要約

  • RFC 9771はAEADで頻用される形容を四つの主張群に分ける。これらを混同すれば、アルゴリズムについて正しい説明でも、システム境界では誤解を招く。
  • 調達や稼働承認を説明可能にするには、形式的な安全性概念、構成と版、APIの挙動、否定試験、鍵のライフサイクル、プロトコル統合を結ぶ「性質の受領証」が要る。

形容詞は保証ではない

「認証付き暗号」は安全性の判断が終わったように響く。しかし実際には、アルゴリズム、鍵とnonceの規律、関連データ、API、周囲のプロトコル状態が一体となって初めて保護を生む。IRTFのCrypto Forum Research Groupが2025年5月に公開したRFC 9771の意義は、この契約を一つの品質表示に押し込めなかった点にある。

同文書はInformationalであり、インターネット標準でも導入認証でもない。価値は分類にある。通常の安全性と、より強い能力を持つ攻撃者に対する追加の安全性を分け、さらに実装特性と、インターフェース自体を変える追加機能を区別する。買い手はまず何の種類の主張かを識別し、その後に必要な証拠を選べる。

RFC 5116の通常のAEADインターフェースは、鍵、nonce、関連データ、平文を受け取り、復号時には平文または失敗を返す。この小さな形にも運用上の義務がある。同じ鍵の下で各呼び出しのnonceを一意にしなければならない。「AES-GCM対応」という仕様表だけでは、一意性の責任者、スナップショット復元後の状態、並行送信者による空間分割、アクセラレーターとソフトウェア代替経路の状態共有は分からない。

RFC 9771は語彙を増やすが、こうした問いを消さない。形容詞を多く選べば安全性が自動的に増す一覧ではなく、異なる証明責任の地図なのである。

四つの主張群と証拠

主張群 変わるもの 添付すべき証拠
通常の安全性 基本的な機密性と暗号文完全性 構成、パラメーター、形式概念、具体的上限、テストベクトル、使用上限
追加の安全性 nonce再利用、複数利用者、漏えい、早期平文など攻撃者の能力 機密性と完全性を分けた主張、形式概念、非同値の開示、誤用試験
実装特性 計算の実行方法 実測した経路、メモリーと走査、検証境界、ハードウェアと代替経路の同等性
追加機能 更新操作や暗号文伸長など新しいAPI 新契約、改定した安全性概念、状態遷移、互換性、失敗時の意味

ここから典型的な誤りが見える。「単一パス」「並列化可能」「ストリーミング可能」は処理方法であり、それだけで機密性や完全性を証明しない。RFC 9771は、ストリーミング構成でブロック単位の安全性や未検証平文を解放する際の完全性が必要になり得ると指摘する。性能測定をストリーミングAPIの安全性受領証に代用してはならない。

逆も同じである。構成への形式的結果は、ラッパーが結果を保つことを証明しない。タグ検証前に復号器がバイトを渡せば、未検証平文を解放するRUPの設定に入る。平文を先に渡した以上、通常の機密性は成立せず、必要な完全性や平文認識の目標も変わる。同じプリミティブを使うバッファ型APIと増分APIが、別の主張を持つ理由である。

追加機能は境界をさらに明確にする。RFC 9771が増分認証付き暗号とrobust authenticated encryptionを付録に置くのは、通常のAEADを超えるAPIを要するからだ。後者では呼び出し側が暗号文の伸長量を選び、その長さで得られる最大の完全性を求める。この「robust」は、鍵コミットメントの同義語として使われるkey robustnessとは違う。承認記録に「robust」しか残らなければ、有用な差異はすでに失われている。

似た言葉に前提が隠れる

nonce-misuse resilienceとnonce-misuse resistanceは同じに見えるが、RFC 9771は区別する。resilienceは攻撃者が別の箇所でnonce再利用を起こしても、新しいnonceのメッセージを保護する。resistanceは再利用されたnonceのメッセージも保護するが、同じnonceで同じ平文を繰り返す際の不可避な漏えいは除く。resistanceはresilienceを含むが、逆は成立しない。

