要約

  • RFC 10024 は ECDHE と ML-KEM の公開値、暗号文、共有秘密を固定順序で連結する三つの TLS 1.3 グループを定義する。
  • 少なくとも一方の暗号機構が安全なら結合秘密を守るという狙いと、二つの実装が別々の障害領域で動くことは同じではない。RFC 自身が共有された脆弱な RNG を共通原因として挙げる。
  • グループ選択の transcript、乱数系、プロセス、ライブラリ、モジュール、FIPS 認証境界、証明書署名、実終端を別々に記録して初めて移行を検証できる。

製造ラインでは二系統、保守票では一系統

組み込み機器向けの TLS 部品を考える。設計表には X25519 と ML-KEM-768 が別々の列に並び、暗号レビューもそれぞれに担当者がいる。ところが製造後の障害票には「暗号モジュール異常」という一項目しかない。二つの演算は同じファームウェア、同じプロセス、同じ乱数サービス、同じ更新署名鍵に依存し、緊急ロールバックも一括で行われるからだ。

ある更新で乱数サービスの再シードが起動順序に負けたとする。ハンドシェイクは X25519MLKEM768 を正しく選び、長さ検査にも Finished にも合格する。それでも ML-KEM のカプセル化と X25519 の一時スカラーが同じ不健全な生成器から出たなら、運用上の二系統性は消えている。

これは特定製品の事故を述べたものではない。正常な CSPRNG の共有そのものを脆弱性と呼ぶものでもない。二つのアルゴリズムを導入した時点で、二つの障害領域も購入したと思い込んではならない、という検査例である。

RFC 10024 は 2026 年 8 月に IETF Standards Track として公開された。TLS 1.3 に三つの Post-Quantum Traditional ハイブリッド鍵合意グループを定め、楕円曲線による一時鍵交換と ML-KEM を組み合わせる。少なくとも一方の構成機構が安全である限り、セッション秘密を守ることが設計目標だ。

この「少なくとも一方」は暗号学的仮定を分散する。運用権限や実装障害まで自動的に分散する文ではない。

NamedGroup は部品表ではなく、順序を含む仕様である

RFC 9954 の枠組みでは、二つの交換を別々にネゴシエートしてアプリケーションが自由に混ぜるのではない。組み合わせ全体を一つの不透明な NamedGroup として扱う。構成要素の公開値または暗号文を決められた順序で連結し、固定長の共有秘密も決められた順序で連結して、TLS 1.3 の通常の (EC)DHE 秘密の位置に入れる。

IANA 値 4588 の X25519MLKEM768 は ML-KEM が先である。クライアントは 1,184 バイトの ML-KEM-768 カプセル化鍵と 32 バイトの X25519 値、計 1,216 バイトを送る。サーバーは 1,088 バイトの ML-KEM 暗号文と 32 バイトの X25519 値、計 1,120 バイトを返す。共有秘密は ML-KEM の 32 バイト、X25519 の 32 バイトの順である。

値 4587 の SecP256r1MLKEM768 は P-256 が先に来る。クライアント側は 65 バイトの非圧縮点と 1,184 バイトの ML-KEM 鍵、サーバー側は 65 バイトの点と 1,088 バイトの暗号文である。秘密は ECDHE 32 バイト、ML-KEM 32 バイトの順になる。

値 4589 の SecP384r1MLKEM1024 は 97 バイトの P-384 点と 1,568 バイトの ML-KEM-1024 値を組み合わせる。クライアント、サーバーとも key share は 1,665 バイトで、秘密は ECDHE 48 バイトと ML-KEM 32 バイト、計 80 バイトである。

固定長だから区切りを追加せずに一意に読める。逆に言えば、順序、パラメータ、検査、鍵スケジュールを変えたものは同じ構成ではない。社内プロトコルに似た連結を持ち込んでも RFC 10024 の分析を借りることはできない。

transcript が構成を TLS に固定する

現行 TLS 1.3 の RFC 9846 は、最初の ClientHello、必要なら HelloRetryRequest と二度目の ClientHello、ServerHello、その後の認証メッセージを transcript hash に束縛する。ServerHello が選択した key share は鍵スケジュールを決め、CertificateVerify は transcript に署名し、Finished は導出鍵の所持を確認する。

RFC 10024 は安全性分析がこの TLS 1.3 transcript に決定的に依存すると明記する。安全性の根拠は「二つのバイト列をつないだ」という見た目ではなく、ネゴシエーションと認証を含むプロトコル全体にある。

RFC 9794 の用語も断言の範囲を整える。PQ/T ハイブリッドとは、少なくとも一つの耐量子構成要素と一つの伝統的構成要素を含む多アルゴリズム方式である。「耐量子」は意図する性質であり、将来の古典攻撃や量子攻撃が絶対に存在しないという保証ではない。

したがって現場が残すべき証拠は具体的だ。クライアントが提示したグループ、送信した key share、HelloRetryRequest の有無、ServerHello の選択、構成要素の検査結果、CertificateVerify の署名方式、Finished の完了を同じ接続の履歴として結ぶ。設定画面の「対応済み」は実行記録ではない。

入力検査は正しいが、工場までは検査しない

RFC 10024 はサーバーに対し、クライアントの ML-KEM カプセル化鍵を FIPS 203 に従って検査し、失敗すれば illegal_parameter で中止するよう求める。クライアントは暗号文の長さを確認する。ECDHE 側も曲線ごとの妥当性検査を行い、X25519 は全ゼロ共有秘密を拒否する。別種の ML-KEM decapsulation 失敗は internal_error となる。

