#78543 crypto/tls: implement MLKEM1024 key exchange

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

概要

crypto/tls パッケージに、耐量子計算機暗号（PQC: Post-Quantum Cryptography）の鍵交換アルゴリズムである MLKEM1024 のサポートを追加するproposalです。Go 1.27 向けに、const MLKEM1024 CurveID = 514 という新しい定数を crypto/tls に追加することが提案されています。

ステータス変更

active → likely_accept
2026年4月29日に開催されたProposal Review Meetingにて、@aclements（Goコアチーム）が「likely accept」と判断しました。提案内容がシンプル（定数1つの追加）であること、CNSA 2.0準拠要件に応える明確な需要があること、デフォルト有効化もGODEBUGも不要という実装上の懸念が少ない点が、迅速な方向性決定の理由と考えられます。

技術的背景

現状の問題点

Go 1.24 では耐量子計算機鍵交換として X25519MLKEM768（CurveID: 4588）と SecP256r1MLKEM768（CurveID: 4587）が導入・デフォルト有効化されています（#69985）。しかしこれらは NIST セキュリティレベル 3 に相当する ML-KEM-768 ベースのハイブリッドであり、米国防衛機関が策定した CNSA 2.0（Commercial National Security Algorithm Suite 2.0）が義務付けるのは ML-KEM-1024 のみです。
CNSA 2.0準拠が要求される政府・防衛・金融などのシステムでは、現状のGoのTLS実装では仕様を満たせないという具体的な問題がありました。

提案された解決策

draft-ietf-tls-mlkem-07 で定義されている ML-KEM-1024 を、スタンドアロン鍵交換として crypto/tls に追加します。IANAはコードポイント 0x0202（10進数で514）を既に割り当て済みであり、Chrome も実装済みです。仕様変更の可能性はなく、標準化プロセスの観点でも安全な時期と判断されています。
追加される公開APIは以下の1つのみです。

const MLKEM1024 CurveID = 514

既存の crypto/mlkem パッケージ（#70122で導入）に ML-KEM-1024 の実装（EncapsulationKey1024、DecapsulationKey1024 等）が既に存在するため、TLS層の実装コストは低い状況です。

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

CNSA 2.0 準拠システムの構築

CNSA 2.0は米国政府や防衛・国家安全保障関連システムで義務付けられているセキュリティ標準です。ML-KEM-1024 を TLS 1.3の鍵交換として使用することが必須要件となっており、今回の追加により Go 単独でこの要件を満たせるようになります。

コード例

// Before: CNSA 2.0 準拠の鍵交換を Go の crypto/tls で実現する方法がなかった
// X25519MLKEM768 は利用可能だが、CNSA 2.0 非準拠
cfg := &tls.Config{
    CurvePreferences: []tls.CurveID{
        tls.X25519MLKEM768, // CNSA 2.0 非準拠
        tls.X25519,
    },
}
// After: MLKEM1024 を明示的に有効化（デフォルトでは無効）
cfg := &tls.Config{
    CurvePreferences: []tls.CurveID{
        tls.MLKEM1024,  // CNSA 2.0 準拠、CurveID = 514
    },
}

セキュリティ強度の段階的向上

X25519MLKEM768 はポスト量子安全性のために十分ですが、MLKEM1024 はより高いセキュリティレベル（NIST Level 5）を提供します。CRQC（暗号関連量子コンピュータ）の実用化タイムラインが前倒しになりつつある現状で、最高レベルの耐量子安全性を必要とするシステムへの対応が可能になります。

段階的な移行パス

将来 CNSA 2.0 準拠システムがインターネット上で普及した場合、デフォルトの CurvePreferences に MLKEM1024 を追加する選択肢が生まれます。今回はオプトイン形式での導入であり、既存システムへの影響はありません。

議論のハイライト

コードポイントの安定性: draft-ietf-tls-mlkem は名目上まだドラフトだが、IANAが draft-connolly-tls-mlkem-key-agreement-05 に基づいてコードポイント 0x0202（514）を既に正式割り当て済みであり、Chrome も実装済みのため仕様変更のリスクは実質ゼロと判断された。
デフォルト無効の採用: X25519MLKEM768 と異なりデフォルト有効化はしない。CNSA 2.0準拠システムが一般的なインターネット上でまだ稀であるため、必要なシステムが CurvePreferences で明示的に設定する形とした。
GODEBUGの不要性: デフォルト無効のため後方互換性の問題が生じず、GODEBUG フラグの追加は不要と明示された。
実装の基盤が既存: crypto/mlkem パッケージ（#70122）が Go 1.24 で既に導入済みであり、ML-KEM-1024 の低レベル実装は利用可能。TLS統合の工数が限定的であることが承認を後押しした可能性があります。
安全性の比較: X25519 や secp256r1 より安全で、ハイブリッド方式の X25519MLKEM768 / SecP256r1MLKEM768 とほぼ同等の安全性を持つスタンドアロン方式として位置づけられている。

Go Proposal Weekly Digest

crypto/tls: implement MLKEM1024 key exchange

要約

概要