What Is X25519MLKEM768? Post-Quantum Hybrid Key Exchange for TLS 1.3

X25519MLKEM768 is an algorithm designed to survive quantum computers. Every time you connect to a website over HTTPS, there is a good chance the cryptographic key protecting that session was built using X25519MLKEM768.

You probably did not notice, by design: the hybrid key exchange powering modern TLS 1.3 connections is quietly upgrading the internet's security without breaking anything.

Learn what this hybrid group is, how post-quantum hybrid mechanisms work, and why network security teams should care about the supported groups negotiated inside every TLS handshake.

Why This Post-Quantum Key Agreement Matters for Network Security

If you are responsible for enterprise network security, this is the post-quantum key agreement mechanism you need to understand

X25519 is vulnerable to Shor's algorithm when quantum computers become powerful enough to break elliptic curve cryptography. The ML KEM part protects against that future. But if ML KEM turns out to have a classical weakness, the X25519 part keeps you safe today.²² This hybrid key exchange ensures security if one algorithm remains secure. 

Every TLS 1.3 connection negotiating X25519MLKEM768 from the supported groups list is already protected. Your key shares carry both classical and quantum-resistant material. The ECDHE share and the ML KEM portion each contribute to the final shared secret independently.

The serialized value of each share follows strict formatting rules. The ML KEM ciphertext and ephemeral key shares must match expected lengths exactly, or the connection aborts. This strictness is what makes the based key encapsulation mechanism integration reliable at internet scale.

The ML KEM part of the hybrid key exchange follows NIST guidelines for secure KEMs, and the National Institute has provided comprehensive guidance in SP 800-227 on how post-quantum cryptography combiners should work.²³

For organizations running TLS 1.3 across their infrastructure, to migrate: 

1. Update your supported groups configuration to include X25519MLKEM768. 

2. Ensure your TLS libraries support the new key exchange group. 

3. Verify your systems handle the larger client share and server share sizes.

How X25519MLKEM768 Hybrid Key Exchange Works

X25519MLKEM768 is a hybrid key exchange mechanism that combines two completely different cryptographic approaches into one handshake.¹

The first component is X25519, a widely trusted elliptic curve Diffie-Hellman exchange. X25519 has been the backbone of secure key exchange on the internet for years. It is fast, well-studied, and battle-tested in TLS 1.3 deployments everywhere.²

The second component is ML KEM 768, a module lattice-based key encapsulation mechanism standardized by the National Institute of Standards and Technology in FIPS 203.³ ML KEM 768 is designed to withstand cryptanalytic attacks from quantum computers. It is a lattice-based key encapsulation scheme that relies on mathematical problems even a large-scale quantum machine cannot solve efficiently.

X25519MLKEM768 combines X25519 ECDH with ML KEM 768 into a single negotiated group for TLS 1.3. The Internet Engineering Task Force published the specification as RFC 10024, formalizing hybrid key agreements that provide quantum-resistant security while preserving the strength of classical cryptography.⁴

This hybrid approach means your connection stays at least as strong as X25519 even if a weakness is found in ML KEM. And it stays at least as strong as ML KEM even if quantum computers break the elliptic curve math behind X25519.⁵

Hybrid key exchange uses classical and post-quantum algorithms working together. If one algorithm remains secure, your data remains protected.

The Client Share and Server Share in X25519MLKEM768

Here is what happens during a TLS 1.3 handshake using this hybrid group.

The client share is the first piece. When this group is negotiated among the supported groups, the client sends a combined key exchange value. That value contains the client's encapsulation key for ML KEM 768 (1,184 bytes) concatenated with the client's X25519 ephemeral share (32 bytes).⁶

The total client share size is 1,216 bytes. Yes, that is larger than a traditional X25519-only exchange. But it is a small price for post-quantum protection.

The server share comes back in the ServerHello. The server performs encapsulation against the client's encapsulation key and generates an ML KEM ciphertext returned from that process (1,088 bytes). The server also provides its own X25519 ephemeral share (32 bytes).⁷

