要約

  • RFC 10032はCFRGの合意を反映するIRTFストリームのInformational文書であり、IETF Standards Trackの義務ではない。IANAの6識別子は安定した名称を与えるが、導入を命じない。
  • 登録はAEGIS-128L、AEGIS-256、四つのX2/X4並列形を区別する一方、128ビットか256ビットかという認証タグ長は符号化しない。並列形は任意であり、当事者全員が同一変種に合意した場合に限って選ぶべきである。
  • ライブラリの自己試験は固定入力に対するプリミティブの一致を示せる。ピアが何を選んだか、どのバイナリとCPU経路が動いたか、nonceと関連データをどう構成したか、実通信で何を使ったかは示せない。
  • アルゴリズム管理受領証は、文書・登録のスナップショット、プロトコル構成、認証された選択、コードポイントとタグ、鍵・nonceのライフサイクル、関連データの符号化、実行経路、正負試験、失敗処理、カウンタ、フォールバック、ロールバックを結び付けるべきである。

数字が到着しても、パケットの履歴は届かない

IANA登録では、32がAEAD_AEGIS128L、33がAEAD_AEGIS256、34と35がAEGIS-128のX2/X4、36と37がAEGIS-256のX2/X4である。公開識別子が重複することを防ぎ、設定画面やプロトコル仕様が同じ変種を正確に指せる点に登録の価値がある。

その番号はセッションの記録ではない。AEADの共通インターフェースと登録を定めたRFC 5116は、IANA登録がアルゴリズムや安全性の承認ではないことを明記する。そのインターフェースは、リプレイ防止やアクセス制御も決めない。呼び出すプロトコルと配備側の責任である。

RFC 10032が提供するのは、プリミティブの定義、パラメータ、運用上の注意、テストベクトルである。TLS、IPsec、QUIC、ストレージ、独自チャネルに共通する一つのネゴシエーションを定義してはいない。採用するプロトコルは、AEGISを提示するか、識別子とプロファイルをどう対応させるか、タグ長、鍵とnonce、関連データ、認証失敗時の処理を自ら決めなければならない。

「製品にAEGISの関数がある」という能力情報と、「このセッションは特定のAEGIS変種で保護された」という運用情報の間には、選択と実行の証拠が必要になる。

RFCという表紙だけで権限を一つにしない

RFC 10032は2026年9月、IRTFストリームのInformational文書として公開された。CFRGの研究グループ合意を表す一方、IETFの製品でも標準でもなく、IRTFの成果が配備に適さない場合があることを状態欄で説明している。

これは技術的価値の否定ではなく、審査経路の表示である。RFC 5743は研究グループでの作成、IRSGレビュー、IESGによる標準化活動との競合確認を説明する。RFC 7841は、非IETFストリーム文書がIETF標準と同じ組織全体の審査・承認を通常は受けないことを示す。

したがって、CFRGの合意、IRSGによる公開承認、IESGの競合確認、IANAによる一意な割当ては四つの別事実である。いずれも、特定プロトコルの採用、製品の既定値、二つのエンドポイントによる選択を意味しない。

9月20日に確認したIANAの公開ページには6行が存在したが、参照欄はなおdraft-18を示し、ページの更新日は7月7日だった。この表示差は割当てが無効だという根拠ではない。審査時に見た公開状態と登録状態を、それぞれ日時付きで残す必要性を示す例である。

同じ32でもタグ境界は一致しない

AEGIS-128Lの鍵とnonceは128ビット、AEGIS-256では256ビットである。どちらも128ビットと256ビットの認証タグを選べる。6種類の登録名はファミリーと並列度を表すが、タグ長を表さない。

この選択は単なる表示設定ではない。RFC 10032が説明するコミット性では、128ビットタグの場合におよそ2^64、256ビットタグの場合におよそ2^128の作業量が示される。同じコードポイント32に合意した二者でも、一方が16バイト、他方が32バイトのタグを期待すれば、登録上は一致してもワイヤ形式は互換でない。

暗号文とタグを別々に扱うか、タグを暗号文の直後に連結するかも固定しなければならない。「AEGIS-128L」という記録だけでは、受信側が何ビットを読み、どこを境界としたかを再現できない。

関連データも同様である。RFC 5116は、アドレス、ポート、シーケンス番号、バージョンなどの平文フィールドを認証対象にできると説明する。RFC 10032の完全コミット性には攻撃者が関連データを制御しないという制約があり、より強い性質を必要とする場合の追加構成も示す。フィールド一覧、順序、長さ、バージョン、ドメイン分離はプロトコル固有の証拠である。

