← Week 1: The Quantum Threat

Day 5: NIST PQC Landscape — Standards and Candidates

Phase 3 · July 12, 2026

← Week 1: The Quantum Threat

Agenda (2–3 hours)

  • Read (60 min): NIST FIPS 203 §1–2 (ML-KEM overview); NIST FIPS 204 §1–2 (ML-DSA overview); NIST FIPS 205 §1–2 (SLH-DSA overview)
  • Study (45 min): KEMs vs. signatures, algorithm families, when to use each
  • Challenge (45 min): Algorithm selection matrix
← Week 1: The Quantum Threat

The Four Finalized NIST PQC Standards (2024)

Standard Name Type Hard Problem Primary Use
FIPS 203 ML-KEM KEM MLWE Key exchange in TLS, key wrapping
FIPS 204 ML-DSA Signature MLWE/MSIS Cert signing, code signing
FIPS 205 SLH-DSA Signature Hash functions Cert signing (conservative)
FIPS 206 FN-DSA (FALCON) Signature NTRU lattice Compact signatures

KEMs vs. signatures: these solve different problems.

  • KEM (Key Encapsulation Mechanism): replaces ECDH for key exchange
  • Signature: replaces ECDSA/RSA for authentication
← Week 1: The Quantum Threat

Key Encapsulation Mechanism (KEM)

A KEM is not a key exchange — it's one-way encapsulation:

[KeyGen]  recipient: (pk, sk) ← ML-KEM.KeyGen()
[Encaps]  sender: (ciphertext, shared_secret) ← ML-KEM.Encaps(pk)
          sender transmits: ciphertext
[Decaps]  recipient: shared_secret ← ML-KEM.Decaps(sk, ciphertext)

Both sender and recipient now have the same shared_secret.
Unlike ECDH, only the recipient needs to do computation. The sender's work is cheap.

In TLS: the client encapsulates to the server's KEM public key.
The server decapsulates to get the shared secret. Both derive traffic keys from it.

← Week 1: The Quantum Threat

ML-DSA vs. SLH-DSA: Which Signature Scheme?

ML-DSA SLH-DSA
Based on Lattice (MLWE/MSIS) Hash functions only
Security assumption Newer, less studied Very conservative (SHA-2/3)
Signature size 2420–4627 bytes 7856–49856 bytes
Verification speed Fast Slow (large sigs)
Key size Small Small public key, large sig
Best for General use, TLS certs Long-term / ultra-conservative

Recommendation: ML-DSA for most uses (including TLS cert signing).
SLH-DSA for root CA keys where you want maximum conservatism and sign rarely.

← Week 1: The Quantum Threat

FN-DSA (FALCON): The Compact Option

FALCON produces the smallest signatures of any NIST PQC standard:

  • FALCON-512: ~666-byte signatures (vs ML-DSA-44's 2420 bytes)
  • Based on NTRU lattice problems (distinct from LWE)
  • More complex to implement securely (timing side-channels in sampling)
  • Less implementation momentum than ML-DSA

For your provisioning service: ML-DSA is the safer default.
FALCON is worth knowing about for constrained devices (IoT, satellite terminals)
where signature size matters.

← Week 1: The Quantum Threat

What's NOT in the NIST Standards (Yet)

  • BIKE, HQC: code-based KEMs, still in Round 4 evaluation
  • McEliece: very old code-based scheme, enormous key sizes
  • SIKE: completely broken (2022) — this is a reminder that PQC evaluation takes time
  • Composite certs: not standardized, but IETF drafts exist

SIKE's break (by a classical algorithm in an hour on a laptop!) is a strong reminder:
don't use draft or non-standardized PQC algorithms in production.
Only FIPS 203/204/205/206 for new implementations.

← Week 1: The Quantum Threat

Challenge Assignment

Create an algorithm selection matrix for your provisioning service:

For each of these use cases, recommend the appropriate NIST PQC algorithm and justify:

Use case Current algorithm Recommended PQC Justification
TLS key exchange (provisioning API) X25519 ECDHE
TLS cert signature (leaf cert) ECDSA P-256
Intermediate CA cert signature ECDSA P-384
Root CA cert signature RSA-4096
Device firmware signing ECDSA P-256
OCSP response signing ECDSA P-256

Save to your migration roadmap as "Algorithm Recommendations."

← Week 1: The Quantum Threat

Resources

  • NIST FIPS 203, 204, 205, 206: pubs.nist.gov (all freely available)
  • NIST PQC project page: csrc.nist.gov/projects/post-quantum-cryptography
  • SIKE break: eprint.iacr.org/2022/975 (cautionary reading)