密钥对、共享秘密与封装结果
密钥生成得到公开的封装密钥与保密的解封装密钥。发送一方以公开密钥执行封装，得到共享秘密和可传送的封装结果；持有对应私钥的一方对结果解封装，按机制条件获得相同秘密。
公开发送的是封装结果，不是把共享秘密直接附在报文里。算法还需规定输入检查、失败处理、参数与密钥格式；这些接口和保证依赖具体KEM，不能把一个方案的返回值或错误行为当成所有机制共同的实现细节。
封装不等于直接加密任意消息
KEM通常为后续机制提供固定用途的秘密材料。应用再用KDF派生所需密钥，并借助对称认证加密保护真正的内容；因此封装结果与内容密文是两个不同对象，增加正文长度也不意味着KEM必然逐块处理更多正文。
RFC 9180展示了这种组合接口，也用基于Diffie–Hellman的机制构建DHKEM。KEM是一个接口和安全目标类别，并非只指某一种数学难题或某个单独产品；是否支持发送者认证扩展，还取决于实际机制。
参考：[1]
数学机制与身份、抗量子属性分开
接收者公钥仍需可靠绑定到预期对象，否则封装可能安全地产生一个由错误对象掌握的秘密。基础封装也不能只凭结果非空就证明发送者身份、协议上下文正确或应用动作已获授权。
不同KEM依赖不同数学假设。NIST的FIPS 203规定ML-KEM，并说明其安全性与模格上的学习带错问题有关；这不意味着所有KEM都因此具有后量子保证，也不能仅因采用KEM接口就忽略参数、实现和协议组合的检查。