What is hybrid X25519+ML-KEM key exchange and why is it the default of the transition?

As of November 8, 2026, the default key exchange of the post-quantum transition is a hybrid: X25519MLKEM768, a TLS 1.3 group that runs classical X25519 and post-quantum ML-KEM-768 side by side in the same handshake and splices both secrets into one key. It is what Chrome has shipped by default since version 124 (April 2024, as X25519Kyber768; the final ML-KEM form arrived with Chrome 131 in November 2024), what Firefox 132 shipped on October 29, 2024, and what OpenSSL 3.5.0 has preferred by default since April 8, 2025. Rosetta Quantum measures what actually ships: the client sends 1,216 bytes of key material, the server answers with 1,120, and an attacker has to break both locks at once. The public record still shows 0 RSA-2048 keys broken by a quantum computer and 0 breaches attributed to a quantum attack (re-verified 2026-11-08) — the hybrid is insurance in both directions, not evidence of an ongoing attack. One more measured fact: the spec everyone deploys is still an Internet-Draft (draft-ietf-tls-ecdhe-mlkem-05, May 26, 2026), not an RFC. Our byte-budget piece promised that the mechanics of this handshake would get their own entry; this is it.

What exactly is X25519MLKEM768?

It is a single TLS 1.3 named group — IANA code point 4588 (0x11EC) — that performs two independent key agreements inside one handshake: X25519, the elliptic-curve Diffie-Hellman in wide deployment across the web since the 2010s, and ML-KEM-768, the lattice-based key encapsulation mechanism NIST standardized as FIPS 203 on August 13, 2024 (our standards piece covers the family: ML-KEM, ML-DSA and SLH-DSA). The two shared secrets are concatenated — ML-KEM's 32 bytes first, then X25519's 32 bytes, a 64-byte block — and fed together into the TLS key schedule (draft-ietf-tls-ecdhe-mlkem-05, 2026-05-26). The session key is secure as long as at least one of the two components holds. That is the entire design: no new mathematics, just two proven key agreements welded so that each covers the other's failure mode.

How does the hybrid handshake work, byte by byte?

In one round trip, same as before — the cost is width, not latency. The client's key_share for X25519MLKEM768 is 1,216 bytes: the ML-KEM-768 encapsulation key (1,184 bytes) concatenated with the X25519 public share (32 bytes). The server encapsulates against that key and answers with 1,120 bytes: the ML-KEM ciphertext (1,088 bytes) plus its own 32-byte X25519 share. Both sides then hold the same 64-byte concatenated secret (all sizes: draft-ietf-tls-ecdhe-mlkem-05, 2026-05-26). Compare the classical baseline this replaces: 32 bytes each way. The hybrid multiplies the key-exchange bytes by roughly 38 in the ClientHello — and in practice Chrome measured about a 1 KB median increase and ≈4% slower TLS handshakes when it turned the hybrid on, the deployment numbers we walked through in the byte-budget piece. The oversized ClientHello is also what broke buggy middleboxes when Chrome 124 flipped the default in April 2024 (BleepingComputer, 2024-04-28): hardware that assumed a hello fits in one packet dropped the connection. That episode is why «can your stack carry a 1.2 KB key share» is now a real procurement question.

Why hybrid, instead of trusting ML-KEM alone?

Because the industry has already watched a post-quantum candidate die in production-adjacent conditions — and the hybrid wrapper is what made that a non-event. In October 2019, Cloudflare and Google Chrome ran the TLS Post-Quantum Experiment: CECPQ2 (X25519 + NTRU-HRSS) and CECPQ2b (X25519 + SIKE) on live connections (Cloudflare blog, 2019-10-30). In 2022, SIKE was broken outright by a classical attack running on ordinary hardware — the full story is in our SIKE and Rainbow piece. Every CECPQ2b connection stayed safe, because X25519 was still underneath. That is the first direction of the insurance: if the new math fails, the old math holds. The second direction is harvest-now-decrypt-later (our HNDL piece): traffic recorded today would become readable if a cryptographically relevant quantum computer arrives within the data's useful life — a future-tense risk category, not a documented present-day practice of any named actor. The ML-KEM half is the one that will matter against that future machine; X25519 alone would not. For calibration, Rosetta's standing Q-Day bet — floor 2031, window 2033–2039 (RQ-PRED-QDAY-001) — is a sealed, refutable judgment, not a measurement; the measured record remains 0 RSA keys broken. Hybrid is also crypto-agility practiced rather than preached: the mechanism that let Chrome swap Kyber-draft for final ML-KEM in seven months without breaking anything is the same one that would let it swap ML-KEM out.

