TLS のサポートされるグループ｜曲線、FFDHE、ML-KEM

secp256r1

P-256 上の ECDHE で、RFC 8446 がすべての TLS 1.3 実装に必須としている鍵交換です。

secp256r1（23）は、TLS 1.3 の実装がサポートしなければならない（MUST）グループです（RFC 8446 §9.1）。そのため、常に使えるフォールバックになります。キーシェアは 65 バイトの非圧縮形式の点で、TLS 1.3 ではこれらの曲線で圧縮された点の使用が禁止されています。P-256 も参照してください。

secp384r1

P-384 上の ECDHE で、NSA の CNSA 1.0 スイートで必須とされています。

secp384r1（24）は IANA で推奨とされており、CNSA に準拠した構成で使われるグループです。キーシェアは 97 バイトです。ハイブリッドの SecP384r1MLKEM1024 は、CNSA 2.0 への移行に向けてこれを ML-KEM-1024 と組み合わせます。P-384 も参照してください。

x25519

Curve25519 上の楕円曲線 Diffie–Hellman で、TLS 1.3 における従来型の鍵交換のデフォルトです。

x25519（29）は TLS 1.3 で最も一般的なキーシェアで、X25519MLKEM768 の従来型の半分を担います。RFC 8446 §9.1 は、必須の secp256r1 に加えて、実装がこれをサポートすべき（SHOULD）としています。キーシェアは 32 バイトです。Curve25519 も参照してください。

ffdhe2048

RFC 7919 で定義された 2048 ビットの有限体 Diffie–Hellman グループです。

RFC 7919 は、サーバーが選ぶ DHE パラメーターを、固定された 5 つの名前付きグループに置き換えました。従来のパラメーターは 1024 ビットのことが多く、多数のサーバーで共有されていて事前計算が可能な場合もあることが、Logjam 攻撃で示されていました。TLS 1.3 は、これらのグループを supported_groups でネゴシエートします。RFC 10015 §3 は TLS 1.2 で FFDHE の暗号スイートを禁止しているため、現在これらのグループが意味を持つのは TLS 1.3 だけですが、そこでもめったに使われません。

MLKEM768

従来型の要素を含まない ML-KEM-768 単体の、純粋なポスト量子 TLS 鍵交換です。

MLKEM768（513）は FIPS 203 の KEM だけを使います。ML-KEM が破られた場合、セッションを守るものは何もなくなります。Web で X25519MLKEM768 などのハイブリッドが使われているのはそのためです。純粋なポスト量子グループは、ポリシーでポスト量子アルゴリズムのみの使用が求められる環境を対象としています。

SecP256r1MLKEM768

P-256 の ECDHE と ML-KEM-768 のハイブリッドで、NIST 承認の曲線を使い続けなければならない環境向けです。

SecP256r1MLKEM768（0x11EB、RFC 10024）は、P-256 のキーシェアと ML-KEM-768 を組み合わせます。どちらの要素も NIST の承認を受けているため、X25519 を使えない FIPS 認証済みの環境に適しています。

X25519MLKEM768

ブラウザーと主要なサーバーがデフォルトでネゴシエートするハイブリッドのポスト量子鍵交換で、X25519 と ML-KEM-768 を組み合わせたものです。

X25519MLKEM768（0x11EC、RFC 10024）は、ML-KEM-768 のカプセル化鍵と X25519 のキーシェアを 1 つの key_share エントリで送り、2 つの共有秘密を連結します。そのため、どちらかのアルゴリズムが安全である限り、セッションの秘密は保たれます。将来の量子コンピューターによる「harvest now, decrypt later」（今収集し、後で解読する）攻撃から、現在の通信を守ります。IANA はこれを推奨としています。

ClientHello のキーシェアは約 1.2 KB あり、ClientHello が 1 つの TCP セグメントに収まらなくなるため、分割された ClientHello を処理できないミドルボックスの存在が明らかになりました。以前の導入では標準化前のコードポイント X25519Kyber768Draft00（0x6399）が使われていましたが、現在は廃止されています。