person Tute World Team

NIST PQC Standards: FIPS 203, 204, 205

In August 2024, after an 8-year competition, NIST published the world's first post-quantum cryptographic standards. These three documents — FIPS 203, 204, and 205 — define the algorithms that will replace RSA and ECC. Here's what they are and what they replace.

The Three Standards at a Glance

FIPS 203

ML-KEM

Formerly: CRYSTALS-Kyber

Purpose: Key Encapsulation Mechanism (KEM)

Replaces: ECDH, RSA key exchange, classical DH

Based on: Lattice problems (Module Learning With Errors)

Use it for: Establishing shared secrets in TLS, VPNs, encrypted communications

FIPS 204

ML-DSA

Formerly: CRYSTALS-Dilithium

Purpose: Digital Signature Algorithm

Replaces: ECDSA, RSA signatures

Based on: Lattice problems (Module Learning With Errors)

Use it for: Code signing, TLS certificates, document signing, software updates

FIPS 205

SLH-DSA

Formerly: SPHINCS+

Purpose: Stateless Hash-Based Digital Signature

Replaces: ECDSA, RSA signatures (as a conservative alternative)

Based on: Hash functions only

Use it for: Long-lived signatures, offline signing, applications needing maximum conservatism

FIPS 203: ML-KEM (Module-Lattice Key Encapsulation Mechanism)

ML-KEM is the primary mechanism for establishing shared keys in post-quantum protocols. A Key Encapsulation Mechanism (KEM) is how two parties agree on a secret key — like Diffie-Hellman, but post-quantum.

Three parameter sets offer different security/performance tradeoffs:

VariantSecurity LevelPublic KeyCiphertextSecret Key
ML-KEM-512Level 1 (~128-bit)800 bytes768 bytes1,632 bytes
ML-KEM-768Level 3 (~192-bit)1,184 bytes1,088 bytes2,400 bytes
ML-KEM-1024Level 5 (~256-bit)1,568 bytes1,568 bytes3,168 bytes
Recommendation: ML-KEM-768 is the default recommendation for most applications — equivalent security to AES-192 at a reasonable size. ML-KEM-1024 for high-security applications. Google is deploying X25519Kyber768 (hybrid ECDH + ML-KEM-768) in Chrome.

How ML-KEM works (simplified)

Like public-key encryption, but specifically designed for key encapsulation:

  1. The server publishes its ML-KEM public key
  2. The client encapsulates a random shared secret using the public key → produces a ciphertext
  3. The server uses its private key to decapsulate → recovers the shared secret
  4. Both sides now have the same shared secret, which becomes the symmetric session key

An eavesdropper who intercepts the public key and ciphertext cannot recover the shared secret without solving the underlying lattice problem — which is hard for both classical and quantum computers.

FIPS 204: ML-DSA (Module-Lattice Digital Signature Algorithm)

ML-DSA is the primary post-quantum signature scheme. It replaces ECDSA and RSA signatures for authenticating software, certificates, and documents.

VariantSecurity LevelPublic KeySignature Size
ML-DSA-44Level 2 (~128-bit)1,312 bytes2,420 bytes
ML-DSA-65Level 3 (~192-bit)1,952 bytes3,293 bytes
ML-DSA-87Level 5 (~256-bit)2,592 bytes4,595 bytes

Compared to ECDSA P-256 (64-byte signature, 64-byte public key), ML-DSA signatures are significantly larger. But the performance overhead is manageable — signing and verification are fast.

FIPS 205: SLH-DSA (Stateless Hash-Based Digital Signature)

SLH-DSA (formerly SPHINCS+) is the most conservative post-quantum signature scheme. Its security is based solely on the security of the underlying hash function — making it extremely well-understood and trusted.

When to use SLH-DSA

SLH-DSA is slower and produces larger signatures than ML-DSA (typically 8–50 KB depending on parameter set). Use it when:

  • Maximum security conservatism is required (you don't want to bet on lattice hardness)
  • Long-lived signatures that must remain valid for decades (offline root CA keys)
  • Applications where signing is rare and performance doesn't matter
  • As a backup when lattice-based confidence is insufficient for the use case

Quick Reference: What to Use When

TLS key exchange → Was: ECDH → Now: ML-KEM-768 (or hybrid X25519+ML-KEM-768)
TLS certificates → Was: ECDSA / RSA → Now: ML-DSA-65
Code signing → Was: ECDSA / RSA → Now: ML-DSA-65 or SLH-DSA for long-lived keys
Root CA keys → Was: RSA-4096 / P-384 → Now: SLH-DSA (maximum conservatism for long-lived offline keys)
SSH keys → Was: Ed25519 / RSA → Now: ML-DSA or hybrid schemes

Frequently Asked Questions

Why are there two signature standards (ML-DSA and SLH-DSA)?

Diversity. If a flaw is discovered in the mathematical hard problem underlying ML-DSA (Module-LWE), SLH-DSA remains secure because it's based on hash functions — a completely different foundation. NIST standardized both to ensure no single point of failure in the post-quantum ecosystem. In practice, ML-DSA is preferred for performance; SLH-DSA as a conservative backup.

Are these FIPS standards available in major crypto libraries?

Yes and growing fast. OpenSSL added experimental PQC support in 3.x. liboqs (Open Quantum Safe) provides full implementations. AWS, Google Cloud, and Cloudflare are deploying ML-KEM in production. BoringSSL (used by Chrome, Android) supports X25519Kyber768. Adoption is accelerating rapidly following the August 2024 finalization.

Is there a fourth NIST PQC standard coming?

Yes — NIST is also standardizing FN-DSA (formerly FALCON), another lattice-based signature scheme with smaller signatures than ML-DSA. It's expected to be published as FIPS 206. Additionally, Classic McEliece (a code-based KEM) is being standardized as a conservative backup to ML-KEM.

← What is PQC? Next: Lattice-Based Cryptography →

Frequently Asked Questions

What will I learn here?

This page covers the core concepts and techniques you need to understand the topic and progress confidently to the next lesson.

How should I use this page?

Start with the overview, then follow the section links to deepen your understanding. Use the table of contents on the right to jump to specific sections.

What should I read next?

Use the navigation below to continue to the next lesson or explore related topics.