要点

  • RFC 10032はAEGISを認証付き暗号、ストリーム生成、メッセージ認証コードとして規定する。暗号では同じ (key, nonce) を再利用できず、検証前の平文を出してはならない。ストリームはタグを意図的に捨てる。異なる入力で同じ組を再利用できるのはMAC関数だけである。
  • IANA番号、性能値、テストベクトル合格は、APIの役割や鍵用途、nonce空間、失敗時の出力管理を証明しない。意味を持つ証拠は、ビット列がアプリケーションへ渡される境界に必要である。

RFC 10032は2026年9月、IRTFストリームのInformational RFCとして発行され、CFRGの合意を記録した。IETF Standards Trackの標準ではない。AESの暗号化ラウンドを使うAEGIS-128L、AEGIS-256、そして大きなベクトルレジスター向けのAEGIS-128X、AEGIS-256Xを定義する。

IANAは基本形とX2・X4形に32から37までのAEAD識別子を割り当てた。識別子は名前を合わせるためのものだ。APIの役割、128/256ビットのタグ、関連データの構造、鍵の目的、nonceの生成、検証失敗後の動作までは表さない。

既存のBTW記事は、RFC 10032のコードポイントがプロトコル交渉や実稼働の受領証ではないという境界を扱っている。本稿の問いはその後にある。アルゴリズム群を選んだ後、実際に呼ばれたのは三つのうちどの役割で、その出力は何を主張できるのか。

AEADでは検証が出力より先に来る

AEADの暗号化はメッセージ、関連データ、鍵、nonceを受け取り、暗号文とタグを返す。復号は期待タグを計算し、定数時間で比較し、成功した場合に限って平文を返す。

暗号化では同じ鍵とnonceの組を二度使ってはならない。タグ長を変更しても別のnonce領域にはならない。再利用すると二つのメッセージのビット差が直ちに露出し、規定された条件では内部状態も回復され得る。nonceは公開でも予測可能でもよいが、一意でなければならない。

AEGIS-128LとAEGIS-128Xについて、RFCは一鍵あたりランダムnonceで2^48メッセージまでなら衝突確率がおよそ2^-33とする。AEGIS-256とAEGIS-256Xには実用上の制限がないという分析を示す。しかし、これは正しくランダム生成した値の衝突評価であり、意図的な再利用許可ではない。

もう一つの義務は平文の保管だ。タグ検証に失敗したら、未検証平文も計算タグも返してはならず、平文バッファーを消去する。最終的にエラーを返していても、その前にパーサー、ログ、コールバック、データベースが一部を受け取れば境界は破られている。

従って受領証には、役割、変種、タグ長、鍵ID、nonce割当、関連データの正規符号化、検証結果、先行した副作用を含める必要がある。タグは鍵の下でビット列を判定する。アプリケーションが先に行動したかまでは監督しない。

ストリームはタグを捨てることで成立する

RFC 10032のストリーム関数は、関連データなしで全ゼロのメッセージを暗号化し、タグを捨てる。実装はFinalize自体を省ける。返るのはキーストリームであり、認証済みメッセージではない。

これは正当な機能だが、AEADの約束は持たない。出力は送信者を示さず、受信者の検証も示さない。上位構成が完全性を与えるなら、その方式、実行順序、検証前の出力禁止を別に記録しなければならない。

危険なのは名称からの借用だ。監視画面がaegis_stream()もaegis_encrypt()も「AEGIS保護」と表示する。移行ツールがアルゴリズム名を残したまま関数を変える。下流担当者はタグが別の場所にあると思い込む。しかしタグは仕様どおり捨てられている。

ストリームには専用の鍵用途とnonce空間、そして「未認証キーストリーム」と分かる型が必要だ。裸のバイト列と組織内の口伝に意味を預けてはならない。

MACだけが再利用例外を持つ

MAC関数はデータを吸収し、128または256ビットのタグを返す。異なる入力に同じ (key, nonce) を使えるのはこの関数だけだとRFCは明記する。

例外の主体はMACであり、AEGIS全体ではない。「AEGIS共通nonce方針」を作れば、例外が暗号化へ流れ込む。暗号コアは権限の混同を検出できず、計算を続ける。

MACタグにも禁止事項がある。鍵が既知なら状態衝突を起こす入力を作れるため、ハッシュとして使ってはならない。また一様ランダム性が保証されないため、鍵導出の材料にしてはならない。128/256ビットという形だけでは、ダイジェストや新しい秘密鍵にならない。

制御は設計で強制すべきだ。役割に束縛した鍵ID、異なる導出ラベル、別々のnonce割当器を用い、AEAD鍵をSTREAMやMAC入口で拒否する。文書の注意書きだけでは職務分離にならない。

タグ長と関連データはプロトコルの責任である

128ビットタグのkey commitmentは記述されたゲームで約64ビット、256ビットタグは約128ビットとされる。コードポイントはどちらを採用したかを示さない。

さらに、完全なcommitmentは攻撃者が関連データを制御できない制限下で成り立つ。関連データを変更できると、同じ認証暗号文を検証する複数鍵を効率的に見つけられるという分析がある。より強い性質が必要なら、適切な衝突・原像耐性ハッシュで関連データを処理するか、曖昧さのない符号化をKDFのinfoへ束縛する方法が示されている。

これはプロトコル構成の仕事だ。どのフィールドを入れ、誰が制御し、どう直列化し、何を守るかを決めなければならない。原語は渡されたビットを認証するが、その組織的意味までは認証しない。

テストベクトルは保管の連鎖を証明しない

RFC 10032の豊富なベクトルは、固定入力に対する実装一致を検査する。実稼働が正しい入口を呼び、失敗出力を閉じたことは別の証拠である。

負のテストでは、他役割の鍵を渡して拒否させる、タグ長を変えて暗号nonceを再利用する、MAC例外がAEAD割当器へ影響しないことを確認する、ストリームを未認証と型付けする、暗号文・タグ・関連データを壊して平文や副作用が一切出ないことを見る、MACタグをハッシュ/KDFへ渡して拒否させる、ロード済みバイナリーとCPU経路を確認する、といった混同を試すべきだ。

時間、電力、故障注入への耐性は、実際のAESRoundと脅威モデルに依存する。初期化後に一時鍵を消せるという仕様上の機会も、特定のコンパイラーやライブラリーが実行した証拠ではない。

最小の役割受領証は、用途と脅威モデル、役割、変種と並列度、タグ長、鍵の身元と目的、nonce空間と割当、関連データの形式、ライブラリーと実行経路、検証・消去、出力境界、ライブカウンター、アプリケーションの受理またはロールバックを結ぶ。

Lu Hengの最小初期仕様は、共通原語を小さく保ち、結果責任を負う主体に将来判断を残す。レジストリーは名前を調整し、ライブラリーは役割を実行し、プロトコルは構造を決め、アプリケーションは行為を許可する。現実層の規律は、RFC、テスト合格、タグが上位の権限を借りることを防ぐ。

RFC 10032の運用上の核心は、AEGISが三仕事をこなせることだけではない。同じ機械を使っても職務は一つにならない。名前が同じでも、受領証は分けなければならない。

情報源