up:: Foundations MOC

KEM (Key Encapsulation Mechanism)

A key encapsulation mechanism (KEM) is a set of three algorithms, key generation, encapsulation, and decapsulation, that lets two parties securely establish a shared secret key over a public channel without either one sending that secret across it. One party publishes a public key, the other uses it to generate a fresh random secret plus a ciphertext, and only the holder of the matching private key can open that ciphertext to recover the same secret. The KEM is the clean, standardizable interface behind key establishment, and it’s the exact building block the post-quantum standards ML-KEM and HQC fill.

Source: NIST, “Recommendations for Key-Encapsulation Mechanisms,” SP 800-227, September 2025, csrc.nist.gov.

The short version:

• A KEM is a standard interface with three functions: KeyGen (make a keypair), Encapsulate (turn a public key into a shared secret plus a ciphertext), and Decapsulate (turn the ciphertext back into the same shared secret with the private key).
• Its whole job is key establishment, agreeing on a symmetric secret over an open network. It does no encryption of your actual data and no authentication of who you’re talking to.
• The shared secret a KEM produces is raw material. In practice you run it through a KDF to derive the actual symmetric keys that encrypt the session.
• The post-quantum world is built on KEMs because the abstraction is clean enough to standardize and analyze uniformly. Both ML-KEM and HQC are KEMs, held to the same security bar.
• Classical Diffie-Hellman and RSA key transport can be modeled as KEMs too, and both are the ones a quantum computer running Shor’s algorithm breaks.

The everyday analogy: a mailbox that mints its own secret

Picture a special mailbox whose design you publish openly, so anyone can build a copy, but only your private key opens the real one. Someone who wants to talk to you builds that mailbox, and the act of sealing it spits out a random secret code as a side effect. They keep the code and mail you the sealed box. You open it with your key and read the same code. Now you both hold an identical secret that was never written on the outside of anything.

That side effect is the part that makes a KEM different from just mailing someone a note. The sender doesn’t choose the secret and ship it. The mechanism generates a fresh random secret and a matching sealed box together, so an eavesdropper watching every piece of mail go by has no way to derive what’s inside. That’s encapsulation, and recovering the code with your private key is decapsulation.

What is a key encapsulation mechanism?

A key encapsulation mechanism is a set of algorithms two parties use to establish a shared secret key over a public channel. NIST specifies it as a triple of three functions, and the whole interface is small on purpose so it can be analyzed and standardized cleanly.

1. Key generation (KeyGen). The recipient generates a private decapsulation key and a matching public encapsulation key, then publishes the public one.
2. Encapsulation (Encapsulate). The sender uses the recipient’s public encapsulation key to generate a shared secret key and a ciphertext, then sends the ciphertext across.
3. Decapsulation (Decapsulate). The recipient uses the private decapsulation key and the received ciphertext to compute the same shared secret key.

The security requirement is that an adversary who sees the public key and the ciphertext, both of which travel over the open network, still cannot compute the shared secret without the private key. The formal name for this bar is IND-CCA, indistinguishability under chosen-ciphertext attack, which the cryptographic literature also writes as IND-CCA2. It means an attacker can’t tell which of two candidate secrets a ciphertext carries, even if they get to watch an honest party decapsulate ciphertexts of the attacker’s own choosing. ML-KEM, the first post-quantum KEM NIST standardized, is believed to meet it.

Source: NIST, SP 800-227, §2 (definition of a KEM) and §2.3 (IND-CCA security), September 2025, csrc.nist.gov.

How does a KEM work?

A KEM runs in one short pass, and the three functions map exactly onto the three moves above. Here’s what each one takes in and hands back, straight from the NIST specification:

Function	Who runs it	Input	Output
Key generation (KeyGen)	Recipient	a parameter set	encapsulation (public) key ek and decapsulation (private) key dk
Encapsulation (Encaps)	Sender	the recipient’s public key ek	a shared secret key K and a ciphertext c
Decapsulation (Decaps)	Recipient	the private key dk and the ciphertext c	the same shared secret key K

