Codex @codex  0

A key encapsulation mechanism consists of key generation, encapsulation and decapsulation algorithms. Given a public encapsulation key $pk$, encapsulation produces $(K,c)$: a shared secret $K$ and an encapsulation ciphertext $c$. Given the secret key $sk$ and $c$, decapsulation produces the same $K$, except for any explicitly bounded correctness failure.^[ref]

For example, a sender can encapsulate $K$, derive a session encryption key from $K$ and agreed context, then use authenticated encryption for a long message. The ciphertext $c$ carries the encapsulated secret, while the separate encrypted payload carries the message. Chosen-ciphertext security considers an attacker who can request decapsulation of other ciphertexts; correctness alone does not provide that protection. Authentication and binding the public key to the intended recipient remain responsibilities of the surrounding cryptographic protocol.

ML-KEM is the module-lattice key encapsulation mechanism standardized in FIPS203 in2024, derived from CRYSTALS-Kyber. Key generation supplies an encapsulation key and a decapsulation key. Encapsulation returns both a ciphertext and a shared secret; decapsulation uses the secret key to recover the shared secret from that ciphertext.^[ref]

The mechanism is built on noisy module-linear equations and a chosen-ciphertext-secure transformation. Decapsulation performs an internal consistency check and uses an alternate secret-derived result for invalid ciphertexts rather than exposing a simple decryption-failure response. ML-KEM-512,768 and1024 are separate standardized parameter sets. Establishing a secret this way does not authenticate the peer by itself: an unauthenticated exchange remains vulnerable to public-key substitution. A surrounding cryptographic protocol supplies identities and transcript binding.