Hybrid TLS guide · updated 4 November 2026

X25519MLKEM768 and post-quantum TLS

X25519MLKEM768 is the hybrid key exchange that browsers and most big sites already use in TLS 1.3, and it's what you want your own servers to offer. It runs X25519 and ML-KEM-768 side by side, so a session you record today stays private even if one of the two is broken later. Below is the one command we use to see whether a server negotiates it, and the handshake sizes we measured ourselves.

Read the guide Run Quantum Core

Client key sharet = live

1216

X25519ML-KEM-768group 4588TLS 1.3

What the name means

The name is just its two halves glued together. X25519 is the elliptic-curve exchange that most TLS 1.3 connections probably use right now. ML-KEM-768 is the lattice key encapsulation NIST standardised in FIPS 203, and I've compared it with the signature standards in ML-KEM, ML-DSA and SLH-DSA. Your browser sends a key share for each half, the server answers both, and the two shared secrets are combined into one key, so anyone who wants to read the session has to break X25519 and ML-KEM-768 at once.

You'll find it in the IETF draft on hybrid ECDHE-MLKEM key agreement. IANA has registered it as TLS supported group 4588 (0x11EC). However, if you have to stay on NIST curves, the same draft also defines SecP256r1MLKEM768 and SecP384r1MLKEM1024, which I'd expect regulated shops to use.

Why key exchange comes first

If you only fix one thing this year, make it the key exchange, because that's the part of TLS that harvest now, decrypt later attacks: someone records your traffic today and decrypts it once a large quantum computer exists, which means anything that has to stay secret for ten years is exposed already. Certificates and signatures matter as well, but nobody can go back and forge a signature on a handshake that has already happened. That's why NIST's migration deadlines put post-quantum key establishment ahead of post-quantum signatures, and it's why the browsers changed their key exchange before anything else.

Check a server from the command line

You'll need OpenSSL 3.5 or later, since that's the first release whose default key shares offer X25519MLKEM768. If you're on a Mac, don't trust /usr/bin/openssl: on ours it's LibreSSL 3.3.6, which doesn't know the group at all, so we used the Homebrew build. Ask for the hybrid first and plain X25519 as the fallback:

echo | openssl s_client -connect example.com:443 -servername example.com \
  -groups X25519MLKEM768:X25519 -brief

When the server supports it, you'll see this:

Protocol version: TLSv1.3
Negotiated TLS1.3 group: X25519MLKEM768

When it doesn't, the handshake quietly falls back and you get Peer Temp Key: X25519, 253 bits instead. If you'd rather it failed outright on servers without the hybrid, pass -groups X25519MLKEM768 on its own.

In Chrome you can open DevTools, go to the Security tab and read the key exchange in the connection details. Chrome switched from the pre-standard Kyber draft to ML-KEM in Chrome 131.

What we found on 4 November 2026

We ran that command with OpenSSL 4.1.0 against nine well-known sites, and here's what each one negotiated.

Server	Group negotiated
functorfund.com	X25519MLKEM768
cloudflare.com	X25519MLKEM768
www.google.com	X25519MLKEM768
www.amazon.com	X25519MLKEM768
www.microsoft.com	X25519MLKEM768
www.apple.com	X25519MLKEM768
www.gov.uk	X25519MLKEM768
github.com	X25519 only
www.bbc.co.uk	no answer on port 443 from our network that night

Bear in mind that one run from one network only tells you what each site's edge offered at that moment. It tells you nothing about the services behind that edge, which usually keep TLS settings of their own. I was a little surprised by GitHub.

What it costs on the wire

We traced the same handshake to functorfund.com twice, once with each group, and counted the bytes.

Bytes	X25519	X25519MLKEM768
Client key share	32	1,216
Server key share	32	1,120
ClientHello	329	1,507
ServerHello	118	1,206

The client's share is a 1,184-byte ML-KEM-768 encapsulation key followed by its 32-byte X25519 key (the IETF draft fixes that order for this group), and the server sends back a 1,088-byte ML-KEM ciphertext plus its own 32-byte X25519 key. At 1,507 bytes our ClientHello no longer fits in a typical 1,500-byte packet. Google said after its earlier trials that most TLS software coped with the bigger message but a few middleboxes broke because they'd hard-coded a limit on message size, and that's the main thing that can go wrong for you, which is why we'd keep the X25519 fallback while you roll it out.

Turning it on

If your TLS ends at a large CDN, it's probably on already, as the table suggests. If you run your own servers, a web server built against OpenSSL 3.5 or later should offer the hybrid with its default group settings, and we checked that locally: an OpenSSL 4.1.0 test server and client, neither given any group options, negotiated X25519MLKEM768. What's worth looking for is an explicit group or curve list in your configuration, because a list somebody wrote years ago for X25519 and P-256 will leave the hybrid out.

The harder job is finding every other place that does its own key exchange, such as internal services, SDKs, VPNs and code that calls a crypto library directly. A CBOM is how you'd record them, and Quantum Core scans a repository on your machine and lists each classical key exchange it finds, with the file and line.

Is X25519MLKEM768 the same as X25519Kyber768?

No. X25519Kyber768 used a draft of Kyber under group 25497 (0x6399), while X25519MLKEM768 uses the final ML-KEM standard under group 4588, and the two don't interoperate.

Does post-quantum TLS need a new certificate?

Not for the key exchange. The hybrid works with the RSA and ECDSA certificates you have now, and post-quantum certificates are a separate step that comes later.

Is the hybrid weaker than plain X25519?

No. The session key depends on both secrets, so you'd have to break X25519 and ML-KEM-768 to recover it. As far as I know nobody has managed either.