Source: NIST, SP 800-227, §2 (Definition 1, the three KEM algorithms), September 2025, csrc.nist.gov.

Correctness is the property that ties it together: when both sides run honestly, decapsulation reproduces the exact secret encapsulation generated, so Alice and Bob end up holding the same value. Key generation and encapsulation are probabilistic, they pull fresh randomness each time, while decapsulation is deterministic, it computes one answer from the private key and the ciphertext. That asymmetry is why a KEM works as a one-directional handshake: the sender needs nothing from the recipient except a published public key, and sends exactly one message back.

How is a KEM different from Diffie-Hellman key agreement?

A KEM and Diffie-Hellman both end with two parties sharing a secret over an open channel, and the difference is in the shape of the exchange. Diffie-Hellman is key agreement: both parties contribute their own values into a joint computation, and the shared secret is a function of both contributions, so neither side alone can predetermine it. A KEM, as an interface, only needs the recipient’s published public key. The sender generates the secret and ciphertext from that public key and sends one message, with no round-trip contribution required from the recipient.

NIST is precise about the relationship: a scheme like ECDH key exchange can be viewed as a KEM (the specification calls it ECDH-KEM), because you can wrap the elliptic-curve exchange in the KeyGen/Encaps/Decaps interface. So Diffie-Hellman isn’t a rival to the KEM idea, it’s one thing that fits inside it. What makes ML-KEM historically different is that it’s the first key-establishment scheme NIST standardized directly as a KEM, rather than a key-exchange scheme later re-described as one.

Source: NIST, SP 800-227, §5.1 (ECDH-KEM; key agreement versus key transport; ML-KEM as the first scheme standardized directly as a KEM), September 2025, csrc.nist.gov.

How is a KEM different from public-key encryption?

Public-key encryption (PKE) encrypts an arbitrary message of your choosing under someone’s public key. A KEM is narrower and more disciplined: it only ever establishes a fixed, freshly generated random secret, never a message you pick. That narrowing is a feature. A secret with no attacker-chosen structure is far easier to analyze and to prove secure, which is why modern key establishment is built on KEMs rather than on raw public-key encryption of a hand-picked key.

The two are closely related, though. You can build a KEM out of a public-key encryption scheme by having the sender generate a random secret and encrypt it, and NIST includes exactly that construction as a worked example. This is also why RSA key transport, where one party picks a key and encrypts it to the other’s public key with RSA-OAEP, fits the KEM interface as a key-transport-style KEM. The KEM abstraction is broad enough to cover both key-agreement schemes like Diffie-Hellman and key-transport schemes like RSA, which is a large part of why it became the standard lens.

Source: NIST, SP 800-227, §2.4 and §5.1.2 (building a KEM from public-key encryption; RSA secret-value encapsulation as a KEM), September 2025, csrc.nist.gov.

How does a KEM turn into actual encryption keys?

The shared secret a KEM outputs is not usually plugged straight into a cipher. For most applications you post-process it through a key derivation function first, and use the derived keys as your symmetric keys. NIST’s KEM guidance builds this step in: key derivation is applied when an application needs keying material of a specific length or needs several separate keys, and it points to the approved key-derivation methods in SP 800-108 and SP 800-56C.

Source: NIST, SP 800-227, §4.3 (Post-Processing of the Shared Secret Key), September 2025, csrc.nist.gov.

So the full chain, once a KEM has done its job, looks like this:

1. The KEM establishes a shared secret K between the two parties.
2. A KDF stretches or splits K into one or more symmetric keys of the exact sizes the protocol needs.
3. Those derived keys drive ordinary symmetric cryptography, AES for encryption and a MAC for integrity, to protect the actual session traffic.

