What a KEM Is

01.The job

A browser connects to a web server it has never contacted before, over a network where every packet can be read and altered. Within a few round trips the two need a shared random string, thirty-two bytes is plenty, that nobody else knows. After that they switch to a symmetric cipher such as AES and move gigabytes cheaply.

So the problem is not "encrypt this document". It is establish a shared symmetric key over an open channel, which is the exact question Chapter 2 opened with.

The reason the job is drawn this narrowly is cost. Public-key operations are expensive and their outputs are large. An ML-KEM ciphertext is about a kilobyte, where an AES block is sixteen bytes. So the public-key machinery runs exactly once per session, to agree on a symmetric key, and every subsequent byte rides on the cheap cipher.

A key encapsulation mechanism is the formalisation of that narrow contract: ship a shared random string, and nothing else.

02.Why not just encrypt a random key

There is an obvious alternative. Alice generates a random 32-byte key herself, encrypts it under Bob's public key using an ordinary public-key encryption scheme, and sends it. Bob decrypts and they both have it.

That works, and it is how TLS operated for most of the 1990s and 2000s under the RSA key-transport mode. The modern design deliberately does something slightly different, and the differences are small on paper and significant in practice.

The sender does not choose the key. In a KEM, the encapsulation routine returns the shared key rather than accepting one. Alice calls $\textsf{Encaps}(pk)$ and receives back a pair: a ciphertext to send, and a key to use. The key is derived by hashing internal randomness, so there is no input through which an attacker could bias it or probe how the implementation responds to a chosen value.

The security proof gets easier. Analysing "what if the attacker chooses the message" is much harder than analysing "the message is a uniformly random string". By construction the KEM only ever encrypts uniform randomness, which removes an entire category of awkward cases from the proof. For a scheme that has to be analysed by many independent parties before standardisation, that matters.

User data never touches the public-key primitive. The object being encrypted is always 32 bytes of noise. Nothing meaningful ever passes through the lattice machinery, which limits the damage if something about that machinery turns out to leak.

FIPS 203 therefore specifies a KEM rather than a general-purpose encryption scheme, and the rest of this chapter follows that shape.

03.How it is used

The deployment pattern is worth having in mind, because it explains which operations need to be fast.

Bob runs $\textsf{KeyGen}$ once. He publishes $pk$, typically inside a certificate, and stores $sk$.

Every client that wants to talk to Bob runs $\textsf{Encaps}(pk)$ with its own fresh randomness, sends the resulting ciphertext, and starts using the key it got back.

Bob runs $\textsf{Decaps}(sk, c)$ on each incoming ciphertext and arrives at the same key that client produced.

Two consequences follow. No two clients ever share a key, because each supplies its own randomness. And Bob performs one decapsulation per connection while performing key generation almost never, which is why decapsulation speed dominates server cost and why it is the operation hardware acceleration targets first.

04.What comes next

The next note states the contract precisely and introduces the two attacker models that shape everything about the construction. The distinction between them is the reason ML-KEM has two layers rather than one.