Why We Run Two Key Exchanges at Once

When a standard like ML-KEM is finalized, the obvious move is to swap out the old key exchange and move on. The internet is not doing that. The migration happening on live traffic right now is hybrid: the session key is derived from a classical exchange and a post-quantum one at the same time, so that breaking either alone breaks nothing.

This is not a transitional hedge to be discarded later. It is a deliberate security design, and it is worth understanding why the most security-conscious operators chose it.

What hybrid actually means

A hybrid key agreement runs two key exchanges in parallel and combines their outputs into one shared secret. The construction now widely deployed is X25519MLKEM768, which pairs classical X25519 elliptic-curve Diffie-Hellman with ML-KEM-768. Recent versions of the major browsers, OpenSSL, Go, and Apple operating systems enable it by default, and Cloudflare reports that by mid-September 2025 roughly 43% of human-generated connections to its network were already protected by it (Cloudflare, State of the post-quantum internet in 2025; PostQuantumSecurity.org).

The security property is simple to state: the session stays confidential unless both X25519 and ML-KEM are defeated. If a future quantum computer breaks X25519, ML-KEM still holds. If cryptanalysis or, far more likely, an implementation bug weakens the lattice scheme, X25519 still holds.

Why not just replace

The case for hybrid is humility about new cryptography. ML-KEM rests on well-studied mathematics, but it is young as deployed code, and the history of cryptographic failure is overwhelmingly a history of implementation mistakes — side channels, bad randomness, parsing bugs — not breaks in the underlying problem. Going pure post-quantum means betting confidentiality on the correctness of new, complex software with a short track record. Hybrid removes that single point of failure: a flaw in the lattice implementation no longer exposes the session on its own, because the classical component still has to be defeated.

This is exactly the reasoning behind our own PHANTOM Protocol, which pairs ML-KEM (Kyber-1024) with X25519 for the same reason the public internet did: neither component should be trusted alone yet.

What it costs

Hybrid is not free, and the costs are concrete rather than theoretical. Cloudflare's measurements put the overhead at about 1,088 additional bytes in the ClientHello and roughly 10 to 20 milliseconds of additional median latency versus a classical X25519 handshake (Cloudflare). The larger payload is the more interesting number, because it can push the handshake across packet-size boundaries and has, in practice, exposed brittle middleboxes. Google enabled hybrid key exchange by default in Chrome 124 in April 2024, then had to roll it back after enterprise network equipment choked on the larger handshakes, before it returned. That episode is the real lesson of post-quantum deployment: the mathematics was never the hard part. The hard part is a decade of accumulated infrastructure that assumed keys were small.

For a messaging protocol or any system establishing long-lived confidential channels, the calculus is straightforward. A kilobyte and a few milliseconds is a trivial price against the alternative, which is trusting either a fifty-year-old curve against a future quantum machine or brand-new lattice code against the ordinary bugs that have always been how cryptography actually breaks.

Sources

• Cloudflare, "State of the post-quantum internet in 2025": https://blog.cloudflare.com/pq-2025/
• PostQuantumSecurity.org, "From X25519 to X25519+MLKEM768": https://www.postquantumsecurity.org/publications/X25519+MLKEM768.html
• Cloudflare SSL/TLS docs, "Post-quantum cryptography": https://developers.cloudflare.com/ssl/post-quantum-cryptography/