Hybrid KEM combiner: how ML-KEM and ECDH are combined

A hybrid KEM combiner is the function that merges the shared secret from a classical key exchange (usually ECDH over X25519 or a NIST curve) with the shared secret from the post-quantum ML-KEM into one session key. Its job is to keep that key confidential as long as either component is still unbroken.

For organisations that run OT and critical infrastructure, the combiner is not an academic detail. Links between substations, plants, control rooms, cloud historians and remote engineers often stay in service for years. Traffic recorded today could be decrypted later if the key exchange cannot withstand a quantum computer. Most of the security of a hybrid design sits in the small step where the two secrets are merged, so that step needs the same scrutiny as the choice of algorithms.

How are the classical and post-quantum shared secrets combined in a hybrid key exchange?

Both key exchanges run side by side, each producing its own shared secret. A key derivation function then takes both secrets plus context data and turns them into a single key. NIST SP 800-227 formalises this as a two-stage process: first establish the shared secrets, then combine them with an approved key combiner.

The two stages in NIST SP 800-227

NIST published SP 800-227, Recommendations for Key-Encapsulation Mechanisms, in final form in September 2025. In its first stage, all component key establishment schemes are run (typically in parallel), resulting in Alice and Bob sharing a collection of shared secrets. In the second stage those secrets go into a combiner. For two components, the combiner has the form K ← KDM((S1,S2),OtherInput) for a two-algorithm key-establishment scheme, where KDM is a key derivation method and OtherInput carries context such as public keys, ciphertexts or protocol labels.

Why the classical part can be “non-approved”

SP 800-227 lets one input to the combiner be generated in some other (not necessarily approved) manner, provided the other comes from an approved method such as ML-KEM under FIPS 203. In practice this means an ECDH secret over X25519, which is widely deployed, can sit next to an ML-KEM-768 secret without making the overall construction non-approved.

Is concatenating the ECDH and ML-KEM secrets secure?

Yes, under three conditions: each secret has a fixed length (or an unambiguous encoding), the concatenated value goes through a KDF before use, and the protocol binds the exchanged public values into the derivation. Raw concatenation used directly as an encryption key does not meet NIST’s guidance.

The IETF draft-ietf-tls-hybrid-design takes this route. The two shared secrets are concatenated together and used as the shared secret in the existing TLS 1.3 key schedule. No length fields are added, because for both the traditional groups and post quantum KEMs, the shared secret output length is fixed for a specific elliptic curve or parameter set. The draft also warns that if concatenation were to be used with values that are not fixed-length, a length prefix or other unambiguous encoding must be used to ensure that the composition of the two values is injective.

The KDF step is not optional. SP 800-227 states that a combiner should ensure that the final shared secret key from the key combiner is passed through a KDF before use. In TLS 1.3 this happens automatically, because the concatenated secret enters HKDF-Extract and the handshake transcript is hashed into later stages.

Why does a hybrid stay secure if only one of the two algorithms remains unbroken?

An attacker who wants the session key has to know every input to the KDF. If either secret stays unknown, the KDF output looks random to them. That holds only if the combiner preserves the security properties of its components.

The TLS hybrid draft states the design goal as the establishment of a shared secret which remains secure as long as one of the component key exchange mechanisms remains unbroken. Gorjan Alagić (UMD / NIST), presenting SP 800-227, put the reasoning more bluntly: “New stuff sometimes gets broken, so combo stuff so adversary has to break both new and old.”

The subtle part is protection against active attackers. SP 800-227 notes that when only one component is IND-CCA secure, a careless construction could be so broken that C[Π1,Π2] is not IND-CCA, even if Π1 is IND-CCA and regardless of what KDF is used. NIST’s answer: “NIST encourages the use of key combiners that generically preserve IND-CCA security”. In concrete terms, the combiner should hash in the ciphertexts and public keys, not just the two shared secrets. Ephemeral ECDH, modelled as a KEM, is not IND-CCA on its own.

What is the X-Wing hybrid KEM and how does it differ from the TLS hybrid design?

X-Wing is a single, fixed hybrid KEM built from X25519 and ML-KEM-768, with its own SHA3-256 combiner. The TLS design is a protocol-level method that concatenates key shares and secrets and relies on the TLS 1.3 key schedule for binding.

X-Wing is specified in an Internet-Draft by Deirdre Connolly, Peter Schwabe and Bas Westerbaan, and is discussed in the IETF Crypto Forum Research Group (CFRG). Revision -11 was published on 23 September 2026 with intended status Informational. Its combiner returns SHA3-256 over the concatenation of XWingLabel, ss_M, ss_X, ct_X and pk_X. The ML-KEM ciphertext and public key are deliberately left out. That shortcut is safe only because of ML-KEM’s internal design: X-Wing’s security relies crucially on the specifics of the Fujisaki-Okamoto transformation used in ML-KEM-768, and its combiner cannot be assumed to be secure when used with different KEMs. The authors summarise the result as “X-Wing is secure if SHA3 is secure, and either X25519 is secure, or ML-KEM-768 is secure.”

