ML-KEM
Module-Lattice Key Encapsulation
The NIST post-quantum key exchange standard (FIPS 203). Formerly known as CRYSTALS-Kyber. Replaces ECDH to ensure key agreements remain secure against quantum computers.
What ML-KEM Does
Every time two systems establish an encrypted connection (TLS, federation handshake, VPN), they need to agree on a shared secret key. Today, this is done with ECDH (Elliptic Curve Diffie-Hellman). ML-KEM replaces ECDH with an algorithm based on the hardness of lattice problems -- a mathematical structure that quantum computers cannot efficiently solve.
ML-KEM is a Key Encapsulation Mechanism (KEM), not an encryption algorithm. It produces a shared secret that both parties can derive independently. That shared secret is then used with AES-256-GCM (or similar) for actual data encryption.
generates keypair
encapsulate
decapsulate
AES-256-GCM
Three Security Levels
| Variant | NIST Level | Key Size | Use Case |
|---|---|---|---|
ML-KEM-512 | 1 (AES-128 equivalent) | 800 bytes | Low-latency, general purpose |
ML-KEM-768 | 3 (AES-192 equivalent) | 1,184 bytes | Recommended for most enterprise use |
ML-KEM-1024 | 5 (AES-256 equivalent) | 1,568 bytes | High-security / national security systems |
ML-KEM-768 is the recommended default: strong enough for enterprise use, with manageable key sizes. Most implementations (Cloudflare, Google, Signal) use this level.
Hybrid Mode: The Transition Strategy
During the transition period, NIST recommends hybrid key exchange: combine classical ECDH with ML-KEM. The shared secret is derived from both, so security holds even if one algorithm is compromised.
This is already live in production at scale: Cloudflare and Google negotiate X25519Kyber768Draft00 (ECDH + ML-KEM-768) on TLS 1.3 connections. If your infrastructure runs behind Cloudflare, your connections may already be quantum-safe.
Why This Matters for Agent Platforms
- Federation: Agents from different organizations exchange data over the internet. If that key exchange is captured today, it could be decrypted when quantum computers arrive.
- CMEK wrapping: Customer-managed encryption keys protect tenant data at rest. Those keys are wrapped with key-encryption-keys that must be quantum-safe for long-term confidentiality.
- Regulatory pressure: DORA, SOX, HIPAA, and CNSA 2.0 are all converging on PQC requirements. Being prepared now avoids scrambling later.
How MeetLoyd Uses ML-KEM
MeetLoyd's federation architecture is designed for ML-KEM hybrid key exchange:
- TLS 1.3 enforced on all federation endpoints. ML-KEM hybrid is automatically negotiated when the infrastructure supports it (Cloudflare edge).
- Application-layer ML-KEM-768 planned for federation trust establishment -- the long-lived handshake that creates cross-org trust relationships.
- CMEK key wrapping roadmapped for ML-KEM-1024 transition -- highest security level for customer master keys.
- No third-party key escrow: BYOK architecture means encryption keys never leave the tenant's boundary. PQC protects the key exchange, not a third-party vault.