A key pair, shared secret and encapsulation
Key generation produces a public encapsulation key and secret decapsulation key. Encapsulation uses the public key to generate a shared secret and transmissible encapsulation; the matching private-key holder decapsulates it to obtain the same secret under the mechanism’s conditions.
The public output is the encapsulation, not a cleartext copy of the shared secret. Input validation, failure handling and formats depend on the particular KEM rather than every construction exposing identical errors or representations.
Encapsulation is not arbitrary-message encryption
A KEM supplies secret material for later mechanisms. A KDF derives needed keys and symmetric authenticated encryption protects the actual contents. Encapsulation and content ciphertext are distinct, so a longer body need not make the KEM process additional plaintext blocks.
RFC 9180 demonstrates the composition and constructs DHKEM from Diffie–Hellman. KEM denotes an interface and security-goal class rather than one mathematical problem or product; optional sender-authentication support depends on the mechanism.
References: [1]
Identity and quantum assumptions require separate choices
The recipient public key must be bound to the intended party; otherwise encapsulation may securely establish a secret with the wrong one. A nonempty encapsulation alone does not prove sender identity, correct context or authorization.
Different KEMs rely on different assumptions. FIPS 203 specifies ML-KEM based on the Module Learning with Errors problem. Its properties do not make every KEM post-quantum, and the interface label removes no need to check parameters, implementation and composition.