From X25519 to X25519+MLKEM768: How Hybrid TLS Is Becoming Real

Abstract

Key Points at a Glance

• X25519 dominates TLS key exchange today—fast, 32-byte keys, constant-time by design—but Shor's algorithm on a future quantum computer will break it.
• ML-KEM-768 (formerly Kyber-768) is a lattice-based KEM standardised in NIST FIPS 203 ^[2], designed to resist both classical and quantum attacks.
• Hybrid mode combines both algorithms so that security holds as long as either one survives—a belt-and-suspenders approach currently being standardized in the IETF's TLS ML-KEM drafts ^[3].
• This is not theoretical: Chrome, Cloudflare, AWS, Apple iMessage, and Signal already ship hybrid TLS or related hybrid key exchange in production ^{[9][10][11][12][13]}.
• Handshake size grows ~38× (32 → 1,216 bytes for the key share), but operational impact is usually dominated by the larger handshake rather than computation time.
• BSI and NIST both recommend hybrid key exchange as the transitional best practice before full post-quantum migration ^[6][8], as discussed in our BSI Compliance report.

What Is X25519 and Why Did It Win?

Before we discuss the quantum threat, it helps to understand the algorithm we're upgrading from. X25519 is an elliptic-curve Diffie–Hellman (ECDH) function operating on Curve25519, designed by Daniel Bernstein in 2006. Its design philosophy was radical for the time: make the fastest possible key exchange that is also impossible to implement incorrectly. Bernstein achieved this by choosing a Montgomery curve that forces all implementations into constant-time arithmetic, eliminating an entire class of side-channel attacks by construction.

The result? A public key is just 32 bytes. A full key exchange completes in microseconds. There are no negotiable parameters to get wrong, no padding oracles to exploit, and no special cases to handle. This simplicity is why TLS 1.3 made X25519 one of only two mandatory-to-implement key exchange groups, effectively retiring the older, larger finite-field Diffie–Hellman groups and RSA key transport ^[5].

In a TLS 1.3 handshake, the client sends its X25519 public key in the ClientHello, the server responds with its own, and both sides derive the same shared secret. This secret feeds into TLS's key derivation function to produce session keys. Because each connection generates fresh ephemeral keys, even compromising the server's long-term private key cannot reveal past sessions—a property called forward secrecy. For a deeper look at how key exchange and digital signatures play different roles in TLS, see our article on Key Exchange vs. Digital Signatures.

Why X25519 Alone Is No Longer Enough

X25519's security rests on the elliptic-curve discrete-logarithm problem (ECDLP): given a point Q = kG on Curve25519, it is computationally infeasible to recover the scalar k. On classical hardware this remains true—but Shor's algorithm ^[7], running on a sufficiently powerful quantum computer, solves ECDLP in polynomial time. When that machine arrives, every X25519 key exchange ever recorded becomes retroactively breakable.

This is the core of the harvest-now, decrypt-later (HNDL) threat: adversaries passively capture encrypted TLS traffic today and archive it, waiting for the day quantum hardware can extract the session keys. Any data that needs to remain confidential into the 2030s is already at risk. As we explored in that article, intelligence agencies have been observed diverting encrypted internet traffic at scale—creating exactly the kind of ciphertext vault the HNDL model predicts.

The expert consensus is sobering: 22.7% of cryptography researchers expect RSA-2048 to fall by 2030, and 50% say no later than 2035. X25519 offers even less quantum resistance than RSA-2048 due to the structure of elliptic curves. For a full vulnerability analysis of TLS 1.3 under quantum attack—including how the handshake, key exchange, and authentication are each affected—see our detailed report on TLS 1.3 Quantum Vulnerabilities and Hybrid Defences.

Enter ML-KEM-768: How a Post-Quantum KEM Works

ML-KEM-768 (Module-Lattice-Based Key Encapsulation Mechanism, Security Level 3) is one of the first post-quantum algorithms standardised by NIST in FIPS 203 ^[2] (August 2024). Formerly known as CRYSTALS-Kyber, it belongs to the family of lattice-based cryptography—schemes whose security derives from the difficulty of solving the Module Learning With Errors (MLWE) problem. No known quantum algorithm can solve MLWE efficiently, which is what makes it a candidate for the post-quantum era.

