Post-Quantum Readiness
NIST Post-Quantum Cryptography Standards Explained: FIPS 203, 204, and 205
Understand the three NIST post-quantum cryptography standards: ML-KEM for key encapsulation, ML-DSA and SLH-DSA for digital signatures. Learn what they replace and when migration starts.
NIST Post-Quantum Cryptography Standards Explained: FIPS 203, 204, and 205
In August 2024, NIST finalized three Federal Information Processing Standards that define the cryptographic algorithms that will replace RSA and ECC across the world's digital infrastructure. FIPS 203, FIPS 204, and FIPS 205 are the result of an 8-year competition that evaluated dozens of candidate algorithms against both classical and quantum attack models.
For enterprise security teams, this is the moment the PQC migration moved from "monitor the research" to "plan the program." This article explains each standard — what it does, what it replaces, and when migration is expected — in plain language.
FIPS 203: ML-KEM (Module-Lattice Key Encapsulation Mechanism)
What it does: Key encapsulation — the cryptographic operation that establishes a shared secret between two parties who have never communicated before. In today's TLS, this is typically done with ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) or, in older configurations, RSA key transport.
What it replaces: RSA-2048/4096 and ECDHE with P-256/P-384 for key establishment. Every TLS 1.3 handshake that uses ECDHE today will eventually use ML-KEM instead (or in combination, during the hybrid transition period).
How it works: ML-KEM is built on the CRYSTALS-Kyber algorithm. It uses structured lattices — mathematical objects in hundreds of dimensions — as the hard problem. Breaking ML-KEM requires solving the module learning with errors (M-LWE) problem, which is believed to be hard for both classical and quantum computers.
Key sizes: ML-KEM-768 (the primary parameter set) uses a 1,184-byte public key, 1,088-byte ciphertext, and 2,400-byte private key. These are larger than RSA keys but smaller than some pre-standardization estimates suggested.
Expected adoption timeline: Browsers, operating systems, and TLS libraries are integrating ML-KEM now. Chrome and Firefox have experimental support. OpenSSL 3.5+ includes Kyber. NIST expects production adoption to begin in 2025-2027 with widespread deployment by 2028-2030.
FIPS 204: ML-DSA (Module-Lattice Digital Signature Algorithm)
What it does: Digital signatures — the cryptographic operation that proves a message came from a specific sender and has not been tampered with. In today's infrastructure, this is RSA-PSS, RSA-PKCS#1 v1.5, or ECDSA.
What it replaces: RSA signatures (2048+ bit) and ECDSA (P-256/P-384) for document signing, code signing, certificate issuance, and authentication.
How it works: ML-DSA is built on the CRYSTALS-Dilithium algorithm. Like ML-KEM, it uses lattice-based mathematics. The security reduction is to the M-LWE and SelfTargetMSIS problems. Dilithium was selected for its strong security proofs and reasonable signature sizes.
Key sizes: ML-DSA-65 (the primary parameter set) produces 3,309-byte signatures with a 1,952-byte public key. Signatures are larger than RSA-2048 (256 bytes) or ECDSA (70 bytes) — about 10x bigger — which has implications for protocols where signature size matters (certificate chains, embedded devices, blockchain transactions).
Expected adoption timeline: Slower than ML-KEM due to larger signature sizes and the need for protocol-level accommodation. NIST expects ML-DSA adoption to ramp in 2026-2028, with government mandates driving early adoption.
FIPS 205: SLH-DSA (Stateless Hash-Based Digital Signature Algorithm)
What it does: Digital signatures — same function as ML-DSA, but based on a fundamentally different mathematical problem (hash functions rather than lattices).
What it replaces: Also RSA and ECDSA signatures, but intended as a backup or alternative to ML-DSA in environments where defense-in-depth at the algorithm level is required.
How it works: SLH-DSA is built on the SPHINCS+ algorithm family. It constructs signatures from hash functions (SHA-256 or SHAKE256) and Merkle trees. The security is based on the preimage resistance of the underlying hash function — a problem that is quantum-hard and extremely well-studied.
Key sizes: SLH-DSA produces larger signatures than ML-DSA — on the order of 7-50KB depending on the parameter set — but comes with the strongest security guarantees because hash function security is better understood than lattice security.
Expected adoption timeline: Specialized use cases first — long-term document signing, firmware signing, root of trust, high-assurance environments. Not expected to replace ML-DSA for general-purpose use due to signature size overhead.
Which Standard Should You Prepare For?
For most enterprises, the practical answer is: prepare for all three, but prioritize ML-KEM and ML-DSA.
- ML-KEM will touch every TLS endpoint, every VPN, every encrypted connection. Start with your TLS certificate inventory.
- ML-DSA will touch every certificate authority, every code signing pipeline, every document signing workflow. Start with your PKI inventory.
- SLH-DSA will be adopted selectively for high-assurance use cases. Monitor but don't prioritize unless you operate in defense or critical infrastructure.
The Hybrid Transition Period
NIST and major standards bodies recommend a transition period where both classical and post-quantum algorithms are used simultaneously:
- Hybrid key exchange: ECDHE + ML-KEM in TLS 1.3. If ML-KEM is broken, ECDHE still protects the session.
- Hybrid certificates: RSA + ML-DSA in X.509. If ML-DSA is broken, RSA still provides authentication.
The transition period is expected to last 5-10 years. During this time, systems will negotiate which algorithms to use, and both classical-only and hybrid-capable clients will be supported.
FAQ
Q: Is ML-KEM a direct drop-in replacement for RSA in TLS? A: Not exactly. ML-KEM handles key encapsulation differently than RSA key transport. TLS 1.3 already moved to ECDHE for key exchange, and ML-KEM follows the same pattern. The transition is smoother for systems already on TLS 1.3.
Q: Should we wait for NIST to finalize more standards before starting? A: No. The three core standards are finalized. Additional signature algorithm standards (like FN-DSA / FALCON) may follow, but FIPS 203/204/205 are the foundation and are ready now for planning and testing.
Q: Are these algorithms proven secure? A: They have undergone 8 years of public cryptanalysis through the NIST PQC competition. No practical attacks have been found. However, continued cryptanalysis is expected, which is why hybrid approaches are recommended during transition.
Q: What if a vulnerability is found in ML-KEM? A: One reason NIST standardized SLH-DSA (hash-based) alongside ML-DSA (lattice-based) is algorithm diversity. If a lattice-breaking result emerges, hash-based signatures remain secure. The hybrid transition period also provides defense-in-depth.
Start Free Readiness Scan →
View Sample Report →