Who ships it today — and since when?

Every major browser, OpenSSL, and Cloudflare's network — plus, outside TLS, two heavily scrutinized messengers that use the same hybrid pattern. The dated record:

Two readings of that table matter more than any single row. First, the client side of the web arrived without asking anyone's permission: if your users run a current browser, most of your inbound TLS is already offering the hybrid — that is how ≈70% of human traffic on one large network came to negotiate PQC by September 2026. Second, the messaging column shows the same architecture chosen independently twice: Signal mixes SPQR's ML-KEM-768 output with the classical Double Ratchet so that an attacker must break both (signal.org, 2025-10-02), and Apple's PQ3 combines Kyber with elliptic-curve cryptography (The Hacker News, 2024-02-22). Nobody shipping at scale trusts either lock alone.

Is the thing everyone deploys actually a standard yet?

No — and that is a measured, slightly uncomfortable fact worth stating plainly: the default key exchange of the post-quantum transition is specified by an Internet-Draft, not an RFC. The document — draft-ietf-tls-ecdhe-mlkem-05, authored at PQShield, AWS, Cloudflare and the University of Waterloo — is standards-track in the IETF TLS working group, was published on May 26, 2026, and will expire on November 27, 2026 unless a revision or an RFC lands first; we will re-verify in its day. It also formally obsoletes the pre-standard Kyber code points (25497, 25498) that early Chrome and Cloudflare deployments used. The draft defines three hybrid groups:

The fine-print detail with budget consequences: X25519 is not a FIPS-approved curve, so shops bound to FIPS-validated cryptography on both halves of the exchange will reach for SecP256r1MLKEM768 — 33 bytes wider per client share, and far less widely deployed. Which group your vendors actually negotiate is a one-line question with a checkable answer: the group name and code point appear in the handshake.

What does a security team do with this?

Four moves, in the order the measurements suggest. First, locate yourself on the asymmetry: browsers already offer the hybrid, but Cloudflare's scans found only ≈15% of origin servers supporting any PQC key agreement as of September 29, 2026 — the gap is almost certainly on your server, CDN and load-balancer side, not your users' side. Second, make «which named group, which code point» a standing vendor question; «quantum-safe» as a label answers nothing that 4588 answers precisely. Third, put TLS termination points at the top of the cryptographic inventory that every regulator's step 1 already asks for (the CBOM piece): key exchange is the part of the migration where the standards, the defaults and the measured deployments will carry most of the work for you. Fourth, calibrate urgency with regulatory clocks rather than Q-Day forecasts: NIST IR 8547, final since October 27, 2026, will deprecate RSA and ECC after 2030 and disallow them after 2035 — those dates are published policy, not predictions. What will NOT do any of this work is panic: 0 broken keys, 0 attributed breaches, re-verified today on the Rosetta board.

What we don't know

We don't know when the RFC will land: draft-05 expires on November 27, 2026, and we found no published successor as of this writing — if a revision or RFC appears, it will be news and we will date it. We don't know that ML-KEM is unbreakable: no public cryptanalytic break exists as of today, and the absence of an attack is not a proof — which is precisely the argument for the X25519 backstop. We don't know PQ adoption beyond the networks that publish measurements: the ≈70%/≈15% pair is Cloudflare's lens (2026-09-29), one large network, not the whole Internet. We don't know Apple's current internal algorithm naming: PQ3 was announced with «Kyber» in February 2024, before FIPS 203 was final, and our sources for it are the press coverage and the February 2024 Stebila analysis, both predating the final standard. We also did not re-verify Signal's PQXDH launch month from a primary source today — our secondary dates it to 2023. Finally, the jurisdiction-by-jurisdiction map of which sectors will face a binding PQC deadline (and which only guidance) will get its own piece in this series.

Rosetta Quantum publishes verdicts with raw, reproducible data. This is educational content — not a product claim, not vendor advice, not investment advice.