The practical difference: X-Wing suits protocols that expect a single KEM, such as HPKE-style encryption, without any protocol-level transcript to depend on. The TLS approach suits protocols that already have a strong key schedule. The concrete ECDHE-MLKEM groups for TLS have since been published as RFC 10024, which states that the shared-secret concatenation and HKDF-based derivation used by TLS 1.3 are consistent with the composite-KEM constructions and key-combiner recommendations outlined in Sections 4.6.1 and 4.6.2 of SP 800-227.

Which key derivation functions does NIST approve for combining hybrid secrets?

NIST relies on the key derivation methods in SP 800-56C Rev. 2: a one-step KDF built on an approved hash function, HMAC or KMAC, and a two-step extract-then-expand KDF. HKDF with SHA-2 follows the two-step pattern.

ENISA’s 2026 standardisation overview notes that SP 800-227’s approved key combiners reference SP 800-56C for one-step and two-step key derivation. For a site-to-site gateway, this has three practical consequences:

• One-step (SP 800-56C, Section 4): hash the concatenated secrets together with a fixed label and context in a single call. X-Wing’s SHA3-256 combiner is built along these lines.
• Two-step (SP 800-56C, Section 5): extract a pseudorandom key from the concatenated secrets with HMAC, then expand it into traffic keys. This matches the TLS 1.3 key schedule and the IKEv2 prf+ construction.
• Context matters as much as the hash: labels, the identities of both peers and the exchanged public values belong in OtherInput, so that a key from one session or direction cannot be reused in another.

How does hybrid key exchange work in IPsec site-to-site tunnels?

IPsec runs hybrid key exchange through RFC 9370, which lets IKEv2 run extra key exchanges after the initial ECDH and mix each resulting secret into the key material in turn.

RFC 9370 (May 2023) utilizes the IKE_INTERMEDIATE exchange, where multiple key exchanges are performed when an IKE SA is being established, and introduces IKE_FOLLOWUP_KE for the same purpose when the IKE SA is being rekeyed or is creating additional Child SAs.

Statistic: RFC 9370 defines seven new transform types, so up to seven additional key exchanges can be negotiated next to the initial one (IETF, May 2023).

Statistic: An ML-KEM-768 encapsulation key of 1184 bytes, plus roughly 250 bytes of IKE header data, fits in a typical 1500-byte MTU (draft-kampanakis-ml-kem-ikev2-02, 2024).

The MTU figure matters for OT. Older cellular, satellite or leased-line links sometimes run with smaller MTUs or drop fragments, and a handshake that works in the lab can stall in the field.

Can a badly designed combiner weaken quantum-safe site-to-site encryption?

Yes. A weak combiner can cut a hybrid back to the strength of its weakest component, or below it, even when ML-KEM and ECDH are both implemented correctly. Most of the risks come from shortcuts in how the secrets are merged and negotiated.

• XOR instead of a KDF. The TLS working group listed XOR the shared secrets then use directly in the TLS 1.3 key schedule as an option it considered, and chose concatenation. XOR does not bind the result to ciphertexts or public keys, and two components that produce related values can cancel each other out.
• Truncation. Cutting the combined secret down to fit a legacy key field throws away entropy and can end up dropping the post-quantum half completely.
• Ambiguous encoding. Variable-length inputs without length prefixes let different input pairs produce the same byte string.
• Missing binding. Hashing only the secrets, without the ECDH public values, gives up the IND-CCA preservation that SP 800-227 encourages.
• Reusing a specialised combiner. Swapping a different KEM into X-Wing’s combiner breaks the assumption it was proven under.
• Silent downgrade. The TLS draft’s compatibility goals allow a hybrid-aware client to establish a non-hybrid shared secret (assuming the hybrid-aware client is willing to downgrade to non-hybrid-only). On fixed site-to-site links between known peers there is rarely a reason to accept that.

What should OT operators verify in a hybrid gateway design?

Ask for the exact combiner specification, check that it matches a published construction, and confirm how the gateway behaves under failure. Algorithm names on a datasheet are not enough.

• Which document defines the combiner (SP 800-227 Section 4.6, the TLS 1.3 key schedule, RFC 9370 key derivation, or X-Wing), and which KDF from SP 800-56C Rev. 2 is used?
• Which ML-KEM parameter set from FIPS 203 is used? The standard specifies three parameter sets, ML-KEM-512, ML-KEM-768 and ML-KEM-1024, in order of increasing security strength and decreasing performance.
• Are public values and ciphertexts hashed into the derivation, either directly or through a transcript?
• Can the post-quantum component be replaced without redesigning the combiner (crypto agility)?
• What happens on line failure: retry with the same hybrid settings, or fall back?

As one example of how these properties show up in a product, Quantum Network’s Quantum Gateway uses a hybrid key agreement in which a classical part and an ML-KEM part (FIPS 203) are combined into one session key. The post-quantum algorithm can be changed if needed, and the connection never falls back to unencrypted traffic after a line failure. Whatever the implementation, apply the same checklist and ask for the combiner details in writing.