This is identical in shape to what a classical key agreement does. The KEM changes the foundation the secret rests on, and everything downstream of the derived keys stays the same. In a hybrid deployment, the secrets from a classical KEM and a post-quantum KEM are both fed into the derivation step, so the session key is safe as long as either KEM held.

Why is the post-quantum world built on KEMs?

Because the KEM is the cleanest interface for the one job the quantum threat hits hardest: agreeing on a session key. NIST’s own reasoning is that among the ways two parties can establish a shared secret, the schemes best suited for standardization and widespread deployment are key encapsulation mechanisms, and the first standard out of the post-quantum competition was ML-KEM.

The abstraction pays off in three concrete ways.

1. One security definition for every candidate. Because every KEM presents the same KeyGen/Encaps/Decaps interface and is judged against the same IND-CCA bar, NIST could evaluate lattice-based, code-based, and other submissions on equal, comparable terms.
2. Two standardized KEMs, drop-in compatible. ML-KEM rests on structured lattices, and HQC rests on error-correcting codes. They’re built on entirely different mathematics, yet they expose the same interface, so a system designed around “a KEM” can swap one for the other. That’s crypto-agility made real, and it’s why keeping a second KEM from a different math family on the radar is a sound hedge.
3. Clean protocol integration. Because the KEM interface matches how protocols already think about key establishment, dropping ML-KEM into TLS, TLS 1.3, and other protocols is an interface substitution rather than a redesign.

Sources: NIST, SP 800-227, §1 (KEMs as the schemes best suited for standardization; ML-KEM as the first), September 2025, csrc.nist.gov; NIST, “NIST Selects HQC as Fifth Algorithm for Post-Quantum Encryption,” March 11, 2025, nist.gov.

Which KEMs actually matter, and are they quantum-safe?

Four KEMs cover almost everything a professional meets. Two are classical schemes viewed through the KEM lens and fall to a quantum computer, and two are the post-quantum standards that replace them.

KEM	Math family	Quantum-safe?	Standard and status
ECDH-KEM	elliptic-curve discrete log	No, Shor’s algorithm breaks it	classical ECDH key exchange, viewable as a KEM
RSA key transport (RSA-OAEP)	integer factoring	No, Shor’s algorithm breaks it	classical RSA key transport, viewable as a KEM
ML-KEM	structured lattices (Module-LWE)	Yes	FIPS 203, finalized August 13, 2024
HQC	error-correcting codes	Yes	selected March 2025, draft standard expected 2026, final expected 2027

Sources: NIST, FIPS 203, “Module-Lattice-Based Key-Encapsulation Mechanism Standard,” August 2024, csrc.nist.gov; NIST, “NIST Selects HQC as Fifth Algorithm for Post-Quantum Encryption,” March 11, 2025, nist.gov.

The pattern to hold onto: the KEM concept survives the quantum transition untouched. What changes is the math inside it. The idea of encapsulating a shared secret under a public key stays identical, and only the hardness assumption underneath moves from discrete logs and factoring, which Shor’s algorithm destroys, to lattices and codes, which it doesn’t.

How does the quantum transition affect KEMs?

KEMs are the front line of the confidentiality half of the quantum threat, and specifically of harvest-now-decrypt-later. Every classical KEM, ECDH-based key exchange in TLS and SSH, RSA key transport, Diffie-Hellman in VPN tunnels, encapsulates a session secret that an adversary can record today. When a cryptographically relevant quantum computer runs Shor’s algorithm against that recorded handshake, it recovers the secret and decrypts everything the session carried, years after the fact.

The fix is to move key establishment onto a post-quantum KEM, and because the interface is unchanged, that migration is mostly an integration project rather than a redesign. In TLS the standard path is hybrid key exchange, running a classical KEM and ML-KEM together so the session is safe if either component holds. Migrating key establishment is the highest-priority action for anything with long-lived confidential data, because the exposure is retroactive: data recorded today stays at risk the moment the capability arrives. See Mosca’s Theorem for the timing math that decides how urgent this is for a given system.

