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.
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 — 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. 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.
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 — ML-KEM standard, the post-quantum half of both constructions.
- Wikipedia: ML-KEM (parameter sizes and Kyber background) and Post-quantum cryptography.