#78543 crypto/tls: implement MLKEM1024 key exchange

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

概要

crypto/tls パッケージに、耐量子暗号アルゴリズム MLKEM1024 の鍵交換サポートを追加するproposalです。CNSA 2.0（米国家安全保障アルゴリズムスイート 2.0）への準拠を必要とするシステム向けに、CurveID 定数1つの追加という最小限のAPIで実現します。

ステータス変更

(新規) → active
2026年4月22日に @aclements がこのproposalをweekly proposal review meetingsの審査対象である「active」カラムに移動しました。提案の動機・スコープが明確で実装コストが低いこと（定数1つの追加）から、比較的スムーズに審査対象入りしたと考えられます。

技術的背景

現状の問題点

Go 1.24 では X25519MLKEM768（CurveID: 4588）と SecP256r1MLKEM768（CurveID: 4587）が標準的な耐量子鍵交換として追加されデフォルト有効化されました。しかしこれらは ML-KEM-768 ベースの実装であり、CNSA 2.0 が要求する ML-KEM-1024 を単独で使用する MLKEM1024 は提供されていません。
NSA が策定した CNSA 2.0 では、ML-KEM-1024 のみが鍵確立アルゴリズムとして承認されており（ML-KEM-768 は非承認）、2027年以降の新規システムは CNSA 2.0 への準拠が義務付けられる予定です。量子コンピュータ（CRQC）の実用化タイムラインが想定より積極化していることも、早期実装の必要性を高めています。

提案された解決策

draft-ietf-tls-mlkem-07 に準拠した MLKEM1024 を TLS 1.3 の鍵交換方式として実装し、以下の定数を公開します。

const MLKEM1024 CurveID = 514

IANA は draft-connolly-tls-mlkem-key-agreement-05 相当として codepoint 0x0202（10進数: 514）を割り当て済みであり、Chrome もすでに実装しています。仕様はドラフト段階ながら変更の可能性はほぼないとされています。
デフォルトでは無効のため GODEBUG によるフォールバック機構は不要で、Config.CurvePreferences に明示的に追加することで利用可能になります。

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

このproposalが承認・実装されると、CNSA 2.0 準拠が求められる政府機関・国防関連・金融機関などのシステムで、Go の標準ライブラリのみを使って要件を満たせるようになります。

コード例

// Before: CNSA 2.0 準拠の MLKEM1024 を単独指定できない
cfg := &tls.Config{
    CurvePreferences: []tls.CurveID{
        // MLKEM1024 は存在しないため、CNSA 2.0 非準拠になる
        tls.X25519MLKEM768,
        tls.X25519,
    },
}
// After: MLKEM1024 を明示的に有効化（CNSA 2.0 準拠）
cfg := &tls.Config{
    CurvePreferences: []tls.CurveID{
        tls.MLKEM1024, // CurveID = 514
    },
}

議論のハイライト

デフォルト無効の方針: CNSA 2.0 準拠を必要とする環境は限定的であり、一般的なインターネット通信では X25519MLKEM768 で十分とされています。将来的に CNSA 2.0 システムがオープンインターネットで普及した場合はデフォルト有効化を検討するとされています。
ドラフト仕様の採用根拠: 仕様は正式RFC化前だが、IANAによるcodepoint割り当て済み・Chrome実装済み・旧drafts（draft-connolly-tls-mlkem-key-agreement-05）と同等の内容であることから、変更リスクはないと判断されています。
ML-KEM-1024 vs ML-KEM-768: ML-KEM-1024 はML-KEM-768と比較してカプセル化鍵が1568バイト（768比+384バイト）、暗号文も1568バイト（768比+480バイト）と大きく、パフォーマンスコストはあるが CNSA 2.0 では ML-KEM-768 は非承認のため選択の余地がありません。
APIの最小化: 新規型や新規インターフェースは一切追加せず、既存の CurveID 型の定数1つを追加するだけというミニマルな設計です。これは crypto/mlkem パッケージ（#70122）が Go 1.25 でML-KEM-768/1024の基盤実装を提供済みであることで実現できます。
GODEBUG 不要の理由: デフォルトで無効化されるため、既存の動作を変更するものではなく、互換性への影響がゼロです。

Go Proposal Weekly Digest

crypto/tls: implement MLKEM1024 key exchange

要約

概要