The term on this page
- KEMkey encapsulation mechanism
- a scheme that agrees a shared secret rather than encrypting a message directly
Also mentioned
ML-KEMML-KEMModule-Lattice-based Key Encapsulation MechanismModule-Lattice-Based Key-Encapsulation Mechanism, the NIST-standardized post-quantum KEM derived from CRYSTALS-Kyber and specified in FIPS 203.Read the full entry (new tab), FIPSFIPSFederal Information Processing StandardFederal Information Processing Standards, publicly announced standards developed by NIST for use in U.S. government computer systems, including cryptographic algorithms and modules.Read the full entry (new tab), NISTNISTNational Institute of Standards and TechnologyThe U.S. National Institute of Standards and Technology, the agency that develops and publishes cryptographic standards, including the FIPS series and post-quantum algorithms.Read the full entry (new tab), PQCPQCpost-quantum cryptographyCryptographic algorithms designed to run on today's classical computers while remaining secure against attacks by both classical and future quantum computers.Read the full entry (new tab) are defined in the glossary.
Read this first
The IETF LAKE working group published revision 01 of its KEM-authentication draft on 28 September 2026. It defines a signature-free method in which an initiator and responder use one ephemeral and two static KEM exchanges, then confirm the result across five messages. With ML-KEM, the design aims at quantum-resistant authentication for constrained systems. It remains an Internet-Draft, and its suggested method identifier is not yet an assigned interoperable target.
The new draft-ietf-lake-authkem-edhoc-01 is not just ML-KEM inserted into an existing three-message exchange. The design changes when each peer can prove possession of its long-term key. Because a KEM peer must first receive a ciphertext encapsulated to its static public key, the draft adds explicit key-confirmation messages and delays final mutual authentication until the exchange is complete.
LAKE is the Lightweight Authenticated Key Exchange protocol previously expanded as Ephemeral Diffie-Hellman over COSE, or EDHOC. RFC 9528 defines the compact authenticated exchange used with constrained applications such as CoAP and OSCORE. Revision 01 keeps that CBOR-based framework, but translates its static-DH authentication pattern into a KEM-only construction derived from the Noise XX pattern.
Three shared secrets feed one final key
| Contribution | First available | Role |
|---|---|---|
| ss_eph | Message 2 | Fresh ephemeral KEM secret that contributes forward secrecy |
| ss_R | After the responder decapsulates ct_R from message 3 | Binds the responder's static KEM key into the key schedule |
| ss_I | After the initiator decapsulates ct_I from message 4 | Binds the initiator's static KEM key into the key schedule |
| PRK_out | After all three contributions and transcript checks | Source for application keying material |
The mechanism uses KEMs for two jobs. The ephemeral pair establishes fresh shared material. The static pairs act as authentication credentials: successful decapsulation plus later MAC verification demonstrates possession of the corresponding private keys. Revision 01 now cites NIST SP 800-227 for this key-confirmation model and makes the three-secret chain explicit.
Five messages postpone authentication on purpose
- Message 1 sends the selected method, offered suites, the initiator's ephemeral KEM public key and connection data.
- Message 2 returns the ephemeral ciphertext and the responder credential, protected with material derived from ss_eph.
- Message 3 carries ct_R and the initiator credential. The responder can now derive ss_R, but the exchange is not finished.
- Message 4 carries ct_I and MAC_2. The initiator derives ss_I and authenticates the responder after checking the protected transcript.
- Message 5 carries MAC_3. The responder authenticates the initiator, and both sides can complete the key schedule.
Encrypted does not yet mean authenticated
The draft says the KEM method provides no peer authentication until the final two messages. Message 3 also has weaker forward-secrecy properties than the completed exchange. External Authorization Data should be treated as unprotected, and applications should not persist PRK_out or derived keys until the five-message handshake, transcript checks and mutual authentication have all completed.
Revision 01 removes shortcuts and tightens KEM requirements
The revision commit changes 534 lines. It removes the earlier four-message variant and the draft's proposed cipher-suite table, leaving the five-message method and a suggested method type value of 5. It also expands the security analysis for forward secrecy, key-compromise impersonation, transcript binding and delayed authentication.
One constraint is especially important for implementers. IND-CCA2 security alone is not enough for the KEM used by this construction. The draft requires the derived shared secret to be cryptographically bound to the recipient public key, which is intended to prevent re-encapsulation and unknown key-share attacks. Static-key encapsulations and their ciphertexts must also be fresh for every session and must never be reused.
Who needs to track the draft
The immediate audience is protocol and firmware teams evaluating quantum-resistant authentication for constrained devices, gateways and OSCORE deployments. Migration leads should also add LAKE or EDHOC to the cryptographic inventory, which now calls out handshake method, message count, credential roles and the point at which authentication completes. An algorithm-only inventory would record ML-KEM and miss the state-machine change that controls when keys are safe to use.
The same distinction belongs in a PQC migration roadmap. Teams should separate algorithm conformance from protocol interoperability, and both from deployment cost on constrained hardware. FIPS 203 defines ML-KEM itself. This draft defines one possible authenticated protocol around a KEM. Those are different review and testing boundaries.
What to test before treating it as a target
- Pin revision 01 in every prototype and test report. Do not record the draft name without its revision.
- Verify all five transcript stages, including rejection when a ciphertext, credential or MAC is replayed or bound to the wrong public key.
- Measure total bytes, fragments, round trips, RAM, energy and timeout behavior on representative constrained devices and networks.
- Confirm ephemeral private material is erased and that static encapsulations, shared secrets and ciphertexts are never reused across sessions.
- Keep the experiment behind normal migration and audit gates. A successful prototype does not turn an Internet-Draft or suggested registry value into a stable deployment contract.
Revision 01 is a stronger engineering document than the July draft because it is clearer about delayed authentication, key binding and session freshness. It is still work in progress. The reliable next signals are another draft revision, an assigned registry value, interoperable implementations and eventually working-group consensus, not the presence of ML-KEM-512 in a configuration file.
References
- draft-ietf-lake-authkem-edhoc-01, published 28 September 2026.
- LAKE working-group revision 01 commit, including the security and IANA changes.
- RFC 9528, the base EDHOC protocol specification.
- NIST SP 800-227, recommendations for key-encapsulation mechanisms.
- FIPS 203, the ML-KEM algorithm standard.