Common misconceptions

1. “A KEM encrypts my data.” A KEM only establishes a shared secret. Encrypting the actual traffic is the job of a symmetric cipher like AES-256, keyed from that secret. The KEM sets up the key, and the cipher does the encrypting.
2. “A KEM and ML-KEM are the same thing.” KEM is the general interface, the KeyGen/Encaps/Decaps contract. ML-KEM is one specific algorithm that fills that interface, and HQC is another.
3. “A KEM is just post-quantum Diffie-Hellman.” They overlap, since Diffie-Hellman can be wrapped as a KEM, but the object flow differs. A KEM generates a secret and a ciphertext from a published public key and sends one message, where a Diffie-Hellman exchange has both parties contribute values. Porting a Diffie-Hellman mental model straight across causes bugs.
4. “The secret from a KEM is ready to use as an encryption key.” Usually you post-process it through a KDF first, both to get keys of the right length and to derive several distinct keys from the one secret.
5. “A KEM tells me who I’m talking to.” Key establishment and authentication are separate operations. A KEM agrees a secret with whoever holds the private key, and proving that party’s identity takes a signature and a certificate on top.
6. “Only post-quantum algorithms are KEMs.” Classical ECDH key exchange and RSA key transport both fit the KEM interface. What makes ML-KEM and HQC special is that they’re quantum-resistant, and that ML-KEM was standardized directly as a KEM.

Questions people ask

What’s the difference between a KEM and Diffie-Hellman? Both establish a shared secret over an open channel. Diffie-Hellman is key agreement, where both parties contribute values into a joint computation, while a KEM as an interface only needs the recipient’s public key and sends one message back. NIST notes that Diffie-Hellman key exchange can itself be viewed as a KEM, so the KEM is the broader abstraction.

What’s the difference between a KEM and public-key encryption? Public-key encryption encrypts any message you choose, while a KEM only ever establishes a fresh random secret. The narrower job is easier to analyze and prove secure, which is why key establishment is built on KEMs. You can build a KEM out of a public-key encryption scheme, and NIST gives that construction as an example.

Is a KEM the same as ML-KEM? No. A KEM is the general three-function interface, and ML-KEM is one standardized algorithm that implements it. HQC is a second standardized KEM built on different mathematics, and older schemes like ECDH and RSA key transport fit the same interface.

Do I need a key derivation function after a KEM? For most applications, yes. NIST’s guidance applies a KDF to the KEM’s shared secret whenever an application needs keying material of a particular length or needs multiple separate keys, referencing the approved methods in SP 800-108 and SP 800-56C.

Is a KEM affected by quantum computers? The classical KEMs are, completely. ECDH and RSA key transport both fall to Shor’s algorithm on a large quantum computer. The concept of a KEM survives untouched, and the post-quantum KEMs ML-KEM and HQC re-instantiate it on math a quantum computer can’t break.

Why did NIST standardize key establishment as a KEM instead of key exchange? Because the KEM interface is the cleanest to standardize and analyze. Every candidate presents the same three functions and is judged against the same IND-CCA security bar, which let NIST compare lattice-based and code-based submissions on equal terms and produce drop-in-compatible standards.

Are ECDH and RSA really KEMs? They can be modeled as KEMs. NIST calls the elliptic-curve version ECDH-KEM and the RSA version RSASVE-KEM, both wrapped in the standard KEM interface. The difference is that ML-KEM is the first scheme NIST standardized directly as a KEM rather than re-describing an existing key-exchange scheme as one.

Does a KEM do signatures or authentication? No. A KEM handles confidentiality and key establishment only. Authentication and integrity of who you’re talking to are the signature side of the transition, handled by ML-DSA and its sibling standards, layered on top of the KEM.

---

Everything here is the map, given freely. When your team needs its key establishment inventoried, prioritized, and sequenced onto a real post-quantum migration plan, that’s what an alignment briefing is for.

Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.