Skip to content
Quantum Defense

Home / Learn / Practitioner / Lesson 8

Part II, Practitioner · Lesson 8

Hybrid key exchange: post-quantum TLS today

By Kyeson Blake Utley14 min read1 interactiveSome tech background
The short version

When your browser connects to a website, the two sides secretly agree on a key. Today many of them agree on it twice at once, using an old method and a new quantum-resistant method, and mix both answers together. A thief would have to break both locks. The new lock is bigger, so a few old network boxes that expect small messages get confused.

You'll learn to

  • Explain what a hybrid key exchange is and why it combines a classical and a post-quantum algorithm.
  • Describe X25519MLKEM768 in TLS 1.3, including its sizes and where it is deployed by default.
  • Separate the key-exchange migration from the certificate migration and say why the first is more urgent.
  • List the practical deployment problems (middleboxes, terminators, libraries) and how to check a connection.

If you read this page in a current browser over a modern connection, there's a good chance the key that encrypts it was agreed using ML-KEM. Post-quantum key exchange is not a future project for the web; it shipped. This lesson explains what shipped, why it's "hybrid", and what it means for the systems you run.

Two jobs inside every TLS handshake

Transport Layer Security (TLS) is the protocol behind HTTPS and much else. In TLS 1.3, the opening handshake does two separate things with public-key cryptography:

  1. Key exchange. Client and server agree on fresh session keys. Today this is usually elliptic-curve Diffie-Hellman with X25519.
  2. Authentication. The server proves it's really the site you asked for, using its certificate and a signature (RSA or ECDSA, typically).

These two migrate on different schedules. Key exchange is threatened now: anyone who records the handshake and the encrypted traffic today can decrypt it once a cryptographically relevant quantum computer (CRQC) exists. That is harvest now, decrypt later. Authentication only matters at the moment of connection: a future quantum computer can't go back and impersonate a server to a connection that already happened. So the web fixed key exchange first, and is still working out certificates (lesson 12).

What "hybrid" means

A hybrid key exchange runs a classical key exchange and a post-quantum one side by side, then feeds both shared secrets into the key derivation. The IETF's terminology document (RFC 9794) calls this a "post-quantum/traditional" or PQ/T hybrid.

The logic is belt and braces. If ML-KEM someday turns out to have a flaw (a cryptanalytic break, or simply a bug in a young implementation), X25519 still protects you against today's attackers. If a quantum computer arrives, ML-KEM still protects you against it. An attacker has to break both. Given that SIKE survived years of scrutiny before falling to a classical attack in 2022, this caution is well earned.

The cost is small: X25519 adds 32 bytes to each side's message, and a little computation.

X25519MLKEM768, byte by byte

The hybrid that the web settled on is called X25519MLKEM768. It is a TLS 1.3 "named group" (the slot in the handshake where the key exchange is chosen), with code point 0x11EC, and it is specified in RFC 10024, published in 2026. The same document defines two siblings for environments that need NIST curves: SecP256r1MLKEM768 and SecP384r1MLKEM1024.

  • The client's ClientHello carries a 1,216-byte key share: a 1,184-byte ML-KEM-768 encapsulation key plus a 32-byte X25519 public key.
  • The server's ServerHello replies with 1,120 bytes: a 1,088-byte ML-KEM ciphertext plus its own 32-byte X25519 key.
  • Both sides combine the ML-KEM secret and the X25519 secret, and the TLS key schedule turns them into session keys.

Compare that with plain X25519: 32 bytes each way. The hybrid adds about 2.3 KB to the handshake in total. That's nothing for a web page, but enough to upset equipment that assumed a ClientHello always fits in one small packet.

Who already does this

Deployment moved quickly once the standards settled:

  • Chrome added the pre-standard hybrid X25519Kyber768 in Chrome 116 (August 2023), turned it on by default in Chrome 124 (April 2024), and switched to the standardized X25519MLKEM768 in Chrome 131 (November 2024). Google chose not to support both at once, so the old code point (0x6399) was retired.
  • Firefox uses X25519MLKEM768 by default from version 132 on desktop. Edge and other Chromium-based browsers follow Chrome.
  • Apple devices advertise X25519MLKEM768 by default for TLS-protected connections in iOS 26, iPadOS 26, macOS Tahoe 26 and visionOS 26.
  • OpenSSL 3.5 (released 8 April 2025) added ML-KEM, ML-DSA and SLH-DSA, and its default TLS key shares now offer X25519MLKEM768 and X25519. Go 1.24 and recent Node.js releases also enable it by default.
  • Beyond TLS: OpenSSH made the hybrid sntrup761x25519-sha512 its default in version 9.0 (2022) and switched to mlkem768x25519-sha256 in 10.0 (April 2025). Signal added its PQXDH protocol in September 2023, and Apple announced iMessage PQ3 in February 2024.