The server must perform the encapsulation key check described in Section 7.2 of FIPS 203 on the client's key. If this check fails, the connection aborts.⁸

How the ML KEM and X25519 Shared Secret Is Derived

Both sides need to arrive at the same cryptographic material.

For this hybrid group, the shared secret is the concatenation of two distinct shared secrets. The ML KEM shared secret comes first (32 bytes), followed by the ECDHE shared secret (32 bytes). That gives you a final shared secret of 64 bytes total.⁹

Why put the ML KEM shared secret first? This ordering matters for FIPS compliance. NIST's SP 800-56Cr2 approves using HKDF with two distinct shared secrets as long as the first one comes from a FIPS approved mechanisms compliant scheme.¹⁰ For this group, that means the ML KEM implementation must be a certified implementation.

The ECDHE shared secret for SecP256r1 groups is the x coordinate of the ECDH shared secret elliptic curve point, represented as an octet string.¹¹ The key derivation methods in TLS 1.3 then feed this combined shared secret into the standard key schedule.

This process gives you quantum-resistant security backed by post quantum cryptography and the proven strength of classical key establishment in a single operation.

Supported Groups and the TLS 1.3 IANA Registry Updates

The IANA registry updates introduced by RFC 10024 added three new supported groups for post quantum key agreement in TLS 1.3.¹²

• X25519MLKEM768 (codepoint 0x11EC). Combines X25519 with ML KEM 768. The fastest and most widely deployed post quantum hybrid group. The identifier for X25519MLKEM768 is 0x11EC.

• SecP256r1MLKEM768 (codepoint 0x11EB). Combines NIST P-256 ECDH with ML KEM 768. Both shared secret parts come from FIPS approved mechanisms.

• SecP384r1MLKEM1024 (codepoint 0x11ED). Combines P-384 ECDH with ML KEM 1024 for high security environments.

The document obsoletes the earlier experimental supported groups X25519Kyber768Draft00 and SecP256r1Kyber768Draft00 that used pre-standard Kyber.¹³ X25519MLKEM768 is the recommended default and what most TLS version 1.3 clients negotiate today.

The document introduces these groups as part of the hybrid key agreements framework defined in the companion IETF documents on hybrid design. The document authors include Bas Westerbaan Cloudflare email contributor and Douglas Stebila University of Waterloo email researcher, alongside Kris Kwiatkowski (PQShield) and Panos Kampanakis (AWS).¹⁴

Security Considerations for X25519MLKEM768

The security considerations for X25519MLKEM768 deserve careful attention.

The same security considerations that apply to the general hybrid framework apply here. The security analysis relies crucially on the TLS 1.3 message transcript. You cannot assume a similar hybridization is safe in other protocols without separate analysis.¹⁵

This is an important point. The security analysis is specific to Transport Layer Security (TLS) version 1.3's handshake structure. The TLS 1.3 message transcript is crucial for security analysis because it binds all exchanged values together cryptographically.

Implementations resistant to side-channel attacks are strongly encouraged, especially those that can be applied by remote attackers.¹⁶ Hybrid key agreements must resist side-channel attacks to maintain the strength of both component algorithms.

Here is another risk: encapsulation randomness in ML KEM can expose RNG output. If the same way an insecure random number generator feeds both algorithms, a disclosure of state by one will compromise the other.¹⁷ Insecure RNGs can compromise both hybrid algorithms' security. Always use cryptographically secure randomness.

The trust legal provisions relating to IETF documents require that persons identified as document authors and contributors review these documents carefully. Code components extracted from the specification must include Revised BSD License text as described in the trust legal provisions.¹⁸ The full Revised BSD License text and document comment details are provided in the RFC.

Real World Deployment of X25519MLKEM768

The adoption of this hybrid group has been remarkably fast.

Google Chrome enabled X25519MLKEM768 as the default key exchange in version 131 (November 2024). Firefox followed with version 132 that same month.¹⁹ Bas Westerbaan announced Cloudflare completed its post-quantum hybrid rollout across its entire edge network.

