#78543 crypto/tls: implement MLKEM1024 key exchange

AIによる要約であり、誤りを含む場合があります。

概要

crypto/tls パッケージに、耐量子暗号（ポスト量子暗号）の鍵交換メカニズムとして純粋な ML-KEM-1024 のサポートを追加するプロポーザルです。Go 1.27 を対象に、新しい CurveID 定数 MLKEM1024 = 514 を追加することが承認されました。

ステータス変更

likely_accept → accepted
2026年4月29日にレビューグループが "likely accept" と評価し、その後1週間のコメント期間を経て変更がなかったため、2026年5月6日の定例プロポーザルレビューミーティングにて正式に "accepted" となりました。レビューには @aclements、@adonovan、@bradfitz、@cherrymui、@griesemer、@neild、@rolandshoemaker が参加し、コンセンサスに変更なしとして承認が確定しました。

技術的背景

現状の問題点

Go の crypto/tls は現在、以下のポスト量子鍵交換をサポートしています（Go 1.24 で追加）。

X25519MLKEM768（コードポイント: 4588）: X25519 とのハイブリッド方式。デフォルト有効
SecP256r1MLKEM768（コードポイント: 4587）: P-256 とのハイブリッド方式。デフォルト有効
SecP384r1MLKEM1024（コードポイント: 4589）: P-384 とのハイブリッド方式
しかし、これらはいずれも従来の楕円曲線暗号と ML-KEM を組み合わせたハイブリッド方式であり、純粋な ML-KEM-1024 単体での TLS 鍵交換はサポートされていませんでした。
CNSA 2.0（Commercial National Security Algorithm Suite 2.0）は米国 NSA が国家安全保障システム向けに策定した暗号アルゴリズム標準であり、鍵交換に ML-KEM-1024 を必須要件として定めています。CNSA 2.0 への準拠を求められるシステム（政府機関、防衛関連など）では、純粋な ML-KEM-1024 による鍵交換が必要でした。

提案された解決策

crypto/tls パッケージに以下の定数を追加します。

const MLKEM1024 CurveID = 514

コードポイント 514 は 16 進数で 0x0202 であり、IANA の TLS Named Group レジストリに登録済みの値です（draft-connolly-tls-mlkem-key-agreement-05 に基づく）。この仕様はドラフト段階ですが、IANA がコードポイントを割り当て済みであり、Chrome も実装済みであることから仕様変更はないと判断されています。
デフォルトでは無効であり、GODEBUG フラグも不要です。利用する場合は Config.CurvePreferences で明示的に指定する必要があります。

これによって何ができるようになるか

CNSA 2.0 準拠を求められる政府機関や防衛・安全保障関連のシステムにおいて、Go の標準 TLS ライブラリを使用しながら規格への適合が可能になります。

コード例

// Before: CNSA 2.0 準拠のために純粋な ML-KEM-1024 を使いたくても、
// Go の標準ライブラリにはサポートがなかった
cfg := &tls.Config{
    // 利用可能なのはハイブリッド方式のみ
    CurvePreferences: []tls.CurveID{
        tls.X25519MLKEM768,    // X25519 との組み合わせ（ハイブリッド）
        tls.SecP256r1MLKEM768, // P-256 との組み合わせ（ハイブリッド）
    },
}
// After: 純粋な ML-KEM-1024 を指定可能になる
cfg := &tls.Config{
    CurvePreferences: []tls.CurveID{
        tls.MLKEM1024, // 純粋な ML-KEM-1024（CNSA 2.0 準拠）
    },
}

主なユースケース:

CNSA 2.0 準拠システム: 国家安全保障システムや機密情報を扱う政府機関が、規格要件を満たすために純粋な ML-KEM-1024 を使用する
ポスト量子移行の段階的実施: ハイブリッド方式から純粋なポスト量子暗号への将来的な移行パスを確保する
暗号アジリティの向上: セキュリティポリシーに応じた鍵交換アルゴリズムの選択肢を増やす

議論のハイライト

デフォルト無効の理由: CNSA 2.0 準拠システムは現時点ではオープンインターネット上でまだ一般的ではないため、デフォルトで有効化する理由はないとされた。CNSA 2.0 システムが広く普及した場合は将来変更される可能性があります
ドラフト仕様だが安定: draft-ietf-tls-mlkem-07 はまだ IETF ドラフト段階だが、IANA によるコードポイント割り当て済みかつ Chrome でも実装済みであるため、仕様変更のリスクはないと判断された
X25519MLKEM768 との位置づけの違い: 既存のハイブリッド方式と比較して安全性はわずかに低いとされるが（量子コンピュータが登場した場合でも古典暗号部分の保護がない）、CNSA 2.0 の要件上は必要な選択肢
GODEBUG 不要: デフォルト無効であるため、後方互換性への影響がなく、GODEBUG フラグによる制御機構は不要と判断された
API の最小化: 公開 API は const MLKEM1024 CurveID = 514 のみと非常にシンプルな設計で、既存の crypto/mlkem パッケージの実装を活用する

Go Proposal Weekly Digest

crypto/tls: implement MLKEM1024 key exchange

要約

概要