With FIPS 203 finalised, the key encapsulation mechanism (KEM) choice for new deployments has a clear answer: ML-KEM-768 or ML-KEM-1024, depending on your security level requirement. But the real engineering question is subtler — should you deploy ML-KEM alone, or use a hybrid combiner like X-Wing during the migration window?
ML-KEM: the baseline
ML-KEM (formerly CRYSTALS-Kyber) is a lattice-based KEM built on the Module Learning With Errors (MLWE) problem. It comes in three parameter sets: ML-KEM-512 (NIST security level 1), ML-KEM-768 (level 3), and ML-KEM-1024 (level 5). For most enterprise deployments, ML-KEM-768 is the practical choice: it is the NIST category-3 parameter set, with a public key of 1,184 bytes and a ciphertext of 1,088 bytes.
The performance story is good. On modern hardware, ML-KEM-768 key generation runs at approximately 40,000 operations per second; encapsulation and decapsulation are similarly fast. The latency overhead over a TLS 1.3 handshake is typically under 4 ms on commodity server hardware — negligible for most applications.
X-Wing: the hybrid combiner
X-Wing (draft-connolly-cfrg-xwing-kem) combines ML-KEM-768 with X25519 using a simple, analysed combiner construction. The shared secret is derived from both KEMs’ outputs, meaning a session is secure if either the classical component (X25519) or the post-quantum component (ML-KEM) is unbroken. You get both classical and post-quantum protection simultaneously.
This matters during the migration window for two reasons. First, the MLWE assumption, while well-studied, has not been subjected to the same decades of cryptanalytic pressure as Diffie-Hellman and elliptic curves. If a structural weakness in lattice problems is discovered — unlikely, but non-zero probability — a hybrid session remains secure. Second, in regulated environments, some standards bodies still require classical algorithm participation in key derivation. X-Wing satisfies both requirements in a single handshake.
The trade-off
X-Wing’s combined public key is 1,216 bytes (ML-KEM-768’s 1,184 + X25519’s 32). Ciphertext is 1,120 bytes. This is slightly larger than ML-KEM alone, but still well within practical TLS record limits. The computational cost is additive — you perform both KEMs — but the overhead is small enough to be invisible in most deployments.
The genuine cost of X-Wing is complexity: two algorithm implementations, two key pairs to manage, and a combiner that must be implemented correctly. In environments where cryptographic agility is already built into the infrastructure — where algorithm negotiation is centralised and well-audited — this complexity is manageable. In legacy systems where cryptographic code is scattered and poorly tested, adding a hybrid combiner can introduce new attack surface.
Decision framework
Use X-Wing (or another well-specified hybrid combiner) when: you are protecting data with a sensitivity horizon beyond 2035; your regulator requires classical algorithm participation; or you are operating in an environment where the post-quantum cryptanalytic track record is a board-level risk factor.
Use ML-KEM alone when: you need the simplest possible implementation path; your policy baseline treats FIPS 203 as sufficient for the deployment; or you are replacing an existing ECDH deployment and hybrid complexity outweighs the marginal security benefit.
In either case, the TLS 1.3 integration path depends on the named groups your stack actually implements. The assigned TLS hybrid named group is X25519MLKEM768, which is not X-Wing. X-Wing remains a separate Internet-Draft KEM with a requested TLS codepoint, while the mid-2023 production deployments were based on the earlier X25519Kyber768Draft00 construction that IANA now marks obsolete.