Aller au contenu
ecdsa.com

X25519MLKEM768

Groupe d’échange de clés hybride TLS 1.3 0x11EC (RFC 10024), alliant ML-KEM-768 et X25519, choix post-quantique par défaut des navigateurs, d’OpenSSL et de Go.
Autres graphiesX25519MLKEM7680x11ECX25519Kyber768hybrid ML-KEM TLS group

La key share du client est la clé d’encapsulation ML-KEM-768 de 1184 octets suivie d’une clé publique X25519 de 32 octets (1216 octets) ; le serveur répond avec le texte chiffré ML-KEM de 1088 octets suivi de sa clé X25519 de 32 octets (1120 octets). Le secret partagé est le secret ML-KEM de 32 octets suivi du secret X25519 de 32 octets. Fait inhabituel, la partie post-quantique vient ici en premier, alors que dans SecP256r1MLKEM768 et SecP384r1MLKEM1024, c’est la partie ECDH qui vient en premier.

Il a remplacé le groupe préliminaire X25519Kyber768Draft00 (0x6399), qui reposait sur le Kyber du 3e tour et n’est pas interopérable. Prise en charge par défaut : Chrome et Edge 131 (novembre 2024), Firefox 132, Safari et les plateformes Apple à partir d’iOS et de macOS 26 (2025), OpenSSL 3.5, Go 1.24, ainsi que Cloudflare et d’autres grands CDN côté serveur. L’IANA le marque comme recommandé (Recommended).

Les coûts sont faibles mais visibles : la key share, plus grande, fait dépasser au ClientHello la taille d’un paquet réseau typique, ce qui a mis au jour des équipements intermédiaires (middleboxes) qui gèrent mal les handshakes fragmentés, et un échange de clés avec OpenSSL 3.6.5 nécessite trois opérations (génération de clé, encapsulation, décapsulation), exécutées à raison d’environ 19 000 à 24 000 par seconde sur un cœur d’Apple M4 Max. Le test TLS post-quantique du navigateur indique si votre connexion l’utilise.

Normes et références

Tous les termes