But ML-KEM-768 is not just a drop-in replacement for X25519—it works fundamentally differently. X25519 performs an interactive Diffie–Hellman exchange: both parties contribute ephemeral public keys and jointly compute a shared secret. ML-KEM, by contrast, is a Key Encapsulation Mechanism (KEM): the sender uses the recipient's public key to encapsulate a random shared secret into a ciphertext, and only the holder of the matching private key can decapsulate it. The result is the same—both sides share a secret—but the mechanism is asymmetric rather than interactive.

The size difference is significant—ML-KEM-768's public key is 37× larger than X25519's. This is the price of quantum resistance: lattice problems require larger mathematical objects. However, the computational overhead is generally modest on modern hardware; in practice, deployment concerns are more often driven by message size and compatibility than by raw ML-KEM computation time. For detailed performance benchmarks including FrodoKEM and Classic McEliece, see our BSI-Compliant Post-Quantum Key Exchange report.

The Hybrid Approach: Belt and Suspenders

If ML-KEM-768 is quantum-safe, why not simply replace X25519 with it? The answer is conservative cryptographic engineering. ML-KEM has been studied intensively since its selection by NIST in 2022, but lattice-based cryptography is still young compared to elliptic curves' four-decade track record. What if a breakthrough in lattice cryptanalysis weakens or breaks MLWE? If we had already abandoned X25519, we'd be left with nothing.

The hybrid approach solves this by running both key exchanges in parallel and combining their outputs. In a hybrid TLS handshake using X25519MLKEM768 ^[3], the client's ClientHello carries a single combined key share: the client's 1,184-byte ML-KEM-768 encapsulation key together with its 32-byte X25519 ephemeral share, for a total of 1,216 bytes. The server responds with its own combined value: a 1,088-byte ML-KEM ciphertext plus a 32-byte X25519 ephemeral share, totaling 1,120 bytes. The two resulting shared secrets are concatenated and then fed into the normal TLS 1.3 key schedule.

The security guarantee is simple: an attacker must break both X25519 and ML-KEM-768 to compromise the session. If quantum computers break X25519, ML-KEM-768 still protects the data. If a classical cryptanalytic breakthrough weakens ML-KEM, X25519 still holds. This is why hybrid deployment is widely recommended during the transition period by government and industry guidance, including BSI TR-02102-1 ^[6] and broader post-quantum migration guidance from NIST ^[8].

This hybrid key exchange is currently being standardized in the IETF's TLS ML-KEM work ^[3], including the draft that defines the X25519MLKEM768 named group for TLS 1.3. The current draft specifies how the combined client and server key exchange values are encoded and how the shared secret is formed, which is what enables interoperable implementations. For a visual diagram of how the hybrid key exchange works mechanically, see Figure 3 in our TLS 1.3 Quantum Vulnerabilities article.

Who's Already Shipping Hybrid TLS?

Unlike many cryptographic transitions that remain theoretical for years, hybrid TLS has moved from draft specification to production deployment with remarkable speed. Here is where adoption stands as of early 2026, based on public deployment announcements and standards-track documents.

The speed of adoption reflects a shared urgency across the industry. Chrome's rollout ^[10] made hybrid post-quantum key agreement visible at Internet scale, while Cloudflare ^[9] has repeatedly emphasized that the main operational trade-off is the larger handshake and the compatibility issues it can expose in middleboxes or legacy infrastructure.

Beyond TLS, the hybrid approach has also influenced secure messaging protocols: Signal's PQXDH protocol ^[12] and Apple's PQ3 ^[11] both combine post-quantum and classical components to protect message confidentiality against future quantum decryption. For a broader survey of post-quantum deployments across different industries, see our PQC Real-World Examples article.

Practical Challenges You'll Hit

Hybrid TLS is production-ready, but the transition is not entirely painless. Here are the most common issues operators encounter.

