要約

  • リビジョン13は平文だけでなく認証付き関連データも総量に含める。暗号化された本文だけを測るメーターでは、上限が扱う量を測れていない。
  • 保護メッセージ、検証失敗、nonce、鍵の総数、一本の鍵への最大集中は別々の証拠であり、プロセス単位のカウンターではつながりが失われる。
  • 数式と表は例示で、万能のローテーション周期ではない。危険度はアプリケーションが選び、実装は計数、拒否、切替、廃止を証明する。

数式は本番のメーターではない

Crypto Forum Research Group は2026年9月3日、Usage Limits on AEAD Algorithms のリビジョン13を公開した。CFRGの合意による成果物だと明記された一方、文書はなおIRTFのInternet-Draftであり、変更、失効、RFCにならない可能性がある。

同じ鍵を使い続ければ攻撃者の優位が増す。難しいのは、その原理を一つのサービスの受付判断へ変えることだ。RFC 5116は鍵、nonce、平文、関連データを入力するAEADの共通インターフェースを定めるが、複数リージョンや再起動をまたぐ予算台帳までは運営しない。どの失敗パケットが検証に届いたか、複数接続が同じ分析範囲かも知らない。

研究草案が与えるのは共通の技術境界である。許容リスクを決め、実トラフィックが境界に従ったと示す責任は、導入組織に残る。

「十分に小さい」を決める主体

草案は認証暗号全体、機密性、完全性に対する攻撃者の優位を分ける。アプリケーションは目標値を選び、方式と導入条件から運用上限を導く。

例示表の数字をそのまま定期ローテーションへ移しても、根拠にはならない。そこにはメッセージ長、オフライン計算量、目標確率の仮定がある。短いタグを使えば、正常通信より検証失敗の回数が先に制約となり得る。

上限には方式、タグ長、メッセージの範囲、攻撃者の計算量、対象となる鍵集合を添える必要がある。前提のない消費率は監査できない表示にすぎない。

AADも予算を使う

リビジョン13は s を平文と認証付き関連データ（AAD）の総ブロック数へ修正し、L も両方を含む最大長とした。AADは秘匿されないが認証計算には入る。ヘッダー、シーケンス番号、文脈ラベルなどは暗号化本文に現れなくても仕事量を増やす。

アプリケーション本文だけを数える監視は、暗号方式が処理した量を過小評価する。CCMではAAD、暗号文、平文のブロックと追加操作が基礎となり、草案は保守的に 2L と近似する。一般化できる教訓は、帯域の見えるバイトと安全性の計量対象は同じとは限らないことだ。

成功と失敗は別の財布から出る

q は保護したメッセージ数、v は復号または偽造検証の失敗数である。書き手は前者を知り、読み手と防御層は後者を見る。別々の台帳に置けば、機密性だけを管理して完全性の予算を失う。

64ビットタグのAES-CCM_8ではこの差が大きい。単一鍵の例にある 2^13 は一定の前提での説明であって共通上限ではない。重要なのは、正しく拒否した悪性入力でも、限られた検証余力を費やす点である。

失敗はエラー経路で消える前に数えなければならない。レート制限は有効でも、数式と同じ検証操作・鍵範囲を覆わなければ暗号予算の代替にはならない。

鍵一本と鍵集団

第6節は単一鍵向けで、接続内の鍵更新や複数接続のような多鍵環境に使ってはならない。第7節では攻撃者が集団内のどれか一本を破れば成功となる。

ローテーションは一本当たりの仕事を減らす一方で鍵集団を増やす。多鍵分析では q と v の総計に加え、一本の鍵で処理した最大ブロック数が必要になる。GCMでは B、CCMでは暗号化と復号を含む C である。平均値だけでは熱い鍵が隠れ、個別値だけでは多数から一つを狙う優位が隠れる。

コンテナ再起動、リージョン切替、テナント移動、監視画面の更新を予算のリセットにしてはならない。範囲は運用部品ではなく鍵と分析に従う。

nonceは独立した関門

GCMなどでは同じ鍵とnonceの再利用が機密性と完全性を大きく損なう。総量が上限未満でも許されない。割当主体、並行処理、障害復旧、ロールバック後の一意性を別の証拠として残す必要がある。

またGCMでは、確率から導く値が上限に近づくと s + q + v < 2^64 が拘束条件になるとリビジョン13は説明する。最も見やすい数字ではなく、最初に到達する条件が受付を止める。

鍵更新には四つの時刻がある

新鍵の生成、配布、新規保護への有効化、旧鍵の受入廃止は別々の時刻だ。書き手が切り替わった後も読み手は旧鍵を必要とし、処理中の仕事は境界をまたぐ。

受付前に遅延監視、並行予約、再試行、処理中の量を見込むべきである。カウンターが落ちたときに閉じるのか、期限付き緊急枠を使うのかは前もって決める。観測不能を自動的な許可にしてはならない。

この資料が証明しないもの

TLS実装、QUIC端点、クラウド、VPN、データベース、機器、鍵管理製品は試験していない。成功したハンドシェイクは残予算を示さず、正しいタグは過去の計数を保証せず、更新ログは全書き手の切替を証明しない。

事故、侵害、採用率、性能、実装適合も資料からは導けない。リビジョン13は、現場に何を証明させるべきかを明瞭にする文書である。

情報源