これらは不正な入力を正常なセッションとして処理しないための重要な拒否条件だ。ただし、乱数の供給元、サイドチャネル対策、共有メモリ、ビルド系、別拠点の終端状態までは証明しない。

NIST FIPS 203 は ML-KEM-512、768、1024 を標準化し、量子計算機を持つ攻撃者に対して安全だと考えられる KEM と位置づける。「考えられる」という慎重さは、標準化後も実装、乱数、パラメータ、暗号解析が残ることを示す。

NIST SP 800-227 は KEM の安全な実装と利用、ハイブリッド構成を含む推奨事項を扱う。その文書名を監査票に書くだけでは、稼働中のバイナリがどの推奨事項を満たしたかは分からない。

乱数は RFC が示した共通故障の入口である

ML-KEM のカプセル化で、サーバーはランダム値 m を生成する。クライアントは decapsulation によって m を回復できる。RFC 10024 は、m が生成器の他の出力に関する情報を含むなら、その情報がクライアントに渡ると指摘する。ECDHE の一時スカラーも暗号学的に安全な乱数を必要とするが、スカラー自体は送信されない。

ここから規格は明確な警告を導く。二つのアルゴリズムが同じ安全でない RNG を使う場合、一方を通じた状態漏えいは他方の安全性にも影響する。

「安全でない」という条件を落としてはいけない。適切に設計され、シード、再シード、状態保護が行われた共通 CSPRNG は、共有という理由だけで破綻しない。二台の物理乱数装置が必須という意味でもない。調べる対象は初期エントロピー、シード経路、fork、snapshot、復元、健全性検査、メモリ露出、相手から観測できる出力である。

RFC 8937 は、初期エントロピーの欠陥がそこからシードされた複数の生成器を一緒に弱くし得ると説明する。長期秘密鍵操作から得た材料を混ぜ、セッションをまたぐ乱数を強化する任意のラッパーも提案する。採用する技術は運用者が選べるが、依存関係を説明する責任は消えない。

共通故障は乱数だけではない。一つのライブラリ欠陥が二つの秘密を読める、一つの HSM ファームウェアが両演算を扱う、一つの署名鍵で両実装を置換できる、一つの委託先が全ての TLS を終端する、といった集中がある。これは数学的ハイブリッドを否定する議論ではなく、その保証が届かない運用面を特定する作業である。

FIPS の順番は責任範囲を決める

RFC 10024 は、二つの異なる秘密を HKDF に与える際、最初の秘密が FIPS 承認済み鍵確立方式に由来するという NIST 条件を説明する。SecP256r1MLKEM768 と SecP384r1MLKEM1024 では ECDHE が先なので、記述された用途では ECDHE 実装に認証が必要となり、この順序条件だけでは ML-KEM 実装の認証は要求されない。X25519MLKEM768 では ML-KEM が先なので、ML-KEM 実装が認証対象となる。

先頭は強度順位ではない。必要な構成要素の認証は、もう一方、RNG、結合バイナリ、ネゴシエーション方針、サービス全体を自動的に認証しない。監査ではモジュール名、版、認証番号、境界外を明記すべきである。

レジストリ値は導入証明書ではない

IANA TLS Supported Groups レジストリ は最終グループに 4587、4588、4589 を割り当てた。Recommended が Y なのは X25519MLKEM768 のみで、二つの secp グループは N である。IANA の注記どおり、N は欠陥を意味するとは限らず、限定用途を想定する場合もある。

実験時の Kyber draft グループ 25497 と 25498 は obsolete、discouraged となった。監視が全てを「PQC」と表示すれば、最終仕様と旧 wire code point の違いを失う。

登録は共通語彙を作る。設定は意図を示す。ClientHello は提示を示す。ServerHello と transcript は一接続の選択を示す。全終端での導入率はフリート計測でしか分からない。

2026 年 8 月 30 日時点の RFC 10024 errata 検索 には記録が表示されなかった。これはその日のレジストリ状態であり、全実装の正しさを保証するものではない。

鍵合意と証明書署名は別の移行である

RFC 9954 は次世代認証を対象外としている。TLS 1.3 では鍵合意と Certificate／CertificateVerify が別であり、接続は X25519MLKEM768 を正しく使いながら、サーバー認証には伝統的署名を使い得る。

ハイブリッド鍵合意は、いま記録して将来解読する機密性リスクに対応する。将来のなりすましや証明書移行は別の時間軸だ。鍵合意、署名、実終端、アプリケーション認可を「PQC 完了」の一語に畳むと、どこが未移行か見えなくなる。

Heng Lu の Running-Code Primacy は、制度上のラベルより実行された transcript と観測結果を優先する証拠原則を与える。最小初期仕様、将来判断のローカル化、自発的採用 は、標準が相互運用の共通層を定めても、各運用者の障害境界までは決めない理由を示す。

現実の層と象徴権力 の観点では、「hybrid」は実行状態を表す記号であって状態そのものではない。データ主権の技術面と実務面 の問いを当てれば、終端、ライブラリ、乱数、監視、ロールバックを実際に変更できる主体が誰かを追うことになる。

二つの鍵交換を正しく組み合わせる仕事は標準が行った。二つを同じ障害票から分離する仕事は、導入組織に残っている。