Groupes pris en charge en TLS : courbes, FFDHE et ML-KEM

secp256r1

ECDHE sur P-256 : l’échange de clés que la RFC 8446 rend obligatoire pour toute implémentation de TLS 1.3.

secp256r1 (23) est le groupe qu’une implémentation de TLS 1.3 DOIT prendre en charge (RFC 8446 §9.1), ce qui en fait la solution de repli qui fonctionne toujours. Sa key share est un point non compressé de 65 octets ; TLS 1.3 interdit les points compressés pour ces courbes. Voir la courbe P-256.

secp384r1

ECDHE sur P-384, exigé par la suite CNSA 1.0 de la NSA.

secp384r1 (24) est marqué comme recommandé par l’IANA, et c’est le groupe des configurations conformes à CNSA. Sa key share fait 97 octets. L’hybride SecP384r1MLKEM1024 l’associe à ML-KEM-1024 pour les transitions vers CNSA 2.0. Voir la courbe P-384.

x25519

Diffie–Hellman sur la courbe elliptique Curve25519, l’échange de clés classique par défaut de TLS 1.3.

x25519 (29) est la key share TLS 1.3 la plus courante et la moitié classique de X25519MLKEM768. Selon la RFC 8446 §9.1, les implémentations DEVRAIENT le prendre en charge, en plus de secp256r1, qui est obligatoire. Les key shares font 32 octets. Voir la courbe Curve25519.

ffdhe2048

Le groupe Diffie–Hellman de 2048 bits sur corps fini de la RFC 7919.

La RFC 7919 a remplacé les paramètres DHE choisis par le serveur – souvent de 1024 bits, parfois partagés par de nombreux serveurs et exposés au précalcul, comme l’a montré l’attaque Logjam – par cinq groupes nommés et fixes. TLS 1.3 les négocie par supported_groups. La RFC 10015 §3 interdit les suites de chiffrement FFDHE en TLS 1.2 ; ces groupes ne comptent donc plus que pour TLS 1.3, où ils sont rarement utilisés.

MLKEM768

ML-KEM-768 seul, sans composante classique : un échange de clés TLS purement post-quantique.

MLKEM768 (513) n’utilise que le KEM de FIPS 203. Si ML-KEM était cassé, plus rien ne protégerait la session : c’est pourquoi le web utilise des hybrides comme X25519MLKEM768 ; les groupes purs visent les environnements dont la politique exige des algorithmes exclusivement post-quantiques.

SecP256r1MLKEM768

L’hybride d’ECDHE sur P-256 et de ML-KEM-768, pour les déploiements qui doivent s’en tenir aux courbes approuvées par le NIST.

SecP256r1MLKEM768 (0x11EB, RFC 10024) combine une key share P-256 et ML-KEM-768. Comme les deux composantes sont approuvées par le NIST, il convient aux déploiements validés FIPS qui ne peuvent pas utiliser X25519.

X25519MLKEM768

L’échange de clés hybride post-quantique que les navigateurs et les grands serveurs négocient par défaut : X25519 combiné à ML-KEM-768.

X25519MLKEM768 (0x11EC, RFC 10024) envoie une clé d’encapsulation ML-KEM-768 et une key share X25519 dans une seule entrée key_share, puis concatène les deux secrets partagés : la session reste secrète tant que l’un des deux algorithmes résiste. Il protège le trafic actuel contre les attaques « récolter maintenant, déchiffrer plus tard » des futurs ordinateurs quantiques. L’IANA le marque comme recommandé.

La key share du ClientHello fait environ 1,2 Ko, ce qui fait dépasser au ClientHello la taille d’un segment TCP et a mis au jour des équipements intermédiaires incapables de traiter un ClientHello fragmenté. Les premiers déploiements utilisaient le point de code X25519Kyber768Draft00 (0x6399), antérieur à la norme et aujourd’hui obsolète.