The upshot: if your users run current browsers and your edge (a CDN, load balancer or web server) runs a current TLS library, a large share of your public HTTPS traffic may already be hybrid. The gaps are usually elsewhere.

What breaks, and where

Middleboxes with hard-coded limits

When Chrome began deploying the hybrid in 2023, Google noted that its earlier experiments had shown "the vast majority" of TLS implementations coped with the bigger ClientHello, but that some TLS middleboxes (firewalls, proxies and inspection appliances) failed because of improperly hard-coded message-size restrictions. Chrome provided an enterprise policy, PostQuantumKeyAgreementEnabled, to switch the hybrid off temporarily while vendors fixed their products. Apple's guidance for its OS 26 releases similarly warns that devices may fail to connect to some legacy servers whose TLS implementations can't read large ClientHello messages.

The lesson for practitioners: test your network path, not just your servers. A TLS-inspecting proxy that can't parse a 1.2 KB key share silently forces everyone behind it back to classical key exchange, or breaks connections outright.

The termination point decides

Post-quantum protection lasts only as far as the TLS session. If a CDN or load balancer terminates TLS and then opens a new connection to your origin server, that second hop has its own key exchange. Each hop needs checking: browser to edge, edge to origin, service to service, and anything that leaves your network, such as partner APIs, payment processors and backups to cloud storage.

Extra round trips when guesses miss

In TLS 1.3 the client guesses which key exchange the server will accept and sends a key share for it up front. If the server doesn't support that group, it answers with a HelloRetryRequest and the client tries again, costing a round trip. Many clients send both a hybrid share and a plain X25519 share to avoid this, which is exactly what OpenSSL 3.5's defaults do.

How to check your own systems

  • Browsers. The widget above uses Cloudflare's /cdn-cgi/trace endpoint, which reports the negotiated key exchange as a kex= line on sites served through Cloudflare.
  • Command line. With OpenSSL 3.5 or later, openssl s_client -connect example.com:443 -groups X25519MLKEM768 offers only the hybrid, so a successful handshake proves the server supports it. On macOS Tahoe 26, Apple documents nscurl --tls-diagnostics for the same check.
  • Servers and appliances. Find out which TLS library and version each terminator uses. Support depends on the library, not on your certificate.
  • Internal traffic. Service meshes, databases, message queues and VPNs each have their own crypto settings. They'll show up in your cryptographic inventory.

A short action list

  1. Upgrade TLS terminators to libraries that support X25519MLKEM768, starting with internet-facing ones that carry long-lived sensitive data.
  2. Test through your real network path, including inspection proxies, and file bugs with vendors whose boxes choke.
  3. Check the second hop behind every CDN and load balancer.
  4. Move SSH to OpenSSH 10 or later (or confirm a hybrid default) and ask VPN vendors for their post-quantum roadmap.
  5. Record what you find. The deadlines in the next lesson assume you know where you stand.

Summary

  • TLS does key exchange and authentication; key exchange is urgent because of harvest-now-decrypt-later.
  • Hybrid key exchange combines X25519 and ML-KEM-768 so an attacker must break both.
  • X25519MLKEM768 (code point 0x11EC) adds 1,216 bytes to the ClientHello and 1,120 to the ServerHello.
  • Chrome, Firefox, Apple's OS 26 releases and OpenSSL 3.5 enable it by default; OpenSSH 10.0 defaults to mlkem768x25519-sha256.
  • Middleboxes with hard-coded size limits and unchecked second hops are the usual gaps.

Questions

Get five of six right to mark the lesson complete. They also feed the final exam.

Sources

CourseQuantum Defense
Sheet8 of 18
PartII · Practitioner
Rev.18 Oct 2026
Sources9 cited
Found an error?Send a correction