For most deployments, the transition is straightforward. If you're running a recent version of OpenSSL (3.5+) ^[14], BoringSSL, or wolfSSL, enabling hybrid key exchange is a configuration change:

The exact server configuration syntax depends on your TLS stack and how it exposes OpenSSL group selection. Treat the following snippets as illustrative examples rather than universal copy-paste commands.

The key principle is to prefer X25519MLKEM768 while keeping X25519 available as a fallback for clients that do not yet support hybrid. This ensures a graceful degradation path.

What Comes Next After Hybrid KEM?

Hybrid key exchange solves the most urgent problem—protecting confidentiality against harvest-now-decrypt-later attacks. But TLS relies on two cryptographic pillars, and we have only upgraded one. The second pillar, authentication via digital signatures, still uses classical RSA and ECDSA. As discussed in our Key Exchange vs. Signatures analysis, this is acceptable for now because a future quantum break of a signature doesn't retroactively compromise past sessions. But eventually, certificates too must be migrated.

NIST has standardised two post-quantum signature schemes: ML-DSA (FIPS 204 ^[15], formerly Dilithium) and SLH-DSA (FIPS 205 ^[16], formerly SPHINCS+). However, PQ signatures bring significant size challenges: an ML-DSA-65 public key is 1,952 bytes and a signature is 3,309 bytes, compared to ECDSA-P256's 64-byte signature. This means certificates containing PQ signatures will be substantially larger, impacting handshake size even further.

Looking further ahead, the industry may eventually transition from hybrid key exchange to standalone post-quantum groups such as ML-KEM, dropping the X25519 component once confidence in lattice-based cryptography and interoperability is sufficiently high. But that day is years away—the conservative approach of hybrid mode is likely to persist through the 2030s.

References

1. Bernstein, D.J. (2006). Curve25519: new Diffie-Hellman speed records. https://cr.yp.to/ecdh
2. NIST (2024). FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard. https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.203.pdf
3. IETF (2026). draft-ietf-tls-ecdhe-mlkem: Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLS 1.3. https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/
4. IETF (ongoing). draft-ietf-tls-mlkem: ML-KEM Post-Quantum Key Agreement for TLS 1.3. https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/
5. IETF (2018). RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3. https://datatracker.ietf.org/doc/html/rfc8446
6. BSI (2025). TR-02102-1: Cryptographic Mechanisms. https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.html
7. NIST (2016). IR 8105: Report on Post-Quantum Cryptography. https://csrc.nist.gov/pubs/ir/8105/final
8. NIST. IR 8547 (Initial Public Draft): Transition to Post-Quantum Cryptography Standards. https://csrc.nist.gov/pubs/ir/8547/ipd
9. Cloudflare (2024). Post-quantum cryptography implementation considerations for TLS and related deployment updates. https://blog.cloudflare.com/post-quantum-zero-trust/
10. Chromium Blog (2024). Advancing Our Amazing Bet on Asymmetric Cryptography. https://blog.chromium.org/2024/05/advancing-our-amazing-bet-on-asymmetric.html
11. Apple Security Research (2024). iMessage with PQ3: The New State of the Art in Quantum-Secure Messaging at Scale. https://security.apple.com/blog/imessage-pq3/
12. Signal (2023). Quantum Resistance and the Signal Protocol. https://signal.org/blog/pqxdh/
13. AWS KMS Documentation (2026). Using hybrid post-quantum TLS with AWS KMS. https://docs.aws.amazon.com/kms/latest/developerguide/pqtls.html
14. OpenSSL 3.5 Documentation: SSL_CTX_set1_groups. https://docs.openssl.org/3.5/man3/SSL_CTX_set1_groups/
15. NIST FIPS 204: Module-Lattice-Based Digital Signature Standard (ML-DSA). https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.204.pdf
16. NIST FIPS 205: Stateless Hash-Based Digital Signature Standard (SLH-DSA). https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.205.pdf
17. NSA: Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) FAQ. https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0_FAQ_.PDF
18. NCSC (2025). Timelines for migration to post-quantum cryptography. https://www.ncsc.gov.uk/guidance/pqc-migration-timelines