ML-KEM (Kyber) Key Encapsulation Demo
Try ML-KEM (Kyber, FIPS 203) in your browser: generate keys, encapsulate and decapsulate a shared secret, and see how the sizes compare with RSA and X25519.
How to use ML-KEM (Kyber)
- 1Pick a parameter set (ML-KEM-768 is the usual choice), then press Run full demo to see every step at once.
- 2Or go step by step: Generate key pair, Encapsulate with a public key, then Decapsulate with the secret key and ciphertext.
- 3Compare the two 32-byte shared secrets: when they match, both sides now hold the same key. Check the size table for the cost.
What makes it better
- ML-KEM-512, ML-KEM-768 and ML-KEM-1024 as standardised in FIPS 203
- Generate, Encapsulate and Decapsulate as separate steps, plus a one-click full demo
- Keys and ciphertext as Hex or Base64, with Copy and Download
- Sizes in bytes next to X25519 and RSA-3072 for context
- Pure JavaScript library run in your browser: no upload, no account
About ML-KEM (Kyber)
ML-KEM, formerly Kyber, is the NIST-standard key encapsulation method designed to stay safe against quantum computers. One side makes a key pair, the other uses the public key to produce a ciphertext and a shared secret, and the key holder recovers the same secret from the ciphertext. This demo runs ML-KEM-512, 768 and 1024 in your browser and shows how big the keys and ciphertexts are.
Common uses
- Learn how a key encapsulation mechanism differs from Diffie-Hellman or RSA encryption.
- Check the key and ciphertext sizes you will need to budget for in a protocol or certificate design.
- Produce test values to compare against your own ML-KEM implementation or a library you are evaluating.
- Explain post-quantum migration to a team with a live example instead of slides.
Example
Input
ML-KEM-768
Result
ML-KEM-768: public key 1,184 B · secret key 2,400 B · ciphertext 1,088 B · shared secret 32 B
Good to know
- ML-KEM is NIST-standardised (FIPS 203, August 2024). Real deployments usually combine it with a classical algorithm in a hybrid such as X25519MLKEM768, so one break does not expose traffic.
- Browsers do not offer ML-KEM through Web Crypto yet, so this page uses an audited pure-JavaScript library (@noble/post-quantum). Key generation here is not hardware-backed.
- These are demo keys: do not use them to protect real data. Secret keys stay in this tab, but the page cannot guard them from malware or extensions.
ML-KEM (Kyber) FAQ
What is ML-KEM and how is it related to Kyber?
ML-KEM is the name NIST gave to the standardised version of CRYSTALS-Kyber in FIPS 203. The algorithm is the same family with small changes, so old Kyber test vectors do not match ML-KEM output. Use the ML-KEM names for anything new.
What is key encapsulation?
Instead of encrypting your data directly, the sender uses the receiver's public key to create a fresh random shared secret and a ciphertext that wraps it. The receiver unwraps the same secret with the secret key. Both then use that secret with a fast cipher such as AES.
Which ML-KEM parameter set should I use?
ML-KEM-768 is the common default and the one in hybrid TLS deployments. ML-KEM-512 is smaller with a lower security level, and ML-KEM-1024 gives the highest margin for the largest keys. Both parties must use the same set.
Why does a wrong ciphertext still give me a secret instead of an error?
ML-KEM uses implicit rejection by design: decapsulating an altered ciphertext returns a pseudo-random secret that does not match the sender's. This hides whether the ciphertext was valid. The shared secrets simply will not match, and encryption using them fails.
Why are post-quantum keys so much bigger than X25519 keys?
Lattice-based schemes need larger public keys and ciphertexts to get their security. An ML-KEM-768 public key is 1,184 bytes against 32 for X25519. That extra size is the price of resisting an attacker with a large quantum computer.