X4の速度は相互運用性を保証しない

AEGIS-128XとAEGIS-256Xは、広いベクトルレジスタとベクトルAES命令を使う設計であり、X2とX4は並列度二と四を表す。実際の利得はプロセッサと実装に依存する。

RFC 10032は採用条件も示す。並列形は、関係するすべての当事者が特定変種に合意した場合にだけプロトコルが選ぶべきであり、AEGIS-128LとAEGIS-256を既定とすべきである。実装は並列形を省略できる。

従って、高速なX4ベンチマークは移植可能なスイートの証明にならない。相手が基底形しか持たない場合、ビルドにX経路が含まれない場合、仮想マシン移動で見える命令が変わる場合、ランタイムが別経路にフォールバックする場合がある。設定欄の「AEGIS」はそれらを区別しない。

受領証は、プロトコルが提示・選択したもの、各ピアに存在した正確な能力、プロセスが実際に通った実装経路を分離して残す必要がある。

nonce管理は大きな数値の外側にある

RFC 10032は、暗号化では一つの鍵に対してnonceを一度しか使わないよう求める。タグ長が異なる場合も同じで、再利用すれば二つのメッセージのビット単位の差が直ちに露出する。nonce自体は公開・予測可能でもよく、カウンタや長周期生成器を使える。

ランダムnonceについては、128ビット系で、示された約2^-33の衝突確率の下、一鍵当たり2^48メッセージまでとされる。256ビット系には「実用上の制限なし」とある。しかし、それは一鍵一nonceの規則や運用上の記録を消さない。

配備側は、一意性の範囲、鍵エポック、再起動時の永続化、乱数源、シャードへの範囲割当て、スナップショット復元やクローンの検出を決めなければならない。同じイメージから二つのプロセスが復元されれば、両方が次の値の所有者だと考え得る。フィールドの広さだけでは調停できない。

鍵にも、生成または導出、プロトコル文脈、エポック、利用者の分離、識別子、消去境界の履歴が要る。初期化後に一時鍵を消去できるという仕様上の記述は、選択した実装がそうしたことの証拠ではない。

自己試験は必要だが、対象が小さい

RFC 10032にはAESRound、基底アルゴリズム、X2/X4、MAC形式について多数の固定ベクトルがある。バイト順、終了処理、部分ブロック、タグ生成の誤りを見つける上で有効で、独立実装間の比較も価値が高い。

負の試験では、タグ、関連データの一フィールド、nonce、並列度を変え、すべてが拒否されることを確認する。認証失敗時には、未検証平文と計算したタグを外へ出さず、復号バッファを上書きし、タグを定数時間で比較する必要がある。正のベクトルだけ通る高速経路が認証前にデータを公開すれば、仕様どおりではない。

完全な試験でも、実際のハンドシェイクが同じスイートを提示したこと、両者が選択を認証したこと、期待する共有ライブラリがロードされたこと、加速経路が動いたこと、利用数が鍵エポック内に収まったことまでは示せない。そこから先は運用証拠の領域である。

14項目のアルゴリズム管理受領証

次の受領証はDaniel Kadeによる編集上の運用提案であり、RFC 10032の要件でも、IETF、IRTF、CFRG、IANAの適合証明でもない。

第一に、文書識別子、ストリーム、分類、公開・正誤表の時点、IANA登録の時点。第二に、呼出しプロトコル、バージョン、スイートのプロファイル、設定世代。第三に、認証された提示・選択記録、または同等のピア合意証拠。

第四に、数値コードと基底、X2、X4の正確な変種。第五に、タグ長と暗号文・タグのフレーミング。第六に、ピア能力と非対応時の挙動。第七に、鍵の出所、導出文脈、エポック、識別子、消去境界。

第八に、nonceの構成、永続化、一意性ドメイン、再起動処理、一鍵当たりの使用カウンタ。第九に、関連データの項目と正規符号化。第十に、ライブラリのビルド、CPU・ベクトル経路、フォールバック。第十一に、正のベクトル、実装間試験、負の試験。

第十二に、認証失敗の意味、平文抑止、定数時間比較、警告。第十三に、範囲を限定したセッションやパケットと使用量テレメトリ。第十四に、代替規則、ダウングレード拒否、ロールバック条件、互換集合からの退出、証拠保存期間。

登録のスナップショットはハンドシェイクを証明せず、ハンドシェイクは再起動後のnonce永続化を証明しない。テストベクトルはロード済みバイナリを特定せず、鍵エポックと関連データ規則のないパケットは受理理由を説明できない。これらを「対応済み」の一語に畳まないことが、受領証の役割である。

出典