要約

  • RFC 9861は四つのXOFを定義するが、再現には正確な入力バイト列、ドメイン分離値またはカスタマイズ文字列、出力長が要る。
  • KT128とKT256は、符号化後の入力が8192バイトを超えると木構造へ移る。並列化しても最終バイト列は変えてはならない。
  • IRTFのInformational RFCとIANA登録は意味を共有する仕組みであり、実装の適合性や導入判断を保証しない。

保存されていたのは出力値と「KT128」という一行だけだった。数年後、別の実装で同じ値を作ろうとしても一致しない。そこで初めて、旧システムが使ったカスタマイズ文字列も出力長も、入力の直列化規則も記録されていなかったことが分かった。

これは暗号プリミティブの破綻を示す話ではない。問いが保存されていなければ、答えの照合に失敗するのは当然である。RFC 9861は2025年10月、TurboSHAKE128、TurboSHAKE256、KT128、KT256を安定した参照として定義した。RFC Editorの記録ではIRTFのInformational文書であり、CFRGの合意ではあるがIETFのInternet Standardではない。定義が公開されたことと、組織が利用を承認したことは別だ。

XOFでは長さも問いの一部になる

TurboSHAKEの引数は、メッセージM、ドメイン分離バイトD、正の出力長Lである。Dは01から7Fまでで、既定値は1F。同じMとDなら、短い出力は長い出力の先頭部分と一致する。

しかし、先頭が一致するからといってアプリケーションが長さを自由に変えてよいわけではない。32バイトの識別子と64バイトの識別子には、それぞれ保存形式、比較条件、切り詰め規則が必要だ。Lを記録しない監査票は、実行した関数呼び出しを特定していない。

入力を分割して渡す場合も同じである。RFCは、各片を渡された順序で連結した一括入力と同じ結果を要求する。出力を分割取得する場合も、順に連結すれば総長Lを一度に要求した結果と一致しなければならない。チャンク境界は変えられるが、バイト順序は変えられない。

カスタマイズ文字列は注釈ではない

KT128とKT256は、任意のカスタマイズ文字列Cを受け取る。内部入力はS = M || C || length_encode(|C|)として可逆的に構成される。つまり、URI、用途名、テナント識別子をCに入れれば、それらは説明用メタデータではなく結果を決める暗号入力になる。

文字コード、URI正規化、大文字小文字、末尾区切りの扱いが変われば、関数名やメッセージが同じでも出力は変わる。どの部署がCを決め、どの仕様がそのバイト列を固定するのかを明示しなければ、暗号ライブラリ外の変更が実質的な鍵を握る。

空文字列にも由来がある。明示的に空を選んだのか、APIがカスタマイズ引数を持たず既定値を強制したのか、移行で値を失ったのか。同じ計算結果でも、将来の再現性は異なる。

8192バイトの境界はMではなくSにある

KangarooTwelveはSを8192バイト単位に分ける。Sが8192バイト以下なら単一ノード、それを超えると後続ブロックからチェイニング値を作り、最初のブロックと木構造の符号化を最終ノードにまとめる。KT128のチェイニング値は32バイト、KT256は64バイトである。

境界判定の対象は、Cとその長さ符号を含むSだ。業務メッセージが同じでも、カスタマイズを変えるだけで単一ノードから木モードへ移る可能性がある。試験は境界直前、境界上、境界直後を、空と非空のCで実行すべきだ。

実装は枝をSIMDなどで並列処理できる。だが答えは一つである。CPUやバックエンドごとに速度が違っても、最終バイト列の相違は性能差では済まない。本稿は製品や速度を測っていない。要求しているのは、同じ完全な入力条件に対する一致だけだ。

固定プロファイルは関数族より多くを語る

IANAのNamed Informationレジストリでk12-256は、KT128、空のC、32バイト出力を固定する。k12-512はKT256、空のC、64バイト出力である。これらは一般的なKT128/KT256の全出力を表す別名ではない。

COSE Algorithmsレジストリにも四関数の値が登録された。コードポイントは共通語彙を作るが、実装の存在、テスト通過、鍵保護、プロトコル適合を証明しない。

RFCは128系に128ビット、256系に256ビットの強度を主張し、12ラウンドKeccakの暗号解析とSakura符号化を根拠にする。NIST FIPS 202はKeccak/SHA-3の基礎を、SP 800-185は関連する派生関数を示す。設計の系譜は分かっても、特定バイナリの適合性や特定機器上のサイドチャネル耐性までは分からない。

テストベクトルには引数名と状態が要る

RFC 9861には、出力長、メッセージ長、カスタマイズ長、木境界を変えた多数のベクトルがある。現在のRFC Errataには、2026年6月の技術項目8997が一件あり、状態はReportedである。いくつかのKT呼び出しで、先頭の位置引数にM=表示がないという指摘で、提案修正は表記をそろえるものだ。掲載出力バイトは変更していない。

ReportedはVerifiedではない。公開済みRFCの本文に修正が自動反映されたわけでもない。試験証跡は、ベクトルID、全引数、期待値、実測値、実装ビルド、ハードウェア経路、実行時刻を残す必要がある。

ハッシュ一致は認可ではない

RFCはHopMACを定義し、鍵を可逆的に前置・後置する方式や、短いメッセージで鍵をCとして使う例も許す。したがって「KT128 MAC」という記述だけでは、構成、鍵管理、タグ長、ドメインが決まらない。

すべて一致しても証明できるのは、宣言した条件で期待バイトを得たことまでだ。メッセージの作者、鮮度、操作権限、処理結果は別の証拠を要する。仕様、設定、直列化、実行、比較、プロトコル受理、現実の効果を分離してつなぐことが、名前に過剰な権威を与えない方法である。

情報源