Grupos suportados do TLS: curvas, FFDHE e ML-KEM

secp256r1

ECDHE na curva P-256: a troca de chaves que a RFC 8446 torna obrigatória para toda implementação de TLS 1.3.

secp256r1 (23) é o grupo que uma implementação de TLS 1.3 DEVE aceitar (RFC 8446 §9.1), o que faz dele a alternativa que sempre funciona. O key share dele é um ponto não comprimido de 65 bytes; o TLS 1.3 proíbe pontos comprimidos nessas curvas. Veja P-256.

secp384r1

ECDHE na curva P-384, exigido pelo conjunto de algoritmos CNSA 1.0 da NSA.

secp384r1 (24) é marcado como recomendado pela IANA e é o grupo das configurações em conformidade com o CNSA. O key share dele tem 97 bytes. O híbrido SecP384r1MLKEM1024 o combina com ML-KEM-1024 para a transição ao CNSA 2.0. Veja P-384.

x25519

Diffie–Hellman de curva elíptica sobre a Curve25519, a troca de chaves clássica padrão do TLS 1.3.

x25519 (29) é o key share mais comum do TLS 1.3 e a metade clássica do X25519MLKEM768. Segundo a RFC 8446 §9.1, as implementações DEVERIAM oferecer suporte a ele, ao lado do obrigatório secp256r1. Os key shares têm 32 bytes. Veja Curve25519.

ffdhe2048

O grupo Diffie–Hellman de campo finito de 2048 bits da RFC 7919.

A RFC 7919 substituiu os parâmetros DHE escolhidos pelo servidor — muitas vezes de 1024 bits, às vezes compartilhados por muitos servidores e passíveis de pré-computação, como mostrou o ataque Logjam — por cinco named groups fixos. O TLS 1.3 os negocia por meio de supported_groups. A RFC 10015 §3 proíbe as cipher suites FFDHE no TLS 1.2, então esses grupos agora só importam no TLS 1.3, em que raramente são usados.

MLKEM768

ML-KEM-768 sozinho, sem componente clássico: uma troca de chaves TLS puramente pós-quântica.

O MLKEM768 (513) usa apenas o KEM do FIPS 203. Se o ML-KEM fosse quebrado, nada protegeria a sessão, e é por isso que a web usa híbridos como o X25519MLKEM768; os grupos puros se destinam a ambientes cuja política exige algoritmos exclusivamente pós-quânticos.

SecP256r1MLKEM768

O híbrido de ECDHE na curva P-256 com ML-KEM-768, para implantações que precisam se manter em curvas aprovadas pelo NIST.

O SecP256r1MLKEM768 (0x11EB, RFC 10024) combina um key share P-256 com ML-KEM-768. Como os dois componentes são aprovados pelo NIST, ele serve para implantações com validação FIPS que não podem usar X25519.

X25519MLKEM768

A troca de chaves híbrida pós-quântica que os navegadores e os principais servidores negociam por padrão: X25519 combinado com ML-KEM-768.

O X25519MLKEM768 (0x11EC, RFC 10024) envia uma chave de encapsulamento ML-KEM-768 e um key share X25519 em uma única entrada key_share e concatena os dois segredos compartilhados; assim, a sessão continua secreta enquanto qualquer um dos dois algoritmos resistir. Ele protege o tráfego de hoje contra ataques do tipo “coletar agora, descriptografar depois” de futuros computadores quânticos. A IANA o marca como recomendado.

O key share no ClientHello tem cerca de 1,2 KB, o que faz o ClientHello ultrapassar um segmento TCP e expôs equipamentos intermediários (middleboxes) que não conseguem lidar com ClientHellos divididos. Implantações anteriores usavam o ponto de código pré-padrão X25519Kyber768Draft00 (0x6399), hoje obsoleto.