The thing being protected is a key, not your files
ML-KEM does one narrow job: it lets two parties agree on a shared secret over a public network without a future quantum computer being able to recover it later. It does not encrypt your data. Your files still get sealed with a symmetric cipher like AES-256-GCM, which quantum computers barely dent. The part that breaks under a quantum attack is the handshake that establishes the symmetric key in the first place, and that handshake is exactly what ML-KEM replaces.
This is where most of the confusion starts. People read "post-quantum encryption" and assume RSA gets swapped for a newer RSA. It doesn't. ML-KEM is a key-encapsulation mechanism (KEM), a different shape of primitive, and understanding that shape is the whole point.
What is ML-KEM?
ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) was standardized by NIST as FIPS 203 on 13 August 2024. It's the cleaned-up, renamed version of CRYSTALS-Kyber, which won NIST's eight-year post-quantum competition. The "Kyber" name still floats around in 2026 announcements; treat it as the same family.
A KEM has three operations, and they don't map onto how RSA works:
- KeyGen produces a public encapsulation key and a private decapsulation key.
- Encapsulate takes someone's public key and outputs a fresh random shared secret plus a ciphertext that wraps it.
- Decapsulate takes that ciphertext and the private key and recovers the same shared secret.
Notice what's missing: you never choose the secret. The KEM generates it for you. That's the structural break from RSA encryption, where you pick a message and encrypt it. With a KEM there is no message to pick, only a secret that pops out of the mechanism, identical on both ends, ready to feed a normal symmetric cipher. It's also why ML-KEM is not a drop-in for RSA key transport. Any protocol that assumed "encrypt this specific value with the public key" has to be rebuilt around encapsulate and decapsulate.
The security comes from lattices, specifically the Module Learning With Errors problem. The rough intuition: take a system of linear equations, add small random noise to every answer, and recovering the original solution becomes hard even for a quantum computer. Shor's algorithm shreds RSA and elliptic curves because they reduce to period-finding and discrete logs. It has no known traction on lattice problems. That's the bet.
Why are the key sizes so much bigger?
Lattice math isn't free. Here's ML-KEM-768, the level-3 parameter set (~AES-192 strength) everyone is shipping, against the classical curve it sits next to:
| Primitive | Public key | Ciphertext / wire cost | Shared secret |
|---|---|---|---|
| X25519 (classical ECDH) | 32 bytes | 32 bytes | 32 bytes |
| ML-KEM-768 (post-quantum) | 1184 bytes | 1088 bytes | 32 bytes |
The public key grows by roughly 37x, and the wire data per handshake jumps from 64 bytes to over 2 KB. AWS puts the added cost at roughly 1,600 extra bytes on the wire per hybrid TLS handshake. That's tolerable, but it can push the ClientHello past a single packet, which is why some early deployments tripped fragmentation bugs in old middleboxes. The output secret stays at 32 bytes, exactly what a symmetric cipher wants. ML-KEM-512 and ML-KEM-1024 trade size for security level in either direction; 768 is the middle the industry converged on.
Why does nobody ship ML-KEM alone?
Here's the part the hype skips. AWS, Google, Microsoft and the browser vendors are not betting everything on ML-KEM. They ship it hybrid, bolted alongside a classical algorithm (usually X25519), with both shared secrets folded into one session key.
The reasoning is honest paranoia. ML-KEM is new. Lattice cryptography has spent far less time under adversarial fire than elliptic curves, and the post-quantum graveyard includes schemes that looked solid and then fell: SIKE made it to the fourth round of NIST's process and was broken in 2022 by a classical attack running on a single CPU core in about an hour. A hybrid construction means a flaw in the new math can't leave you worse off than today's TLS. The session key is derived from both halves, so the failure modes are bounded. If lattices hold up, you're protected against a future quantum computer. If ML-KEM has an undiscovered classical break, X25519 still holds the line exactly as it does now.
This pattern is captured in X-Wing (an IETF CFRG draft), a hybrid KEM combining X25519 and ML-KEM-768 that stays secure if either component is secure, and Google Cloud KMS now offers it as a key-encapsulation option. AWS ships the same idea as ECDH-plus-ML-KEM hybrid TLS across KMS, ACM and Secrets Manager, retiring the older Kyber draft in 2026. Microsoft wired ML-KEM into SymCrypt and the Windows crypto stack (CNG) in late 2025. And the codepoint X25519MLKEM768 became the default key exchange in Chrome, with Firefox already matching it, which means a large slice of TLS handshakes on the web in 2026 are quietly hybrid post-quantum whether the operators noticed or not.
Why bother now, before quantum computers exist?
Because the threat isn't future decryption of future traffic. It's harvest now, decrypt later: an adversary records your encrypted traffic today and stores it until a cryptographically relevant quantum computer exists. Anything with a long confidentiality lifetime is exposed retroactively the day that machine boots, the contents of a cloud drive very much included. Key exchange is the right place to start the migration because a recorded handshake is precisely what a harvester wants. Make the key agreement quantum-safe and the recorded session stays sealed even if the recording survives twenty years.
This is the one piece of the migration that genuinely can't wait for the hardware to arrive, which is why the hybrid rollout is happening at the protocol layer first.
What's settled and what isn't
Settled: ML-KEM itself. FIPS 203 is final, the parameter sets are fixed, and production implementations live in BoringSSL, OpenSSL, SymCrypt and the major cloud KMS products. If you're choosing a post-quantum KEM in 2026, ML-KEM-768 is the safe default, and there's no real debate about that.
Still settling: how to combine it. The exact hybrid construction (which combiner, X-Wing versus a generic KDF-based mix, how it slots into TLS and SSH and IKEv2) is still moving through IETF drafts. Long-term identity is further behind: the post-quantum signature story (ML-DSA / FIPS 204) and the migration of certificate chains will take years. And "quantum-resistant" is a claim about the best attacks we currently know, not a proof. Anyone selling you "unbreakable" post-quantum crypto is selling the same overconfidence that made "harvest now, decrypt later" a viable strategy in the first place.
Where beebeeb sits on this
We'll be straight about it. beebeeb's file encryption today rests on AES-256-GCM for content, X25519 for the key exchange in sharing, Argon2id for password-derived keys, and OPAQUE for login. That's a classical stack, not yet hybrid post-quantum at the key-exchange layer. The symmetric core (AES-256) is already quantum-resistant in any practical sense: Grover's algorithm only halves its effective strength, leaving 128 bits, which is fine. The work to do is on the asymmetric side, and migrating to a hybrid X25519+ML-KEM key exchange (the same pattern the cloud providers shipped) is on our roadmap rather than done. We'd rather tell you what we actually run than imply a checkbox we haven't earned. You can read the current design on our security page, and