NIST Post-Quantum Cryptography Standards

The Road to Post-Quantum Standards

NIST launched its post-quantum cryptography standardization process in 2016. The goal was clear: identify and standardize algorithms that resist attacks from both classical and quantum computers.

The process received 69 submissions from research teams worldwide. Over three evaluation rounds spanning eight years, NIST assessed each candidate for security, performance, and implementation characteristics. Cryptographers published thousands of papers analyzing the submissions.

In August 2024, NIST published three final standards:

• ML-KEM — FIPS 203 — Key encapsulation mechanism
• ML-DSA — FIPS 204 — Digital signature algorithm
• SLH-DSA — FIPS 205 — Stateless hash-based digital signature algorithm

Each standard addresses a specific cryptographic function that quantum computers threaten.

ML-KEM: FIPS 203

ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) replaces RSA key transport and ECDH key agreement. When two parties establish an encrypted session — a TLS handshake, a VPN tunnel, an encrypted email exchange — ML-KEM securely generates and transmits the shared symmetric key.

How ML-KEM Works

ML-KEM builds on the Module Learning With Errors (MLWE) problem. The sender encapsulates a random secret using the recipient’s public key. The recipient decapsulates it with their private key. An eavesdropper cannot recover the secret without solving the underlying lattice problem.

The algorithm operates in three steps:

1. Key generation produces a public key and private key pair.
2. Encapsulation takes the public key and produces a ciphertext and shared secret.
3. Decapsulation takes the private key and ciphertext to recover the shared secret.

Security Levels and Key Sizes

ML-KEM defines three parameter sets mapped to NIST security levels:

ML-KEM-768 is the recommended default for most applications. It balances security margin with performance overhead.

Performance Characteristics

ML-KEM operations are fast. Key generation, encapsulation, and decapsulation each complete in microseconds on modern hardware. In many benchmarks, ML-KEM-768 outperforms ECDH P-256 in raw computation speed.

The trade-off is bandwidth. ML-KEM-768 adds roughly 2 KB to a TLS handshake compared to ECDH. For most web applications, this overhead is negligible. For constrained IoT devices or high-frequency trading systems, it requires evaluation.

ML-DSA: FIPS 204

ML-DSA (Module-Lattice-Based Digital Signature Algorithm) replaces RSA and ECDSA for digital signatures. Certificates, code signing, document authentication, and any system that verifies identity or data integrity through signatures will transition to ML-DSA.

How ML-DSA Works

ML-DSA also builds on the MLWE problem, but applies it to signature generation and verification. The signer uses their private key to produce a signature over a message. Any party with the corresponding public key can verify the signature’s authenticity.

The algorithm uses a “Fiat-Shamir with Aborts” technique. The signer generates candidate signatures and rejects those that would leak information about the private key. This rejection sampling ensures security but means signing time varies slightly between operations.

Security Levels and Sizes

ML-DSA-65 is the recommended default. It provides strong security with manageable signature sizes.

Impact on Certificate Infrastructure

ML-DSA signatures are 50x larger than ECDSA P-256 signatures. A certificate chain with three ML-DSA-65 certificates adds roughly 10 KB compared to under 1 KB for an equivalent ECDSA chain.

This size increase affects TLS handshake latency, especially on mobile networks. Certificate transparency logs grow faster. Hardware security modules (HSMs) need firmware updates to support the new algorithm.

QCecuring’s CLM platform tracks every certificate in your infrastructure. When you begin reissuing certificates with ML-DSA signatures, CLM automates the renewal process and validates that new certificates deploy correctly across all endpoints.

SLH-DSA: FIPS 205

SLH-DSA (Stateless Hash-Based Digital Signature Algorithm) provides a digital signature scheme built entirely on hash functions. It does not use lattice mathematics.

Why Hash-Based Signatures Matter

ML-KEM and ML-DSA both depend on the hardness of lattice problems. If future research discovers an efficient algorithm for solving MLWE — classical or quantum — both standards would be compromised simultaneously.

SLH-DSA eliminates this single-point-of-failure risk. Its security depends only on the properties of the underlying hash function (SHA-256 or SHAKE-256). Hash functions have decades of cryptanalysis behind them and resist quantum attacks with only a quadratic speedup from Grover’s algorithm.

NIST recommends SLH-DSA as a conservative alternative for high-assurance applications where algorithm diversity is a priority.

Security Levels and Sizes

SLH-DSA offers multiple parameter sets optimized for either small signatures or fast operations:

The “s” variants minimize signature size. The “f” variants optimize for signing speed. Public keys are compact, but signatures are large — significantly larger than ML-DSA.

Performance Trade-offs

SLH-DSA signing is slower than ML-DSA. The “s” variants can take tens of milliseconds per signature. Verification is faster but still slower than ML-DSA verification.

These characteristics make SLH-DSA best suited for applications where signatures are generated infrequently but verified often — root CA certificates, firmware signing, and long-lived document signatures. For high-throughput TLS certificate signing, ML-DSA is the better choice.

Choosing the Right Standard

The three standards serve complementary roles:

Most organizations will deploy ML-KEM and ML-DSA as their primary PQC algorithms. SLH-DSA serves as a backup for critical trust anchors.

Preparing Your Infrastructure

Adopting NIST PQC standards requires changes across your certificate and key management infrastructure.

Audit your certificate inventory. Identify every certificate, its algorithm, its expiration date, and the systems that depend on it. QCecuring’s CLM platform automates this discovery across cloud, on-premises, and hybrid environments.

Test PQC algorithms in staging environments. Deploy ML-KEM and ML-DSA in non-production TLS configurations. Measure handshake latency, certificate chain sizes, and client compatibility.

Update HSMs and crypto libraries. Verify that your hardware security modules and software libraries support FIPS 203, 204, and 205. Major vendors began shipping PQC-capable firmware in 2024.

Plan hybrid deployments. During the transition period, many organizations will run hybrid configurations — combining a classical algorithm (ECDSA) with a post-quantum algorithm (ML-DSA) in the same certificate. This ensures backward compatibility while adding quantum resistance.

Secure your software supply chain. Code signing with post-quantum algorithms protects software integrity against future quantum attacks. Transition signing keys to ML-DSA or SLH-DSA as your signing infrastructure supports them.

The transition to PQC standards is a multi-year effort. Starting with a complete cryptographic inventory gives you the visibility to plan, prioritize, and execute the migration systematically.