この差は試験項目を変える。resilienceなら事故が新しいnonceの通信を汚染しないことを示す。resistanceなら再利用された通信自体の機密性と完全性も評価する。RFC 8452のAES-GCM-SIVは標準化された誤用耐性構成の例だが、その性質は通常のGCMへ移らず、周辺ライブラリの鍵やエラー処理を保証もしない。

コミットメントにも罠がある。鍵コミットメントは一つの暗号文が異なる鍵で有効になるかを問う。完全コミットメントはnonce、関連データ、平文の違いも対象にする。完全から鍵への含意はあるが逆はない。復号成功によってテナント、アカウント、会話、封筒の文脈を見つける設計では運用問題になる。文脈発見攻撃の研究は複数の有効な文脈が生む曖昧さを示している。ただし受領証には構成、文脈の符号化、タグ長、形式概念が必要である。符号化していない結合を、用語だけで補うことはできない。

性質の受領証を作る

受領証は、調達、セキュリティ、運用、インシデント対応が互いの前提を推測せず読める、簡潔で版管理された証拠である。最初に正確な性質とRFC 9771上の分類を置く。「nonce誤用耐性のある機密性と完全性」は主張だが、「より安全なnonce」は宣伝である。機密性と完全性が別の概念を使うなら両方を記す。代替概念には同値性の証明、または非同値の開示が要る。

次に対象を固定する。アルゴリズムと構成、パラメーター、タグ長、プロバイダーやライブラリ、版とビルド、CPUまたはアクセラレーター経路、ソフトウェア代替経路である。設計の証明とバイナリーの適合試験は別の問いに答えるため、両方が必要だ。

API欄には入力、出力を解放する時点、タグ検証境界、チャンク順序、キャンセル、エラーの意味を記す。nonceと関連データの生成責任者も明示する。失敗時に何も出さないのか、バッファを渡すのか、一部を渡すのか、呼び出し側が行動した後にエラーになるのかは、実際の安全性モデルを決める事実である。

否定試験は一般的な暗号チェックリストではなく、性質から導く。nonce再利用、誤鍵、改変関連データ、別文脈の暗号文、短縮・偽造タグ、チャンクの入れ替え、早期出力、ロールバック、復元、カウンター枯渇、鍵フェーズ移行、ソフトウェアとオフロードの不一致などである。試験は観測した挙動であって証明ではない。証明もAPIが前提を守ったことの代用にはならない。

鍵のライフサイクルには生成と導出、鍵ID、nonceとシーケンスの範囲、並行性、使用上限、更新、破棄、バックアップと復元、複数利用者の集計を含める。RFC 8645は鍵更新機構を示すが、導入側はどの条件で発火し、新旧状態がどう重なるかを示さなければならない。版、オフロード経路、nonce割当、永続化、更新方針が変われば受領証を失効させる。

最後にプリミティブと通信路の間を埋める。TLS 1.3はシーケンス状態からレコードnonceを作り、QUICはパケット番号と鍵フェーズを加える。再試行、リプレイ、障害復旧、移行、フレーミング、文脈結合、相互運用、ハードウェア終端を別途確かめる必要がある。アルゴリズム名はこのシステムの一部にすぎない。

買い手が今すぐ求められるもの

RFC 9771を使えば、こう要求できる。「通常のAEADを超えて主張する各性質について、正確な安全性概念、対象の実装と版、前提を守るAPI挙動、境界を突く否定試験、鍵ライフサイクルの統制、対象プロトコル経路を提示してほしい」。

「非対応」「この経路だけ」「この障害条件では未証明」という回答は有用だ。価格を付け、監視し、見直せる境界を作るからである。危険なのは、責任者も期限もない性質名だ。条件付きの研究結果が、いつの間にか永続的な組織記憶になる。

出典