Part II, Practitioner · Lesson 7
Meet the new standards: ML-KEM, ML-DSA and friends
The short version
Computers lock messages with math puzzles that a big enough quantum computer could solve. In 2024 the US standards lab, NIST, published three new puzzles that quantum computers aren't known to be good at. One is for agreeing on a secret key; two are for signing things. The catch: the new keys and signatures are much bigger.
You'll learn to
- Name the three NIST post-quantum standards published on 13 August 2024 and say what job each one does.
- Explain the difference between a key-encapsulation mechanism (KEM) and a digital signature.
- Compare classical and post-quantum key, ciphertext and signature sizes, and say why size is the main practical cost.
- Choose a sensible parameter set for a given use, including the CNSA 2.0 choices.
The Foundations track ended with a problem: Shor's algorithm breaks RSA, Diffie-Hellman and elliptic-curve cryptography, and harvest now, decrypt later means some of that damage is being banked today. Symmetric cryptography such as AES mostly survives (Grover's algorithm is a nuisance, not a catastrophe). So the job is to replace the public-key parts.
This lesson is the field guide to the replacements. You don't need the math. You need to know the names, what each one is for, what it costs, and which one to reach for.
Three standards, one date
On 13 August 2024, the US National Institute of Standards and Technology (NIST) published its first three post-quantum cryptography standards as Federal Information Processing Standards (FIPS). They came out of a multi-year public competition, and each got a new official name in place of its competition nickname.
| Standard | Name | Was called | Job | Built on |
|---|---|---|---|---|
| FIPS 203 | ML-KEM | CRYSTALS-Kyber | Agree on a shared secret key | Module lattices |
| FIPS 204 | ML-DSA | CRYSTALS-Dilithium | Digital signatures | Module lattices |
| FIPS 205 | SLH-DSA | SPHINCS+ | Digital signatures | Hash functions only |
The names are less cryptic than they look. ML means "module-lattice": the hard problem underneath is a lattice problem called Module Learning With Errors, a structured version of the Learning With Errors problem Oded Regev introduced in 2005. SLH means "stateless hash-based". KEM is a key-encapsulation mechanism and DSA is a digital signature algorithm. Engineers who want to see the lattice machinery can visit Lattices and Learning With Errors; everyone else can treat it as a well-studied puzzle that no known quantum algorithm cracks efficiently.
Two jobs: key exchange and signatures
Public-key cryptography does two different jobs in almost every protocol you run, and the new standards split along the same line.
Agreeing on a key: ML-KEM
A key-encapsulation mechanism (KEM) lets two parties end up with the same secret over an open network. One side publishes an encapsulation key (a public key). The other side uses it to "encapsulate" a fresh random secret, producing a ciphertext. Only the holder of the matching private key can "decapsulate" the ciphertext and recover the same secret. Both sides then feed that secret into AES or another symmetric cipher for the actual data.
This is the job Diffie-Hellman and elliptic-curve Diffie-Hellman (ECDH) do today in TLS, SSH and VPNs. It is also the job that harvest now, decrypt later threatens right now, which is why ML-KEM is the first thing most organizations deploy.
A KEM isn't a perfect drop-in for Diffie-Hellman. With Diffie-Hellman, both sides send a public value and combine them symmetrically. With a KEM, one side sends a key and the other answers with a ciphertext. Protocols such as TLS 1.3 fit this shape easily; some custom protocols need redesign.
Proving who sent it: ML-DSA and SLH-DSA
A digital signature proves that a message, certificate or software update came from the holder of a private key and hasn't been altered. RSA and ECDSA signatures are everywhere: website certificates, code signing, firmware updates, document signing, DNSSEC. Signatures aren't threatened by harvesting (you can't retroactively forge a signature that was already checked), but once a quantum computer exists, an attacker could forge new ones. Anything that must still be trusted years from now, such as firmware roots of trust, needs a head start.
NIST standardized two signature schemes on purpose. ML-DSA is the general-purpose choice: fast, with moderate sizes. SLH-DSA relies only on the security of hash functions, which cryptographers consider a very conservative assumption, and pays for that with much larger, slower signatures. If lattices ever turn out weaker than expected, SLH-DSA is the backstop.
The real cost: size
For most deployments, the cost practitioners actually feel isn't speed. It's bytes. Play with the chart, and switch between key exchange and signatures.
Some numbers worth remembering (all in bytes):
- An X25519 public key is 32. An ML-KEM-768 encapsulation key is 1,184 and its ciphertext 1,088.
- An Ed25519 signature is 64. An ML-DSA-65 signature is 3,309, about 50 times bigger, and its public key is 1,952.
- SLH-DSA-SHA2-128s has a tiny 32-byte public key but a 7,856-byte signature. The "f" (fast-signing) variant is 17,088.
Size matters wherever something was designed around small keys: a packet that used to fit in one network round trip, a database column sized for 256 bytes, a smart card with a few kilobytes of storage, a certificate chain sent on every connection. Much of the practical migration work in later lessons comes down to this one fact.
Parameter sets: picking a size
Each standard comes in several parameter sets, trading size for security margin. NIST rates them in security categories: category 1 means breaking it should take at least as much computation as a brute-force search for an AES-128 key; category 3 matches AES-192; category 5 matches AES-256. (Categories 2 and 4 are pegged to finding collisions in SHA-256 and SHA-384.)
| Parameter set | Category | Public key | Ciphertext or signature |
|---|---|---|---|
| ML-KEM-512 | 1 | 800 | 768 |
| ML-KEM-768 | 3 | 1,184 | 1,088 |
| ML-KEM-1024 | 5 | 1,568 | 1,568 |
| ML-DSA-44 | 2 | 1,312 | 2,420 |
| ML-DSA-65 | 3 | 1,952 | 3,309 |
| ML-DSA-87 | 5 | 2,592 | 4,627 |
| SLH-DSA-SHA2-128s / 128f | 1 | 32 | 7,856 / 17,088 |
In practice:
- ML-KEM-768 is the mainstream default. It's the one inside the hybrid key exchange that Chrome, Firefox, Safari and OpenSSL now use (next lesson).
- ML-KEM-1024 and ML-DSA-87 are what the US National Security Agency's CNSA 2.0 suite requires for national security systems. If you sell to that market, those are your numbers.
- ML-DSA-44 or ML-DSA-65 are typical general-purpose signature choices where size is tight.
- SLH-DSA suits rare, high-value signatures where the conservative assumption is worth the bytes, such as a root key that signs once a year.
The friends: what's coming and what's already there
FN-DSA (forthcoming FIPS 206)
A fourth signature standard, FN-DSA, is based on the Falcon submission and will be FIPS 206. It is still in development. Its main attraction is smaller signatures than ML-DSA. Treat it as forthcoming, and don't design around it until it's final.
HQC, the backup KEM
On 11 March 2025, NIST selected HQC, a KEM built on error-correcting codes rather than lattices, as a backup to ML-KEM. A draft standard is expected later. The point is diversity: if a breakthrough ever hurt lattices, there would be a standardized KEM built on unrelated math.
Stateful hash-based signatures: LMS and XMSS
Before the FIPS trio, NIST had already approved two hash-based signature schemes in SP 800-208 (2020): LMS (RFC 8554) and XMSS (RFC 8391). They are small and fast to verify, and CNSA 2.0 names them for software and firmware signing. The catch is in the word stateful: the signer must track which one-time keys it has used, and reusing one is catastrophic. They suit tightly controlled signing systems, not general use. Lesson 12 covers them in context.
Why diversity matters: the ones that didn't make it
Not every candidate survived the competition, and the failures are instructive.
- SIKE, an isogeny-based KEM, was broken in July 2022 by Wouter Castryck and Thomas Decru. The attack was classical, not quantum, and recovered a SIKEp434 key in about an hour on a single core.
- Rainbow, a multivariate signature scheme and a finalist, was broken in 2022 by Ward Beullens with an attack that took "a weekend on a laptop".
Both had survived years of review. That is why practitioners deploy the new algorithms in hybrid mode alongside a classical one for now, why NIST standardized backups based on different math, and why crypto-agility gets a lesson of its own.
What this means for your roadmap
- Key exchange first. ML-KEM (usually ML-KEM-768 in a hybrid) protects against harvest-now attacks today.
- Signatures next, but plan now. ML-DSA for general use, SLH-DSA or LMS/XMSS where a conservative or firmware-oriented choice fits. Long-lived devices need verification support built in before they ship.
- Audit for size assumptions. Fixed buffers, column widths and message limits are where migrations break.
- Keep AES-256 and SHA-384 or better where you're subject to CNSA 2.0; elsewhere AES-128 remains acceptable to NIST.
- Don't build your own. Use validated library implementations. The algorithms are public, but implementing them safely is specialist work (see Implementation pitfalls).
Summary
- NIST published FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) on 13 August 2024.
- ML-KEM agrees on keys; ML-DSA and SLH-DSA sign. Key exchange is the urgent one because of harvest-now-decrypt-later.
- The main practical cost is size: an ML-DSA-65 signature is 3,309 bytes versus 64 for Ed25519.
- ML-KEM-768 is the mainstream default; CNSA 2.0 requires ML-KEM-1024 and ML-DSA-87.
- FN-DSA (FIPS 206) is forthcoming and HQC is a code-based backup KEM; SIKE and Rainbow show why diversity and hybrids matter.
Questions
Get five of six right to mark the lesson complete. They also feed the final exam.
Sources
- NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard
- NIST FIPS 204: Module-Lattice-Based Digital Signature Standard
- NIST FIPS 205: Stateless Hash-Based Digital Signature Standard
- NIST: Security (evaluation criteria), security categories 1 to 5
- NIST: NIST selects HQC as fifth algorithm for post-quantum encryption (March 2025)
- NIST SP 800-208: Recommendation for Stateful Hash-Based Signature Schemes
- Castryck and Decru: An efficient key recovery attack on SIDH (2022)
- Beullens: Breaking Rainbow takes a weekend on a laptop (2022)
