X25519MLKEM768: what it changes in TLS

Published 23 September 2026

X25519MLKEM768 is a hybrid key exchange for TLS 1.3. It combines the familiar X25519 elliptic-curve exchange with the post-quantum ML-KEM-768 mechanism. An attacker must break both parts to recover the session secret. It protects the confidentiality of recorded traffic from a future quantum computer; it does not, by itself, make the server's certificate or signature post-quantum.

The name is the useful part

Part	Job	Why it is there
X25519	Classical elliptic-curve key agreement	Keeps today's well-understood security even if ML-KEM later develops a weakness
ML-KEM-768	NIST-standardized post-quantum key encapsulation	Protects the exchange against a cryptographically relevant quantum computer
Hybrid result	TLS derives one secret from both contributions	Neither a classical-only nor quantum-only break is enough

The current IETF TLS working-group draft assigns X25519MLKEM768 supported group 0x11ec. The client sends a 1,216-byte key share: 1,184 bytes for ML-KEM and 32 for X25519. The server's share is 1,120 bytes. That is much larger than the 32-byte X25519 share it replaces, and the size is the first operational difference most networks will notice.

What it protects

In TLS 1.3, the key exchange creates the secret used to encrypt the connection. A passive attacker can record encrypted traffic now and hope to decrypt it after sufficiently capable quantum computers exist. This is the harvest now, decrypt later problem. A hybrid exchange makes a captured session depend on ML-KEM as well as X25519, so breaking X25519 in the future would not be enough.

That matters first for data with a long shelf life: health records, government material, trade secrets, private messages and credentials that must stay secret for years. It is less urgent for a weather response or a public software download. The protocol is the same; the lifetime of the secret changes the risk.

What it does not protect

A TLS handshake has two different cryptographic jobs. The key exchange establishes fresh session keys. The certificate signature authenticates the server. X25519MLKEM768 changes the first job only. A connection can negotiate this group while the certificate chain is still signed with RSA or ECDSA.

Operationally, post quantum TLS is therefore two migrations: key agreement for confidentiality and signatures for authentication. Treating them as one checkbox is how a hybrid handshake gets mistaken for an end-to-end quantum-safe identity.

Do not call the certificate post-quantum because the negotiated group is X25519MLKEM768. Post-quantum authentication needs a separate signature migration, such as ML-DSA, all the way through the certificate and trust ecosystem. Key agreement and authentication can move on different schedules.

It also does nothing for TLS 1.2. The hybrid group is a TLS 1.3 mechanism. If a middlebox or endpoint forces a downgrade to 1.2, the post-quantum key exchange disappeared with the protocol version.

It does not hide the hostname in the opening handshake either. That is a separate TLS 1.3 privacy mechanism; the Encrypted Client Hello test shows how to distinguish an advertised ECH configuration from one a client actually used.

Why a larger ClientHello can break a working path

A classical TLS 1.3 ClientHello with an X25519 share often fits in one TCP segment. Adding the ML-KEM public material commonly splits it across two. TCP permits that. TLS permits that. Some old firewalls, load balancers and inspection devices nevertheless behave as though the ClientHello must arrive in one packet.

The result is a distinctive failure: ordinary X25519 works, but offering the hybrid group causes a reset, timeout or handshake failure before the certificate is even sent. That is not evidence that ML-KEM mathematics failed. It is usually protocol ossification in the path.

The diagnosis belongs with the same packet-level discipline as any other SSL handshake failure: compare one successful and one failed ClientHello, identify who sent the first reset or alert, and do not start by replacing the certificate. If small handshakes work while the larger one vanishes, also check for the path-MTU failure pattern rather than assuming the endpoint rejected the algorithm.

How to test X25519MLKEM768

Use a client library that actually implements the final ML-KEM group. OpenSSL 3.5 added the standardized post-quantum algorithms and TLS group controls. First confirm the client knows the group, then offer it explicitly:

openssl version
openssl list -tls1_3 -tls-groups | grep X25519MLKEM768

openssl s_client \
  -connect example.com:443 \
  -servername example.com \
  -tls1_3 \
  -groups X25519MLKEM768

Read the negotiated temporary key or TLS group in the output. A successful TLS 1.3 connection proves the server and path accepted this group for this test. A successful connection without checking the negotiated group proves only that TLS found some mutually supported choice.

Test from the real client network as well as beside the server. A local success bypasses the exact proxy, firewall and WAN path most likely to mishandle the larger ClientHello. If a CDN terminates TLS, the browser-to-CDN and CDN-to-origin legs are separate handshakes and may negotiate different groups.

How to read the result operationally

Result	What it establishes	What it does not
X25519MLKEM768 negotiated	This TLS 1.3 key exchange is hybrid post-quantum	The certificate signature is post-quantum
X25519 negotiated instead	The connection has normal classical forward secrecy	The server is broken; the client may not have offered the hybrid
HelloRetryRequest	The first key-share guess did not match the server preference	The final handshake necessarily failed
Reset only with the hybrid offer	The larger or unfamiliar ClientHello triggers something	Which device triggered it; capture both sides

Should you enable it now?

For public services, start by measuring client and path compatibility, then enable the hybrid alongside classical groups rather than as the only choice. For origins behind a CDN, test the origin leg explicitly. Cloudflare now measures origin support and can select a preferred exchange per zone; that is useful because a wrong first guess produces a HelloRetryRequest and another round trip.

For private systems, inventory the TLS libraries before changing a policy. A load balancer may support the group while a service mesh, appliance or synthetic monitor does not. "The platform supports PQC" is not the same as "every TLS termination point in this path supports the same standardized group."

The practical migration order is simple: find the TLS endpoints, identify their libraries and versions, test the hybrid through the real network, watch fallback and failure rates, and keep authentication as a separate workstream. The Kodura SSL checker remains useful for the certificate-chain half of that job; it should not be read as a test of the negotiated post-quantum key exchange.

Sources

Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLS 1.3: IETF TLS working-group draft, group construction, code points and key-share sizes
FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard: NIST's ML-KEM standard
Post-quantum between Cloudflare and origin servers: split ClientHello behaviour and origin deployment
Automatic Key Exchange: Cloudflare, 8 September 2026; measurement, preference selection and HelloRetryRequest cost
OpenSSL 3.5 final release: standardized PQC algorithm and TLS group support

X25519MLKEM768 is still moving through the IETF publication process. The deployed group and NIST algorithm are real; implementation defaults and diagnostic output vary by library release. Commands and references were checked in September 2026.