X25519MLKEM768 (hybrid X25519 + ML-KEM-768 key exchange)

X25519MLKEM768 is a TLS 1.3 named group (codepoint 0x11EC), standardized in RFC 10024 (August 2026), that runs two key exchanges at once: X25519 elliptic-curve Diffie-Hellman and ML-KEM-768. The client's key share is an ML-KEM-768 encapsulation key followed by an X25519 public key (1,184 + 32 = 1,216 bytes); the server replies with an ML-KEM ciphertext and its own X25519 share (1,088 + 32 = 1,120 bytes). The two shared secrets are concatenated and fed into the normal TLS 1.3 key schedule.

Why it matters

It is the most widely deployed hybrid key exchange on the web. Chrome 131 (November 2024) switched to it from the earlier experimental X25519Kyber768Draft00 group, and OpenSSL supports it from version 3.5. Because breaking the result requires breaking both X25519 and ML-KEM-768, it protects today's traffic against future quantum decryption without betting everything on a young algorithm. It exists only in TLS 1.3; servers that do not support it simply negotiate plain X25519 or P-256.

Example

Check support from the command line (OpenSSL 3.5 or later), and prefer it in nginx built against such an OpenSSL:

openssl s_client -connect example.com:443 -groups X25519MLKEM768

ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1;

In Chrome, the DevTools Security panel shows X25519MLKEM768 as the key exchange when it is negotiated.

Common misconceptions

• "It makes the connection fully quantum-safe." It protects key establishment; server authentication still uses classical RSA or ECDSA signatures.
• "Hybrid means only half as strong." An attacker must break both components, so it is at least as hard to break as either one alone.
• "It is the same as X25519Kyber768Draft00." That was an earlier experimental group based on pre-standard Kyber, with a different codepoint.