August 2024 was the finish line. After eight years, NIST published three finalised post-quantum cryptography standards — FIPS 203, FIPS 204, and FIPS 205. Not drafts, not interim recommendations. Done.
Most of the commentary that followed was either too shallow — glossing over the maths entirely — or too deep, landing you in academic papers with no design rationale. This article is for you if you already know how RSA, ECC, and Diffie-Hellman work but want to understand what these algorithms actually do, why the specific choices resist quantum attack, and what the tradeoffs look like in practice.
This guide is part of our comprehensive series on why post-quantum cryptography is an urgent business risk — here we focus on the standards themselves: what they cover, how the algorithms work, and what changes for your infrastructure. Three finalised standards — one for key encapsulation, two for digital signatures. The comparison numbers come straight from the FIPS specifications.
What did NIST actually finalise in August 2024 and why does the timeline matter?
On 13 August 2024, NIST simultaneously published three Federal Information Processing Standards: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA). Finished standards, not interim guidance.
The eight-year timeline matters more than it might seem. The competition launched in 2016, first-round submissions arrived in 2017, and after multiple rounds of public analysis and attempted breaks, the standards landed in 2024. That rigour is also why “wait for something better” is not a viable strategy. There is no better algorithm coming soon. These are it.
FIPS 203 standardises ML-KEM, a key encapsulation mechanism derived from CRYSTALS-Kyber. FIPS 204 standardises ML-DSA, a lattice-based digital signature algorithm derived from CRYSTALS-Dilithium. FIPS 205 standardises SLH-DSA, a stateless hash-based digital signature scheme derived from SPHINCS+. Together they cover key establishment and digital signatures — the two operations that underpin most of the security stack.
Two further standards are in development. FIPS 206 will standardise FN-DSA (Falcon), a compact lattice-based signature scheme. In March 2025, NIST announced HQC had been selected as a code-based backup KEM. The spread across lattices, hash functions, and codes is deliberate policy — not indecision.
How does ML-KEM work — and why is key encapsulation different from key agreement?
Before getting into ML-KEM, the functional category matters.
A Key Encapsulation Mechanism (KEM) works like this: one party generates a shared secret and encrypts — “encapsulates” — it using the recipient’s public key. The recipient decapsulates using their private key. No bidirectional exchange. The encapsulator generates the secret; the decapsulator recovers it.
That is structurally different from Diffie-Hellman. In DH, both parties contribute randomness and arrive at a shared secret through a mathematical exchange. In a KEM, the encapsulator already knows the secret and the decapsulator recovers it after. Different security model, different protocol design implications.
ML-KEM (formerly CRYSTALS-Kyber), standardised as FIPS 203, implements this using the Module Learning with Errors (MLWE) lattice problem. It defines three operations — KeyGen, Encaps, Decaps — and always produces a 32-byte shared secret regardless of which parameter set you’re using. Both names remain in active use; standards documentation uses ML-KEM, while developer documentation often still says Kyber.
ML-KEM comes in three parameter sets for different risk and bandwidth profiles. ML-KEM-512 sits at NIST security level 1 (roughly AES-128 equivalent) and suits bandwidth-constrained environments. ML-KEM-768 sits at level 3 (~AES-192) and is the recommended default for most deployments. ML-KEM-1024 sits at level 5 (~AES-256) and is mandated by CNSA 2.0 for National Security Systems.
ML-KEM-768 is what Cloudflare uses for all TLS 1.3 connections via X25519MLKEM768, and it’s the parameter set adopted in age v1.3.0 via the mlkem768x25519 recipient type. Unless you’re building for national security systems or are severely bandwidth-constrained, ML-KEM-768 is your default.
For how ML-KEM and X25519 combine in production hybrid deployments, see the article on how ML-KEM and X25519 combine in hybrid key exchange.
Why do lattice problems defeat Shor’s algorithm — the mathematical intuition?
Shor’s algorithm solves two things: integer factorisation (breaking RSA) and the discrete logarithm problem (breaking ECDSA, ECDH, Diffie-Hellman). That is the complete scope. It does not solve all hard mathematical problems — just those two specific structures.
The Module Learning with Errors (MLWE) problem is a different structure entirely. Given a matrix A and a vector b = As + e, where s is a secret vector and e is a small random error vector, find s. Even knowing A and b, recovering s is computationally hard. There is no known reduction from MLWE to integer factorisation or discrete logarithm. Shor’s algorithm has no purchase on it.
The geometric intuition: a lattice is a regular grid of points in high-dimensional space. Finding the shortest or closest vector on that grid — the core hardness assumption — is exponentially hard even on quantum hardware. Quantum computers offer no known meaningful speedup over classical approaches for this problem.
Grover’s algorithm does provide a quadratic speedup for unstructured search, which effectively halves the security level of symmetric primitives. The fix is to double the security parameter. ML-KEM-768 at NIST level 3 accounts for this in its sizing. The comparison numbers later in this article only mean something if you trust this hardness assumption — MLWE security does not depend on what Shor’s attacks. That is the foundation.
For more on the threat driving urgency — the harvest-now-decrypt-later threat is the reason the migration clock is already running.
How do ML-KEM and X25519 compare — what do the numbers actually look like?
Wire size is the variable to plan around. ML-KEM’s computational overhead is negligible for most server-to-client workloads — the cost is bandwidth, not CPU.
From the FIPS 203 specification and Cloudflare’s production data, here is what the numbers look like.
X25519: 32-byte public key, 32-byte ciphertext, 64 bytes on the wire in total, ~128-bit classical security. ML-KEM-512: 800-byte public key, 768-byte ciphertext, ~1,568 bytes on the wire, NIST level 1. ML-KEM-768: 1,184-byte public key, 1,088-byte ciphertext, ~2,272 bytes on the wire, NIST level 3. ML-KEM-1024: 1,568-byte public key, 1,568-byte ciphertext, ~3,168 bytes on the wire, NIST level 5.
All three ML-KEM parameter sets produce the same 32-byte shared secret. The growth is in the public key and ciphertext — not the output.
In a TLS 1.3 handshake, switching from X25519 to ML-KEM-768 adds roughly 2.2KB to the wire exchange. Meaningful for high-frequency APIs or bandwidth-constrained connections; manageable for most web applications. Cloudflare reports that hybrid ML-KEM has negligible performance overhead even for short-lived TLS connections — and by October 2025 over 50% of their traffic was already using hybrid X25519MLKEM768.
ML-KEM-1024 is for CNSA 2.0 compliance. ML-KEM-512 is appropriate only where bandwidth is severely constrained and NIST level 1 genuinely suffices.
How does ML-DSA replace digital signatures and what changes for certificate chains?
ML-DSA (formerly CRYSTALS-Dilithium), standardised as FIPS 204, is a lattice-based digital signature scheme built on the same MLWE foundation as ML-KEM — applied to signing rather than key encapsulation. Both names remain in active use across documentation and libraries.
The size jump is the thing to understand here. An ECDSA P-256 signature is 64–72 bytes. ML-DSA-44 (NIST level 2) produces 2,420-byte signatures with a 1,312-byte public key. ML-DSA-65 (level 3) produces 3,293-byte signatures with a 1,952-byte public key — roughly 50 times larger than ECDSA P-256. ML-DSA-87 (level 5) produces 4,595-byte signatures with a 2,592-byte public key, and is mandated by CNSA 2.0 for National Security Systems.
That size change has real consequences for any system that stores, transmits, or validates signatures.
The certificate chain impact is where you feel it first. A three-certificate TLS chain — root CA, intermediate, end-entity — each signed with ML-DSA-65 adds approximately 10KB to a TLS handshake. ECDSA P-256 chains come in around 3KB. Manageable for most connections; meaningful for mobile clients and high connection-rate systems. Code signing artefacts and JWTs embedded with ML-DSA signatures will also grow materially.
Microsoft is researching and prototyping ML-DSA and SLH-DSA for device-bound request signing, with forthcoming integration into Active Directory Certificate Services.
For tooling and library support — where ML-DSA is available in production today — see the article on how these algorithms are already deployed in production tooling.
How do ML-DSA and ECDSA compare — and what is the signature size tradeoff you need to plan for?
The size numbers make the migration case concrete; the performance numbers complete it. From FIPS 204 and benchmarks from Encryption Consulting: ML-DSA-44 signs in ~0.35ms and verifies in ~0.08ms. ML-DSA-65 signs in ~0.45ms and verifies in ~0.12ms. ML-DSA-87 signs in ~0.65ms and verifies in ~0.19ms. ECDSA P-256 benchmarks are not directly comparable in milliseconds because they depend heavily on hardware — but they are generally faster for both operations.
Verification is fast and comparable to ECDSA. Signing is slower, but within an acceptable range for certificate issuance and most enterprise signing workloads.
The real migration work for ML-DSA is not compute — it is auditing and upgrading every system that handles signatures. Cloudflare noted that only 3.7% of origins supported post-quantum signatures as of September 2025, compared to 39% of the top 100,000 domains already supporting post-quantum key agreement. That gap is the signature migration challenge in a single statistic.
Where the size increase matters most: PKI certificate chains, mobile authentication flows, API token payloads (JWTs), and CI/CD or firmware distribution pipelines that embed signatures. ML-DSA-65 at NIST level 3 is the recommended default for TLS certificates, code signing, and identity verification. CNSA 2.0 requires ML-DSA-87.
When should you use SLH-DSA — the case for a mathematically independent backup?
SLH-DSA (formerly SPHINCS+), standardised as FIPS 205, is a stateless hash-based digital signature scheme. Its security relies entirely on cryptographic hash functions — SHA-256, SHAKE — not on lattice hardness assumptions.
If the MLWE lattice problem is ever broken, ML-KEM and ML-DSA are both compromised. SLH-DSA is not. There is no shared mathematical foundation. That independence is the whole point.
NIST standardised both ML-DSA and SLH-DSA for this reason: deliberate algorithm diversity. Two signature schemes from different mathematical families hedge against a breakthrough in either. The same logic drove the HQC selection — a code-based backup KEM alongside the lattice-based ML-KEM.
The tradeoff is size and speed. SLH-DSA-128s produces approximately 7,856-byte signatures; the fast variant SLH-DSA-128f produces approximately 17,088-byte signatures. Signing involves thousands of hash computations — potentially milliseconds where ML-DSA operates in sub-millisecond ranges. Verification is fast. Public keys are compact — typically 32 to 64 bytes, essentially a Merkle tree root hash.
SLH-DSA is the right choice for long-lived signatures: root CA certificates, firmware signing, legislative documents requiring multi-decade verifiability, or any context where independence from lattice assumptions is a policy requirement. For interactive authentication, TLS certificates, and API signing, ML-DSA is preferred.
SLH-DSA is also stateless — it uses pseudo-random key selection from an enormous Merkle tree, removing the state-management burden of alternatives like LMS/XMSS (NIST SP 800-208).
FN-DSA (Falcon), draft FIPS 206, is worth knowing about. It uses NTRU lattices rather than MLWE and produces compact signatures (~666 bytes for FN-DSA-512 versus ML-DSA-44’s 2,420 bytes), making it suitable for IoT and embedded systems where ML-DSA’s size is a practical constraint. Implementation complexity is high and it is not yet a finalised standard — but it is on the roadmap.
For production library and tooling context, see the article on how these algorithms are already deployed in production tooling.
Frequently asked questions
Is ML-KEM the same as CRYSTALS-Kyber?
Yes. NIST renamed CRYSTALS-Kyber to ML-KEM when it was standardised as FIPS 203 in August 2024. Both names remain in active use. Kyber768 = ML-KEM-768; Kyber1024 = ML-KEM-1024. When you see “Kyber” in a library or RFC, it refers to the same algorithm family.
Is ML-DSA the same as CRYSTALS-Dilithium?
Yes. NIST renamed CRYSTALS-Dilithium to ML-DSA when it was standardised as FIPS 204 in August 2024. Dilithium2 = ML-DSA-44; Dilithium3 = ML-DSA-65; Dilithium5 = ML-DSA-87.
Do I need to implement all three NIST standards, or just one?
Most organisations need both KEM and at least one signature scheme. ML-KEM covers key exchange for TLS, VPNs, and encrypted storage. ML-DSA and SLH-DSA cover certificates, code signing, and authentication tokens. SLH-DSA is typically adopted alongside ML-DSA as a conservative backup — not instead of it.
Are these algorithms approved for use in regulated industries?
FIPS 203, 204, and 205 are the global regulatory reference standards. They underpin CNSA 2.0, UK NCSC guidance, and EU migration frameworks. For FinTech, HealthTech, and SaaS businesses selling to regulated sectors, FIPS 203–205 is the de facto migration target.
How much slower are post-quantum algorithms compared to classical ones?
ML-KEM is competitive with X25519 — the overhead is bandwidth, not computation. ML-DSA verification is comparable to ECDSA; signing is slower but within acceptable range for most enterprise workloads. SLH-DSA signing is significantly slower; verification is fast. None of this presents a fundamental performance constraint for most enterprise use cases.
What does “NIST security level” mean?
Security levels map PQC algorithm security to the effort required to break the algorithm relative to AES. Level 1 = AES-128; level 3 = AES-192; level 5 = AES-256. ML-KEM-512 = level 1; ML-KEM-768 = level 3; ML-KEM-1024 = level 5. ML-DSA-44 = level 2; ML-DSA-65 = level 3; ML-DSA-87 = level 5. Level 3 is the recommended default for most enterprise deployments.
What is the MLWE problem and why can’t quantum computers solve it?
Module Learning with Errors: given a matrix A and a vector b = As + e (where s is a secret and e is small random noise), find s. Shor’s algorithm solves integer factorisation and discrete logarithm — it has no known reduction to lattice problems. Grover’s algorithm provides only a quadratic speedup, addressed by the parameter sizing in ML-KEM-768 and above.
Why did NIST standardise a hash-based signature scheme alongside ML-DSA?
Algorithm diversity. Two signature families with different mathematical foundations — lattices for ML-DSA, hash functions for SLH-DSA — hedge against a cryptanalytic breakthrough in either. If MLWE is ever broken, SLH-DSA remains secure.
Can I use hybrid ML-KEM + X25519 before migrating to pure ML-KEM?
Yes — and it is the recommended first step. X25519MLKEM768 is already deployed by Cloudflare, Chrome, Firefox, and Edge. By October 2025, over 50% of Cloudflare traffic used hybrid ML-KEM. Security holds as long as either algorithm remains unbroken. Architecture detail is in the article on how hybrid post-quantum cryptography works and why it is the right architecture for the transition.
Where can I find the official FIPS 203, 204, and 205 documents?
All three are at csrc.nist.gov: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA). NIST SP 800-227 covers KEM recommendations. NIST NCCoE SP 1800-38 provides practical migration guidance.
