up:: Migration Architecture MOC
KEM Combiners
A KEM combiner is the piece of machinery that takes a classical key-encapsulation mechanism and a post-quantum one and fuses their outputs into a single shared secret, so that the combined result stays secure as long as at least one component remains unbroken. It is the load-bearing part of hybrid key exchange, the “secure if either holds” guarantee actually lives in the combiner, not in the mere presence of two algorithms. The care is necessary because the obvious approach, gluing the two shared secrets together end to end and using that as your key, is not automatically safe. Whether the combined key inherits the security of the surviving component depends on how the two secrets are folded together and what is fed into the key derivation function. A combiner is the specific, analyzed construction that makes the guarantee hold.
Source: Federico Giacon, Felix Heuer, Bertram Poettering, “KEM Combiners,” PKC 2018, ePrint 2018/024.
The short version:
- A KEM combiner fuses two KEMs into one. Given a classical KEM and a post-quantum KEM, it produces a single hybrid KEM whose shared secret is derived from both, and it is the construction that carries the “secure if either component holds” property.
- Naive concatenation is not automatically safe. Simply gluing the two shared secrets together and calling it the key can forfeit the guarantee, because the combined value can leak structure or fail to bind everything an attacker might manipulate.
- A sound combiner runs the secrets through a KDF that behaves like a dual-PRF, so the output stays pseudorandom as long as either input secret is unknown to the attacker, and it binds the ciphertexts into the derivation alongside the secrets.
- Giacon, Heuer, and Poettering formalized this in 2018, giving combiner constructions and proving which ones preserve IND-CCA security when at least one ingredient KEM is secure.
- This is why hybrid TLS combines the way it does. The TLS 1.3 hybrid design concatenates the two secrets and runs them through the HKDF-based key schedule, which the standard justifies as the dual-PRF combiner and which requires fixed-length shared secrets.
Picture two safes, an old mechanical one and a new electronic one, each holding half of a passphrase, and your job is to combine the two halves into the single passphrase that opens the front door. The lazy method is to write one half next to the other and read them as one long string. That works only if neither half ever tells you anything about the other and the boundary between them is unambiguous, and if either assumption slips, a thief who cracks one safe can start guessing at the door. The careful method runs both halves through a blender that produces the real passphrase, engineered so that as long as one half stays secret the blended output is unguessable, and so that swapping either safe for a tampered one changes the result. The blender is the combiner, and the whole security of the scheme depends on it being built right.
What is a KEM combiner?
A KEM combiner is a construction that takes two or more key-encapsulation mechanisms and produces a single new KEM. Each ingredient KEM independently encapsulates to its own ciphertext and its own shared secret, and the combiner defines how those separate shared secrets, and the ciphertexts that produced them, are merged into one final shared secret for the hybrid. The point of the exercise is a specific robustness property: the combined KEM should be secure whenever at least one of its ingredients is secure, so that a break of either the classical or the post-quantum component leaves the hybrid standing. That property is exactly what a migration wants, because it hedges a future quantum break of the classical side against an undiscovered flaw in the young post-quantum side at the same time.
Source: Giacon, Heuer, Poettering, “KEM Combiners,” PKC 2018, ePrint 2018/024.
The reason a combiner is a defined object with its own security analysis, rather than an obvious afterthought, is that the target security notion is IND-CCA, security against an attacker who can make decapsulation queries. Under that notion, an attacker who has fully broken one component, and can therefore choose its ciphertexts and know its shared secret freely, must still gain nothing against the hybrid as long as the other component holds. A combiner earns its name by provably delivering that under a realistic attacker, and the Giacon-Heuer-Poettering work is where the constructions and their proofs were laid out, some proven secure under standard assumptions and some in idealized models.
Why is concatenating shared secrets not automatically safe?
Concatenation can fail because the security a combiner promises is a strong claim about a strong attacker, and simply placing two secrets side by side does not, on its own, meet it. Two failure modes matter. The first is boundary ambiguity: if the two shared secrets can vary in length, then different pairs of secrets can concatenate to the same combined string, and that collision can be exploited. This is why the TLS hybrid design restricts hybrid combination to algorithms with fixed-length shared secrets, so the concatenation is unambiguous. The second is that a raw concatenated string is a value, not a key, and reading it directly as key material can expose structure from a broken component instead of a uniformly random secret.
Source: fixed-length requirement and the injectivity concern per Stebila, Fluhrer, Gueron, “Hybrid key exchange in TLS 1.3,” IETF, draft-ietf-tls-hybrid-design (concatenation works only for “algorithms which have fixed-length shared secrets”).
There is a subtler gap that a good combiner has to close, which is binding the ciphertexts alongside the secrets. In an IND-CCA setting an attacker can manipulate the ciphertext of a component they control, and a combiner that mixes only the two shared secrets while ignoring the ciphertexts can let that manipulation slip through in a way that breaks the “secure if either holds” guarantee for a component that is otherwise fine. The Giacon-Heuer-Poettering analysis shows that a combiner robust in the strongest sense feeds the ciphertexts into the mixing step as well, so the final secret is bound to the exact transcript that produced it. Concatenation can be part of a safe design, and it is safe only inside a construction that fixes the lengths and runs the whole thing through the right function.
What does a proper combiner require?
A sound KEM combiner runs the ingredient secrets through a key derivation function that behaves like a dual-PRF, and binds the ciphertexts into the derivation. The dual-PRF property is the crux: a pseudorandom function is normally unpredictable when its key is secret, and a dual-PRF is unpredictable when either of its two inputs is secret, even if the attacker knows and controls the other. Feed the two shared secrets into a dual-PRF and the output stays pseudorandom as long as one of the two secrets is unknown, which is precisely the “secure if either holds” guarantee expressed as a property of the mixing function. HKDF, the HMAC-based KDF that TLS 1.3 already uses, is the standard realization, and its extract step is what the hybrid design leans on as the combiner.
Source: dual-PRF combiner and its security per Bindel, Brendel, Fischlin, Goncalves, Stebila, “Hybrid Key Encapsulation Mechanisms and Authenticated Key Exchange,” PQCrypto 2019, ePrint 2018/903; TLS realization per draft-ietf-tls-hybrid-design (the design “corresponds to the dual-PRF combiner of [BINDEL] which is shown to preserve security under the assumption that the hash function is a dual-PRF”).
The requirements a real combiner has to satisfy come down to a short list, and each one closes a specific gap.
| Requirement | What it prevents |
|---|---|
| Dual-PRF mixing (e.g. HKDF) | An attacker who breaks one component predicting the combined key from the other |
| Fixed-length inputs | Boundary ambiguity where different secret pairs collide to the same combined string |
| Bind the ciphertexts alongside the secrets | Ciphertext manipulation on a controlled component slipping past the guarantee |
| Refuse silent classical-only fallback | A downgrade that quietly discards the post-quantum half |
Source: dual-PRF and ciphertext-binding per ePrint 2018/024 and ePrint 2018/903; fixed-length and key-schedule integration per draft-ietf-tls-hybrid-design.
The practical reading is that a combiner is easy to get subtly wrong and well understood once you follow the analyzed designs. The mistakes that matter, XORing or gluing raw secrets and reading them straight as a key, ignoring the ciphertexts, allowing variable-length inputs, are exactly the ones the standardized constructions were built to rule out. When a hybrid deployment uses the TLS 1.3 key schedule or an equivalent HKDF-based combiner as specified, the “secure if either holds” property is carried correctly, and the risk moves from the cryptography to the operational questions of configuration and fallback.
How does this show up in TLS and other protocols?
In hybrid TLS 1.3 the combiner is the existing key schedule. The two shared secrets, from the classical X25519 exchange and the post-quantum ML-KEM decapsulation, are concatenated as classical_secret || pq_secret and inserted into the TLS 1.3 key schedule in place of the single classical secret the protocol used before. Because that key schedule is HKDF-based and the design treats HKDF-Extract as the dual-PRF combiner, every downstream key is derived from both secrets at once, and the combination inherits the “secure if either holds” guarantee. The fixed-length constraint is why the standard restricts hybrid combination to algorithms whose shared secrets have a fixed size once the algorithm is chosen.
Source: Stebila, Fluhrer, Gueron, draft-ietf-tls-hybrid-design (“concatenated_shared_secret = MyECDH.shared_secret || MyPQKEM.shared_secret and inserted into the TLS 1.3 key schedule in place of the (EC)DHE shared secret”; corresponds to the dual-PRF combiner of [BINDEL]); see X25519MLKEM768 and the TLS hybrid named groups.
The same shape recurs across the protocols that adopted hybrid key exchange, described in Hybrid Cryptography: each runs both key establishments, then folds both secrets into the protocol’s own key derivation rather than reading either secret directly as a key. That consistency is deliberate, because the combiner is the one place the whole hybrid guarantee can be lost, so the standards route the secrets through an analyzed KDF-based construction every time rather than inventing a bespoke mixing rule per protocol. For a deployment, the meaning is that verifying a hybrid connection is genuinely hybrid includes trusting that the key schedule combines both secrets as specified, which is a property of using the standardized configuration rather than something an operator tunes.
Common misconceptions
- “Two KEMs automatically give a secure hybrid.” The security lives in the combiner, and having two algorithms present does nothing on its own. A hybrid is “secure if either holds” only when the two secrets are merged through an analyzed dual-PRF construction that binds the ciphertexts and forbids silent fallback.
- “Concatenating the two shared secrets is all a combiner does.” Concatenation is one step inside a safe design, and by itself it can leave boundary ambiguity and ignore the ciphertexts. A sound combiner fixes the input lengths and runs the concatenation through a KDF that behaves like a dual-PRF, so the raw glued string is never used directly as a key.
- “XOR of the two secrets is a fine combiner.” XORing raw secrets and using the result as key material can forfeit the guarantee, because it neither binds the ciphertexts nor guarantees pseudorandomness from the surviving secret under a strong attacker. The analyzed constructions route the secrets through a dual-PRF KDF instead.
- “The combiner is where the slowness of hybrid comes from.” The cost of hybrid is the extra kilobyte in the handshake from the post-quantum key material, and the KDF-based combining step is cheap. A hybrid rollout’s practical hazard is the oversized handshake tripping middleboxes, described in Hybrid Cryptography, rather than the combiner’s arithmetic.
- “If the protocol uses HKDF, the combiner is automatically correct.” HKDF is the right tool, and correctness also needs fixed-length inputs, both secrets actually fed in, the ciphertexts bound, and no silent classical-only fallback. Using HKDF as the standardized hybrid designs specify is what makes it correct, rather than the mere presence of HKDF.
Questions people ask
What is a KEM combiner in simple terms? It is the construction that merges a classical and a post-quantum key-encapsulation mechanism into one, deriving a single shared secret from both, so the result stays secure as long as either component is unbroken. It is the part of a hybrid where the “secure if either holds” guarantee actually lives.
Is concatenating the two shared secrets safe? Only inside a proper construction. Raw concatenation can leave boundary ambiguity if the secrets can vary in length, and reading the glued string directly as a key can expose structure from a broken component. It becomes safe when the lengths are fixed and the concatenation is run through a KDF that behaves like a dual-PRF, which is what the TLS hybrid design does.
What makes a combiner secure? Mixing the two secrets through a dual-PRF, so the output stays pseudorandom as long as either secret is unknown to the attacker, together with fixed-length inputs, binding the ciphertexts alongside the secrets, and refusing any silent fallback to classical-only. HKDF as used in the TLS 1.3 key schedule is the standard realization.
Who formalized KEM combiners? Federico Giacon, Felix Heuer, and Bertram Poettering, in “KEM Combiners” at PKC 2018, gave combiner constructions and proved which ones preserve IND-CCA security when at least one ingredient KEM is secure. Bindel, Brendel, Fischlin, Goncalves, and Stebila then analyzed the dual-PRF combiner that the TLS hybrid design uses.
How does hybrid TLS combine its two secrets? It concatenates the classical X25519 secret and the post-quantum ML-KEM secret and feeds the result into the existing HKDF-based TLS 1.3 key schedule, which acts as the dual-PRF combiner. Every session key is then derived from both secrets, and the design requires fixed-length shared secrets for the concatenation to be unambiguous.
Do I need to build a combiner myself? No. The combining is done by the protocol’s standardized key schedule, so a deployment inherits an analyzed construction by using hybrid as specified rather than assembling one. Understanding the combiner explains why hybrid security is a property of the composition and why a home-rolled mixing rule is the kind of shortcut that quietly forfeits the guarantee.
Everything here is the map, given freely. When your team needs its hybrid key exchange assessed for a correct combiner, a real fallback policy, and a clean retirement plan, that’s what an alignment briefing is for.
Last verified 2026-07-12 · Maintained by Addie LaMarr, LaMarr Labs.