TL;DR
KeHoSuは、LLM等が生成した本文を後から加工するのではなく、Latin/Cyrillicの同形文字の選択に、暗号化・認証したプラットフォームIDとユーザIDを埋め込む。各キャリアの配置は局所文脈の鍵付きハッシュで決め、ファウンテン符号で欠損に備えるため、コピペや文の並べ替え、部分引用後も抽出しやすい。論文では18プラットフォームのコピペで識別子が残り、72ビットIDの50%復元点が英語散文で約167文字、LLM生成物で約178文字と報告。英語中心で、コードポイントを保持するコピペ経路が前提。
既存手法との違い
原論文は、ファイル向けのC2PAメタデータと、生成時にトークン分布へ介入するSynthIDを関連手法として挙げる。KeHoSuは生成後にUnicodeコードポイントへ書き込み、コピペでメタデータが落ちる経路を対象にする点が異なり、SynthIDとは併用可能と述べる。同形文字は従来フィッシング攻撃に使われてきたが、これを鍵付き帰属チャネルに転用する。提示本文には既存手法との定量比較表や同一条件でのベンチマークは確認できない。
使える条件
テキストを配布するWebサイト、出版、LLMプラットフォーム等が、生成後の本文に秘密鍵でマークを付ける用途。コピペがUnicodeコードポイントを保持し、Latin/Cyrillicの同形文字キャリア（大文字・小文字とも対応）が十分にある英語テキストが主対象。文の並べ替え、部分引用、軽微な編集、キャリア脱落にはファウンテン符号で対応。識別子は8+32+32=72ビット例、公開鍵検証の非対称モードもある。評価はLLM生成ストーリーと3つの英語コーパス、18プラットフォームのコピペ。他言語・他文字体系・再入力や正規化などの条件は提示本文からは確認できない。
限界と未検証の範囲
評価は英語中心で、キャリア率α≈0.44–0.50は英語頻度に基づく。コピペ経路がコードポイントを保持することが前提で、再入力・翻字・正規化・画像化などは提示本文で未検証。フォントによって見た目が異なる同形文字ペアはキャリアから除外。短文では識別子長に応じて必要文字数が増え、128ビットのプラットフォームIDはr=0.5で約569文字必要と報告。境界層のキャリアは抽出時にスキップ。混合スクリプト検出を一定以下に抑えると隠しビットはO(log L)に制限。偽造耐性は鍵なしでq2^-t+AdvAEADの範囲。文の並べ替え不変は定数境界層を除く。非英語・多言語・実運用の大規模評価は提示本文から確認できない。
解説
ねえ智也、この「KeHoSu」って論文、タイトルからして呪文みたいなんだけど、何の話なの？
LLMが書いた文章がコピペで拡散されたとき、「どのプラットフォームの、誰のアカウントから出たか」を後から突き止める仕組みの話。文章そのものに帰属マークを埋め込む。
え、文章にマークって、ファイルに付けるメタデータみたいな感じ？
メタデータはコピペで消えるだろ。そうじゃなくて、文字そのもの、Unicodeのコードポイントが残ることを利用する。ラテン文字のaとキリル文字のаって見た目ほぼ同じだけど別のコードポイントなんだよ。
あー、見た目そっくりな文字、あるある！ でもそれって偽装に使われるやつじゃん。
そう。同形文字攻撃を逆手に取る。ラテン文字なら0、キリル文字なら1、みたいに1ビットを運ばせる。キャリアは、大文字も小文字も同形がそろう文字だけに絞ってる。再キャップでマークが崩れないようにね。
全部の文字がキャリアになるわけじゃないんだ。どれくらい埋め込めるの？
英語の文字頻度でいくと、e・a・o・i・s・c・p・y・x・jで全文字の約49.8%。フォントによって形が違うペアを除いて、キャリア率αは0.44〜0.50くらい。英語散文だと1文字あたり0.39個くらいがキャリアになる。
で、ビットって文章のどこに置くの？ 決まった順番？
そこが工夫。各キャリアの周りの局所的な文脈を鍵付きハッシュにかけて、その値をΛで割った余りを「どの符号ビットを置くか」のインデックスにする。だから挿入や削除があっても、その窓に重なるキャリアのインデックスしか変わらない。文全体のハッシュや絶対位置だと、1文字入っただけで全部ずれる。
ローカルだから壊れにくいんだ。じゃあ文の並べ替えは？
文の境界で窓をクリップしてるから、文を並べ替えても各キャリアのインデックスは変わらない。両端に定数サイズの境界層はできるけどね。部分引用も、残った長さにしか依存しない。
欠損にはどう備えるの？
ファウンテン符号、レートレス符号を使う。異なるインデックスの正しいビットが(1+ε)K個そろえば復号できる。編集でインデックスがずれたキャリアは、正しいところから票を1つ引いて、間違ったところに1つ足す形になる。復号器は票差の大きいK+16本の式を選んで解いて、タグが通るまで最大8回くらいやり直す。
識別子の中身って何が入ってるの？
プラットフォームIDとユーザIDを暗号化して、認証タグを切り詰めて付けたもの。例だと8+32+32で72ビット。SIVっぽい決定的暗号でノンスを省いてる。鍵なしで偽造が通る確率はq2^-t + AdvAEADで抑えられる。非対称モードだと公開鍵で発信元プラットフォームを誰でも検証できて、ユーザIDはプラットフォームだけが読める。
評価はどうなってるの？
18のプラットフォームでコピペしてもマークが残った、と報告してる。72ビットIDの50%復元点は、英語散文で約167文字、LLM生成ストーリーで約178文字。文の並べ替えで判定が変わらなかったのが1524文書。散発的に4箇所置換されても、コンセンサス復号で320文字の設計点を71%の試行で復元した、とも書いてある。
既存の方法と何が違うの？
C2PAみたいなファイル向けの来歴メタデータは、コピペで落ちる。SynthIDみたいな生成時ウォーターマークはモデルのトークン分布に介入するけど、KeHoSuは生成済みのテキストのコードポイントに書き込むから、モデルのサンプリングに触らなくていい。プラットフォーム側が後から付けられるし、SynthIDと併用もできると書いてある。
へえ、じゃあ配布した文章や内部文書が引用・漏えいされても、どのアカウント宛てだったか辿れるってことだ。
ただ、同じ条件での既存手法との定量比較表みたいなのは、提示された本文からは確認できない。あと評価は英語中心で、キャリア率も英語頻度ベース。コピペ経路がコードポイントを保持することが前提で、再入力・翻字・正規化・画像化は未検証。フォントで見え方が違う同形ペアはキャリアから外してるし、境界層のキャリアは抽出時にスキップされる。
短い文章だと厳しいの？
短文ほど必要文字数が増える。128ビットのプラットフォームIDだとr=0.5で約569文字必要。対象は段落や記事くらいの長さ。あと混合スクリプト検出を一定以下に抑えると、隠せるビットはO(log L)に制限される、っていう理論的な話もある。
なるほどね、コピペしても残る指紋ってことか。じゃあ私が智也のカッコいい文章をコピペして自分のブログに載せても、智也印が残ってバレちゃうんだね！
まずコピペすんな。