要約

  • RFC 10042 は ML-KEM と P-256、P-384、X25519 を組み合わせ、両方の結果から一つの共有秘密を導く三方式を登録した。
  • ソフトウェアの対応だけでは利用を証明できない。接続ごとの交渉結果、失敗、認証状態が移行の証拠になる。

二つのアルゴリズム、一つの交渉方式

RFC 10042 は「今収集し、後で復号する」リスクに対応し、mlkem768nistp256-sha256、mlkem1024nistp384-sha384、mlkem768x25519-sha256 を定義する。一つの SSH 方式名の中で、従来 ECDH と ML-KEM カプセル化を実行する。

クライアントは耐量子と従来の公開材料を連結して送る。サーバーは ML-KEM 暗号文、従来公開鍵、ホスト鍵、交換署名を返す。双方は所定の長さを検証し、規定の失敗時には鍵交換を中止する。共有秘密は固定長表現を使い、K = HASH(K_PQ || K_CL) として SSH の鍵導出へ渡される。

これは仕様上の事実である。運用上は、ハイブリッド名が交渉で選ばれ、交換全体が成功した時だけ移行境界を越える。実装が存在しても、古い優先順位、バージョン差、フォールバック設定が従来方式を選び得る。

ハイブリッド方式は認証を置き換えない

ホスト鍵と署名は引き続き交換記録の一部である。したがって、弱いホスト鍵管理、未確認の信頼判断、侵害された認証情報を修復するものではない。RFC の公開は、特定製品や運用者の導入証拠でもない。

RFC は各接続で新しい ECDH と ML-KEM の一時鍵対を要求し、ML-KEM 暗号文生成時の乱数再利用を禁じる。固定長の秘密表現も求め、長さの変動に起因するタイミング漏えいを抑える。実装品質と乱数品質は管理対象である。

サイズは収まっても運用は無料ではない

定義された三方式は SSH の最低パケット能力内に収まる。しかし互換性、CPU、遅延、容量、失敗監視、ロールバック条件はローカルに測る必要がある。一次資料は特定環境の費用を定量化していない。

受益者は、現在の古典暗号の前提より長く機密性を保つ必要があるセッションだ。費用はクライアント、サーバー、踏み台、 自動化、暗号ライブラリを維持するチームが負う。古典方式のみなら単純だが ML-KEM はなく、耐量子方式のみなら古典側の保険を失う。後者は RFC 10042 の設計ではない。

情報源