ML-KEM Key Encapsulation Online | Post-Quantum Cryptography (FIPS 203)
Key Exchange How It Works
This tool runs the full FIPS 203 (ML-KEM) workflow in your browser using the @noble/post-quantum library. The recipient generates a key pair; the sender encapsulates a fresh random 32-byte shared secret against the public key, producing a ciphertext; the recipient decapsulates with their secret key to recover the same secret. Unlike ECDH, ML-KEM survives quantum computers because its security rests on the Module-LWE lattice problem, not discrete logarithms. All computation runs locally — no key material leaves your browser.
Parameter Set Comparison
| Parameter Set | Security | Public Key | Secret Key | Ciphertext | Used in |
|---|---|---|---|---|---|
| ML-KEM-512 | 128-bit (L1) | 800 B | 1632 B | 768 B | Bandwidth-constrained |
| ML-KEM-768 | 192-bit (L3) | 1184 B | 2400 B | 1088 B | TLS 1.3, Chrome, Signal |
| ML-KEM-1024 | 256-bit (L5) | 1568 B | 3168 B | 1568 B | Top-secret-grade |
Code Examples
Perform ML-KEM encapsulation programmatically:
// Browser — ML-KEM-768 with @noble/post-quantum
import { mlkem768 } from '@noble/post-quantum/ml-kem';
const { publicKey, secretKey } = mlkem768.keygen();
const { ciphertext, sharedSecret } = mlkem768.encapsulate(publicKey);
const recovered = mlkem768.decapsulate(ciphertext, secretKey);
// sharedSecret === recovered (both 32 bytes)# Python — ML-KEM-768 with pqcrystals-kyber
from pqcrystals_kyber.kyber768 import keygen, encapsulate, decapsulate
pk, sk = keygen()
ciphertext, shared_secret = encapsulate(pk)
recovered = decapsulate(ciphertext, sk)Security Notes
- Use hybrid schemes — for production, combine X25519 + ML-KEM-768 and derive transport keys with HKDF rather than using the raw secret directly.
- Rotate KEM keys — the shared secret of one encapsulation must never be reused across sessions without a KDF.
- Quantum-resistant — ML-KEM security rests on Module-LWE lattice problems; Shor's algorithm cannot break it.
Related Tools
Want to see the classical half of hybrid key exchange? Try the ECDH Key Exchange tool for X25519 demonstrations. Once you have a shared secret, use AES Encrypt/Decrypt for the actual message encryption. For generating classical ECC keys, try the ECC Key Generator tool.
Frequently Asked Questions
What is ML-KEM and how does it differ from ECDH?
ML-KEM (FIPS 203, standardized by NIST in August 2024 and formerly known as Kyber) is a Key Encapsulation Mechanism. Instead of the interactive two-way dance of Diffie-Hellman, a KEM is one-shot: the recipient publishes a public key, the sender encapsulates a fresh random secret against it producing a single ciphertext, and the recipient decapsulates that ciphertext with their secret key to recover the same secret. Functionally both establish a shared secret — but ML-KEM survives quantum computers, while ECDH does not.
Which parameter set should I choose?
ML-KEM-512 targets 128-bit security, ML-KEM-768 targets 192 bits, and ML-KEM-1024 targets 256 bits. ML-KEM-768 is the practical default: it is the exact set deployed in TLS 1.3 hybrid key agreement by Chrome, Firefox, OpenSSL, Cloudflare, and Signal, and it corresponds to security level 3 in the FIPS 203 category ladder. Use 512 only where bandwidth is extremely tight, and 1024 for top-secret-grade margins.
Why is ML-KEM considered quantum-resistant?
Its security rests on the Module Learning With Errors (Module-LWE) problem over module lattices. The best known quantum attacks (essentially variants of lattice reduction) still cost super-polynomial time, and crucially, Shor's algorithm — which breaks ECDH and RSA outright by computing discrete logs and factoring — does not apply to lattice problems. A future quantum computer therefore cannot recover the shared secret from the public key and ciphertext.
What is hybrid key agreement and why combine ML-KEM with X25519?
Hybrid mode runs both a classical exchange (X25519) and a post-quantum KEM (ML-KEM-768) and combines the two shared secrets into one key. This gives defense in depth: if a weakness is ever found in ML-KEM implementations, classical ECDH still protects the session, and once quantum computers arrive, the lattice half still protects it. This is exactly what TLS 1.3 deployments (X25519MLKEM768) and Signal (PQXDH) do today. Try the X25519 exchange in our ECDH tool to see the classical half.
What should I do with the 32-byte shared secret?
The decapsulated secret is already a uniform, uniformly-random 256-bit value — unlike raw ECDH output, ML-KEM internally applies a hash-based extractor, so it can be used directly as an AES-256 key. In real protocols you would still feed it into a KDF (HKDF) together with transcript context to bind it to the session. Note that a KEM does not encrypt your data itself: it establishes the key; use the AES or ChaCha20 tools for the actual message encryption.
Privacy: This tool runs entirely in your browser — nothing is uploaded or stored. · Disclaimer: For educational purposes only. Not professional security advice.
More in Key Exchange
RSA Key Generator
Generate RSA key pairs online in PEM, DER, JWK, SSH, or PKCS#1 format. Batch generation, passphrase encryption, key import.
ECC / ECDSA Key Generator
Generate ECC key pairs on P-256, P-384, P-521, and secp256k1 online. Export PEM/JWK/hex, sign and verify ECDSA, derive ECDH secrets.
ECDH Key Exchange
Perform ECDH key exchange online across P-256, P-384, P-521, secp256k1, and X25519. Compute shared secrets, derive symmetric keys.