A key encapsulation mechanism establishes a shared secret between two parties using public-key cryptography, but differently from Diffie-Hellman.
In Diffie-Hellman, both sides contribute a public value and combine them to derive the same secret. In a KEM:
- One party publishes an encapsulation key (a public key)
- The other generates a random shared secret and encapsulates it to that key
- The first party decapsulates it using the corresponding private key
The secret is generated by one side and transported, rather than derived jointly.
Why post-quantum cryptography uses KEMs
Lattice-based constructions like ML-KEM fit the KEM shape naturally, whereas a direct Diffie-Hellman analogue does not exist for them. Standardising a KEM rather than forcing a DH-shaped interface was the practical choice.
Practical consequence: size
KEM keys are large. An ML-KEM-768 encapsulation key is 1,184 bytes, against 32 bytes for X25519. In a hybrid TLS handshake the combined client share reaches 1,216 bytes.
That is enough to push a ClientHello beyond a single network packet, which is why some middleboxes and older load balancers fail on post-quantum handshakes when they were fine with classical ones. If a post-quantum rollout breaks connectivity, oversized ClientHellos are the first thing to check.