The term on this page
- TLSTransport Layer Security
- the protocol behind the padlock in your browser
Also mentioned
ML-KEMML-KEMModule-Lattice-based Key Encapsulation MechanismModule-Lattice-Based Key-Encapsulation Mechanism, the NIST-standardized post-quantum KEM derived from CRYSTALS-Kyber and specified in FIPS 203.Read the full entry (new tab), KEMKEMkey encapsulation mechanismA public-key mechanism for securely establishing a shared secret key: the sender encapsulates a random secret to the recipient's public key, and the recipient decapsulates it with their private key.Read the full entry (new tab), FIPSFIPSFederal Information Processing StandardFederal Information Processing Standards, publicly announced standards developed by NIST for use in U.S. government computer systems, including cryptographic algorithms and modules.Read the full entry (new tab), NISTNISTNational Institute of Standards and TechnologyThe U.S. National Institute of Standards and Technology, the agency that develops and publishes cryptographic standards, including the FIPS series and post-quantum algorithms.Read the full entry (new tab) are defined in the glossary.
Read this first
For TLS 1.3 hybrid key exchange, use X25519MLKEM768, TLS named group 4588, now the de facto default in browsers and TLS stacks. X-Wing is a closely related but distinct standalone hybrid KEM built from the same two primitives (X25519 + ML-KEM-768) with a different combiner; the section below draws the line. Lattice confidence is earned, not assumed: keeping a classical component is cheap insurance, and the real risk in hybrids is implementation complexity.
A hybrid combines a classical primitive with a post-quantum one so the result is secure as long as either component holds. For key exchange this is attractive: the classical part protects you if a weakness is found in the lattice assumption, and the post-quantum part protects you against harvest-now-decrypt-later.
Hybrid KEMs are not hybrid signatures
It is tempting to reason about “going hybrid” uniformly. Don't. A hybrid KEM combines two shared secrets through a key-derivation step; a hybrid signature scheme has to decide what it means for a message to be signed by two schemes at once, and how a verifier treats partial validity. They are different problems with different pitfalls.
Use the TLS group, not a bespoke combiner
Adopt X25519MLKEM768 as exposed by your TLS library rather than designing your own KEM combiner. It has had cryptographic review, an assigned named group, and broad deployment. A custom combiner is surface area you do not need.
The real risk in hybrid construction is not that the cryptography is weak: it is that the construction is complex, and complexity is where bugs live. Concatenation order, domain separation in the KDF, and how downgrade is handled are all places where a plausible-looking hybrid can quietly fail. They are the three we look at first in a hybrid implementation review.
Lattice confidence is earned, not assumed
The lattice assumptions behind ML-KEM are well studied but younger than the classical ones. Keeping a classical component in the hybrid is inexpensive and removes a single point of failure, so there is little reason to drop to a PQ-only KEM for general traffic today.
X-Wing and X25519MLKEM768: same primitives, different combiners
The title is a deliberate pairing, because the two are easy to conflate. Both combine X25519 with ML-KEM-768, but the combiner and its security argument differ. X25519MLKEM768 (TLS named group 4588 / 0x11EC) uses plain concatenation: the ML-KEM shared secret first, then the X25519 shared secret, fed straight into the ordinary TLS 1.3 key schedule per RFC 9954. It is safe in TLS precisely because that key schedule already hashes the full handshake transcript, including both public key shares. X-Wing is instead a standalone, general-purpose KEM whose shared secret is a SHA3-256 hash of both secrets, the X25519 ciphertext and public key, and a domain-separation label; its efficiency trick, omitting the ML-KEM ciphertext from the hash, is justified in the X-Wing paper by ML-KEM's ciphertext-binding properties. Note X-Wing is on the IETF Independent Submission stream, not CFRG-adopted, so it is a specification to build on, not yet a standard.
The practical takeaway is unchanged: inside TLS, use the assigned group your library ships (X25519MLKEM768) rather than wiring X-Wing in by hand: the concatenation construction is what has the review and the deployment. For most estates that is a configuration change rather than a code change, which makes it the cheapest step in a post-quantum migration. And mind the ordering gotcha the name hides: for X25519MLKEM768 the ML-KEM secret comes first, whereas the NIST-curve variants (SecP256r1MLKEM768, SecP384r1MLKEM1024) put the ECDHE secret first for FIPS-compliance reasons. Exactly the kind of detail a plausible-looking bespoke combiner gets wrong, and exactly what conformance testing is built to catch.
References
- IETF: RFC 9954: Hybrid Key Exchange in TLS 1.3 (the concatenation framework the TLS groups instantiate), and draft-ietf-tls-ecdhe-mlkem (defines X25519MLKEM768, group 4588).
- X-Wing: draft-connolly-cfrg-xwing-kem (the SHA3-256 combiner + label) and the paper Barbosa et al., "X-Wing: The Hybrid KEM You've Been Looking For" (IACR eprint 2024/039).
- NIST: FIPS 203: the ML-KEM standard, the post-quantum half of both constructions.
- Wikipedia: ML-KEM (parameter sizes and Kyber background) and Post-quantum cryptography.