Поддерживаемые группы TLS: кривые, FFDHE и ML-KEM

secp256r1

ECDHE на P-256: обмен ключами, обязательный по RFC 8446 для каждой реализации TLS 1.3.

secp256r1 (23) — группа, которую реализация TLS 1.3 обязана (MUST) поддерживать (RFC 8446, § 9.1), поэтому она служит запасным вариантом, который работает всегда. Её key share — несжатая точка длиной 65 байт; сжатые точки для этих кривых в TLS 1.3 запрещены. См. P-256.

secp384r1

ECDHE на P-384, обязательный в наборе алгоритмов CNSA 1.0 от NSA.

IANA помечает secp384r1 (24) как рекомендуемую (Recommended); это группа конфигураций, соответствующих CNSA. Её key share занимает 97 байт. Гибрид SecP384r1MLKEM1024 сочетает её с ML-KEM-1024 для перехода на CNSA 2.0. См. P-384.

x25519

Протокол Диффи — Хеллмана на эллиптической кривой Curve25519, классический обмен ключами по умолчанию в TLS 1.3.

x25519 (29) — самый распространённый key share в TLS 1.3 и классическая половина X25519MLKEM768. Согласно RFC 8446, § 9.1, реализациям следует (SHOULD) поддерживать эту группу наряду с обязательной secp256r1. Значение key share занимает 32 байта. См. Curve25519.

ffdhe2048

2048-битная группа Диффи — Хеллмана над конечным полем из RFC 7919.

RFC 7919 заменил выбираемые сервером параметры DHE пятью фиксированными именованными группами. Прежние параметры часто были 1024-битными, иногда общими для многих серверов и поддавались предварительным вычислениям, как показала атака Logjam. TLS 1.3 согласует эти группы через supported_groups. Согласно RFC 10015, § 3, наборы шифров FFDHE в TLS 1.2 запрещены, поэтому теперь эти группы важны только для TLS 1.3, где их используют редко.

MLKEM768

Только ML-KEM-768, без классической составляющей: чисто постквантовый обмен ключами в TLS.

MLKEM768 (513) использует только KEM из FIPS 203. Если бы ML-KEM взломали, сеанс остался бы без защиты, поэтому в вебе используют гибриды, например X25519MLKEM768; чистые группы предназначены для сред, политика которых требует только постквантовых алгоритмов.

SecP256r1MLKEM768

Гибрид ECDHE на P-256 с ML-KEM-768 для развёртываний, которые должны оставаться на кривых, одобренных NIST.

SecP256r1MLKEM768 (0x11EB, RFC 10024) объединяет key share на P-256 с ML-KEM-768. Поскольку обе составляющие одобрены NIST, эта группа подходит для сертифицированных по FIPS развёртываний, где нельзя использовать X25519.

X25519MLKEM768

Гибридный постквантовый обмен ключами, который браузеры и крупные серверы согласуют по умолчанию: X25519 в сочетании с ML-KEM-768.

X25519MLKEM768 (0x11EC, RFC 10024) передаёт ключ инкапсуляции ML-KEM-768 и key share X25519 в одной записи key_share и конкатенирует два общих секрета, поэтому сеанс остаётся секретным, пока стоек хотя бы один из алгоритмов. Эта группа защищает сегодняшний трафик от атак будущих квантовых компьютеров по схеме «собери сейчас, расшифруй потом» (harvest now, decrypt later). IANA помечает её как рекомендуемую (Recommended).

Key share в ClientHello занимает около 1,2 КБ, из-за чего ClientHello уже не помещается в один TCP-сегмент; это выявило промежуточные устройства (middleboxes), которые не справляются с ClientHello, разбитым на несколько сегментов. Ранние развёртывания использовали достандартное кодовое значение X25519Kyber768Draft00 (0x6399), которое теперь устарело.