By April 2026, more than two thirds of human-generated TLS 1.3 traffic to Cloudflare uses X25519MLKEM768 for hybrid key exchange.²⁰ Apple shipped post-quantum support for iOS and macOS in October 2025.

The Stebila University of Waterloo research team and contributors at Cloudflare, AWS, and PQShield drove this specification from draft to standard in the Internet Engineering Task Force. The key words "MUST" and "SHALL" in the RFC ensure interoperable implementations resistant to both classical and quantum threats.

X25519MLKEM768 supports FIPS-approved key establishment through its careful ordering of shared secret components and compatibility with NIST SP 800-56Cr2 and SP 800-227 key agreements guidance.²¹

Sources

1. IETF, "Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3," draft-ietf-tls-ecdhe-mlkem, https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/

2. A. Langley, M. Hamburg, S. Turner, "Elliptic Curves for Security," RFC 7748, https://www.rfc-editor.org/rfc/rfc7748

3. NIST, "Module-Lattice-Based Key-Encapsulation Mechanism Standard," FIPS 203, August 2024, https://doi.org/10.6028/nist.fips.203

4. RFC Editor, "RFC 10024: Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3," https://www.rfc-editor.org/info/rfc10024/

5. D. Stebila, S. Fluhrer, S. Gueron, "Hybrid key exchange in TLS 1.3," draft-ietf-tls-hybrid-design-16, https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/16/

6. IETF, "Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3, Section 4.1 Client share," https://www.ietf.org/archive/id/draft-ietf-tls-ecdhe-mlkem-02.html

7. IETF, "Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3, Section 4.2 Server share," https://www.ietf.org/archive/id/draft-ietf-tls-ecdhe-mlkem-02.html

8. NIST, "Module-Lattice-Based Key-Encapsulation Mechanism Standard, Section 7.2," FIPS 203, https://doi.org/10.6028/nist.fips.203

9. IETF, "Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3, Section 4.3 Shared secret," https://www.ietf.org/archive/id/draft-ietf-tls-ecdhe-mlkem-02.html

10. NIST, "Recommendation for Key-Derivation Methods in Key-Establishment Schemes," SP 800-56Cr2, https://doi.org/10.6028/nist.sp.800-56cr2

11. E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.3," RFC 8446, https://www.rfc-editor.org/rfc/rfc8446

12. IANA, "TLS Supported Groups Registry," https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml

13. IETF, "IANA Registry Updates for TLS and DTLS," draft-ietf-tls-rfc8447bis-15, https://datatracker.ietf.org/doc/html/draft-ietf-tls-rfc8447bis-15

14. K. Kwiatkowski, P. Kampanakis, B. Westerbaan, D. Stebila, "Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3," Authors' Addresses, RFC 10024

15. IETF, "Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLSv1.3, Section 6 Security Considerations," https://www.ietf.org/archive/id/draft-ietf-tls-ecdhe-mlkem-02.html

16. IETF, "Hybrid key exchange in TLS 1.3, Section 6 Security Considerations," draft-ietf-tls-hybrid-design-16

17. NIST, "Recommendations for Key-Encapsulation Mechanisms," SP 800-227, https://doi.org/10.6028/nist.sp.800-227

18. IETF Trust, "Legal Provisions Relating to IETF Documents," https://trustee.ietf.org/license-info

19. Encryption Consulting, "Post-Quantum Cryptography Support in Web Browsers," https://www.encryptionconsulting.com/pqc-support-in-web-browsers/

20. Cloudflare, "PQC Support Documentation," https://developers.cloudflare.com/ssl/post-quantum-cryptography/pqc-support/

21. NIST, "Recommendations for Key-Encapsulation Mechanisms, Section 4.6," SP 800-227, https://doi.org/10.6028/nist.sp.800-227

22. PostQuantumSecurity.org, "From X25519 to X25519+MLKEM768: How Hybrid TLS Is Becoming Real," https://www.postquantumsecurity.org/publications/X25519+MLKEM768.html

23. NIST, "Recommendation for pair-wise key-establishment schemes using discrete logarithm cryptography," SP 800-56Ar3, https://doi.org/10.6028/nist.sp.800-56ar