ML-KEM, Explained: Post-Quantum Key Exchange in Plain English

NIST finalized its first three post-quantum cryptography standards in 2024: one for establishing shared secret keys, and two for digital signatures. The signing side gets most of the crypto-holder attention, because that’s what guards a wallet. The key side, ML-KEM, is the one already built into your browser, ready to protect encrypted traffic against a quantum computer that doesn’t exist yet. The reason it can’t wait has a name: harvest now, decrypt later. Here’s what ML-KEM is, and why it’s rolling out first.

What a KEM is

KEM stands for key encapsulation mechanism, which is a precise way of saying a method for two parties to end up sharing a secret key over a channel anyone can read. That shared key then feeds an ordinary cipher like AES, which does the encrypting.

It’s the job classical Diffie-Hellman and elliptic-curve key exchange do today, the handshake at the start of nearly every secure connection. ML-KEM is the post-quantum replacement for that key-establishment role, built so no known classical or quantum algorithm can efficiently recover the agreed key from what it sees on the wire.

How it works, without the math

Picture two people, a sender and a receiver. The receiver publishes a public key for anyone to grab. The sender runs ML-KEM’s encapsulation step with that public key, and it produces two things at once: a shared secret and a ciphertext. The sender keeps the secret and sends the ciphertext across. The receiver combines that ciphertext with the matching private key to derive the very same secret. Now both hold an identical secret, and it never crossed the wire on its own.

The security rests on a lattice problem called Module Learning With Errors. An eavesdropper who grabs the public key and the ciphertext has everything except the private key, and pulling the secret out of those two pieces means solving that lattice problem, which has no known efficient attack, classical or quantum. That last part is the point. Shor’s algorithm dismantles the math behind today’s key exchange. No comparable shortcut is known against this one.

Why it’s rolling out fast: harvest now, decrypt later

You might wonder why encryption gets this push before signatures, when no quantum computer can break either one yet. The answer is a threat with a long fuse. An attacker can record your encrypted traffic today and decrypt it years later, once a capable quantum computer exists. Confidentiality has a shelf life. Traffic you send now can already be at long-term risk if someone stores it and the contents still need to stay secret when that machine arrives.

A forged signature, by contrast, mostly helps an attacker once quantum computers are here. You can’t fake today’s transaction retroactively. That asymmetry is why harvest now, decrypt later has pushed ML-KEM into network protocols so quickly. Signature migration is necessary too, and some long-lived signing keys need years of lead time, but the recorded-traffic problem is the one with a clock already running.

Already in your browser

ML-KEM isn’t a future plan. It’s live. The common deployment is a TLS hybrid called X25519MLKEM768, which pairs ML-KEM-768 with the classical X25519 exchange so the key-establishment step stays secure as long as either one holds. Chrome switched to the finalized version in Chrome 131, and Firefox turned it on by default on desktop from version 132. A given connection uses it only when the server supports it too, so the browser support is widespread and each site still depends on its own server. As of 2026 the hybrid is a formal TLS standard, written up in an IETF RFC.

The other cost is size. ML-KEM-768 uses a 1,184-byte public key and a 1,088-byte ciphertext, against a 32-byte share for X25519. That’s much larger, and still well within what a modern handshake absorbs. The pairing is deliberate: ML-KEM is young, so pairing it with a well-studied classical scheme means a break in ML-KEM alone doesn’t expose the shared key. An implementation bug or a botched combiner still could, which is why the hybrid is careful engineering rather than a promise.

What it means for your wallet

Here’s where crypto holders should place ML-KEM. It sets up the shared key that protects encrypted data moving between machines, like a browser connection to an exchange or custodian that supports hybrid post-quantum key establishment. A symmetric cipher such as AES does the encrypting with that key. ML-KEM doesn’t sign anything. The signature that proves you own your coins is a separate job, handled by post-quantum signature standards such as ML-DSA and SLH-DSA. A blockchain protects transaction authorization against quantum attacks by adopting a post-quantum signature scheme, and a key-establishment upgrade doesn’t do that job.

So ML-KEM and your on-chain security sit in different lanes. ML-KEM helps protect the confidentiality of what you send. The signature schemes protect the authenticity of what you sign. You want both eventually, and they arrive on different timelines. ML-KEM is turning up through browser and server updates you don’t see, and a chain’s move to post-quantum signatures is a slower, more visible affair. If you take one thing from this, take the split: harvest now, decrypt later makes encryption the migration with a running clock, and ML-KEM is the piece already going into place.