NIST PQC Standards Explained: ML-KEM, ML-DSA, and SLH-DSA for Practitioners
In August 2024, NIST published the first three finalized post-quantum cryptography standards after an eight-year evaluation process that started in 2016. These are not drafts or proposals. They are Federal Information Processing Standards (FIPS) that federal agencies must adopt and that the broader industry will follow.
This guide covers the practical details that security engineers and PKI architects need: what each standard does, the specific parameter sets, key and signature sizes on the wire, performance characteristics, and which one to pick for which use case.
For the broader context (why PQC matters, harvest now decrypt later, who has already shipped), see our What Is Post-Quantum Cryptography? article.
The three standards
| Standard | Algorithm | Replaces | Purpose |
|---|---|---|---|
| FIPS 203 | ML-KEM | RSA, ECDH, DH | Key encapsulation (agreeing on a shared secret) |
| FIPS 204 | ML-DSA | RSA, ECDSA, Ed25519 | Digital signatures (general purpose) |
| FIPS 205 | SLH-DSA | RSA, ECDSA, Ed25519 | Digital signatures (conservative, hash-based) |
Coming next: FIPS 206 (FN-DSA, based on Falcon) is still in draft due to implementation complexity around constant-time floating-point arithmetic. HQC was selected in March 2025 as a code-based KEM to diversify away from lattice-only cryptography.
FIPS 203: ML-KEM (ex-CRYSTALS-Kyber)
Module-Lattice-Based Key-Encapsulation Mechanism. This is the algorithm that protects key exchange. When two parties need to agree on a shared secret to encrypt their communication (every TLS handshake, every VPN connection, every SSH session), ML-KEM provides quantum-resistant key establishment.
Parameter sets
| Parameter set | Security level | Public key | Ciphertext | Shared secret | NIST category |
|---|---|---|---|---|---|
| ML-KEM-512 | ~AES-128 | 800 B | 768 B | 32 B | 1 |
| ML-KEM-768 | ~AES-192 | 1,184 B | 1,088 B | 32 B | 3 |
| ML-KEM-1024 | ~AES-256 | 1,568 B | 1,568 B | 32 B | 5 |
Recommended default: ML-KEM-768 (this is what Chrome, Cloudflare, and the TLS IETF drafts use in hybrid mode as X25519MLKEM768).
Performance
ML-KEM is fast. On ARM Cortex-M0+ (embedded hardware), ML-KEM-512 completes a full key exchange in 35.7 ms, which is 17x faster than ECDH P-256 on the same chip. On modern x86 CPUs, all operations are sub-millisecond.
The main cost is bandwidth, not computation. ML-KEM-768 adds approximately 1.1 KB to a TLS ClientHello compared to X25519 alone. For most connections this is negligible. For constrained IoT links or protocols with tight header budgets, it matters.
Current deployment
ML-KEM-768 is deployed in production today via the hybrid X25519MLKEM768 TLS named group:
- Google Chrome and Microsoft Edge enable it by default
- Cloudflare accepts it server-side for all domains
- AWS supports it in KMS (hybrid mode)
This is the most widely deployed PQC algorithm in 2026 by traffic volume.
FIPS 204: ML-DSA (ex-CRYSTALS-Dilithium)
Module-Lattice-Based Digital Signature Algorithm. The default replacement for RSA and ECDSA signatures everywhere: TLS certificates, code signing, S/MIME, JWTs, document signatures.
Parameter sets
| Parameter set | Security level | Public key | Signature | NIST category |
|---|---|---|---|---|
| ML-DSA-44 | ~AES-128 | 1,312 B | 2,420 B | 2 |
| ML-DSA-65 | ~AES-192 | 1,952 B | 3,293 B | 3 |
| ML-DSA-87 | ~AES-256 | 2,592 B | 4,627 B | 5 |
Recommended default: ML-DSA-65 for most certificate and signing use cases.
The size problem
ML-DSA-65 signatures are 3,293 bytes. For context:
- ECDSA P-256 signature: 64 bytes (51x smaller)
- RSA-3072 signature: 384 bytes (8.6x smaller)
A single TLS certificate signed with ML-DSA-65 is roughly 5 KB larger than today. A three-certificate chain adds 15+ KB to every TLS handshake. This does not break anything, but capacity planning for edge infrastructure (CDNs, load balancers, CT logs) must account for it.
Performance
Verification is fast (competitive with RSA-3072 verification). Signing is slower than ECDSA but still within practical budgets for all workloads except the most extreme high-frequency signing scenarios.
Current deployment
ML-DSA certificates are experimental in 2026. Cloudflare, Microsoft, and Google have issued ML-DSA certificates from internal CAs for testing. The IETF LAMPS working group is profiling ML-DSA for X.509 certificates (draft-ietf-lamps-dilithium-certificates). Production rollout in the public WebPKI is expected 2027-2028 as browser trust stores add PQ-capable root CAs.
FIPS 205: SLH-DSA (ex-SPHINCS+)
Stateless Hash-Based Digital Signature Algorithm. A deliberately conservative alternative to ML-DSA whose security depends only on hash functions (SHA-2 or SHAKE), not lattice assumptions.
Why it exists alongside ML-DSA
ML-DSA is based on the Module-LWE lattice problem. This problem has been studied extensively and is believed hard, but it is relatively young compared to hash function security (which has decades of cryptanalytic attention). SLH-DSA exists as insurance: if a mathematical breakthrough ever makes lattice problems tractable, SLH-DSA signatures remain safe because they rely only on hash collision resistance.
Parameter sets (selected)
| Parameter set | Profile | Public key | Signature | Signing speed |
|---|---|---|---|---|
| SLH-DSA-SHA2-128s | Small | 32 B | ~7,856 B | Slow |
| SLH-DSA-SHA2-128f | Fast | 32 B | ~17,088 B | Faster |
| SLH-DSA-SHA2-192s | Small | 48 B | ~16,224 B | Slow |
| SLH-DSA-SHA2-256s | Small | 64 B | ~29,792 B | Very slow |
| SLH-DSA-SHA2-256f | Fast | 64 B | ~49,856 B | Faster |
There are twelve total parameter sets across SHA-2 and SHAKE hash families, each with “s” (small signature, slow signing) and “f” (fast signing, large signature) profiles.
The tradeoff: SLH-DSA-128s signature (7,856 B) is 2.4x larger than ML-DSA-65 (3,293 B), and signing is dramatically slower (tens to hundreds of milliseconds on commodity CPUs). But verification is fast, and the security assumption is extremely conservative.
When to use SLH-DSA
- Root CA self-signatures (signed once, verified millions of times)
- Firmware and secure boot signing keys (20+ year validity)
- Archival notarization (must verify decades later)
- Any context where policy requires non-lattice cryptography
Do not use SLH-DSA for high-volume signing (TLS session tickets, JWTs, per-request signatures). Use ML-DSA for those.
Size comparison: everything on one table
| Algorithm | Public key | Signature/ciphertext | Use case |
|---|---|---|---|
| RSA-3072 | 384 B | 384 B | Legacy (being replaced) |
| ECDSA P-256 | 64 B | 64 B | Legacy (being replaced) |
| X25519 | 32 B | 32 B (shared secret) | Legacy key exchange |
| ML-KEM-768 | 1,184 B | 1,088 B | PQC key exchange |
| ML-DSA-65 | 1,952 B | 3,293 B | PQC signatures (default) |
| SLH-DSA-128s | 32 B | ~7,856 B | PQC signatures (conservative) |
The jump from ECDSA’s 64 B to ML-DSA’s 3,293 B is the single biggest infrastructure impact of the PQC migration. Every system that transmits or stores signatures needs to account for ~50x larger payloads.
OpenSSL 3.5: generating PQ keys
OpenSSL 3.5 (April 2025) is the first upstream release with ML-KEM, ML-DSA, and SLH-DSA in the default provider.
# Verify PQC algorithm support
openssl list -signature-algorithms | grep -Ei 'ML-DSA|SLH-DSA'
openssl list -kem-algorithms | grep -i ML-KEM
# Generate an ML-DSA-65 key pair
openssl genpkey -algorithm ML-DSA-65 -out mldsa65.key
# Inspect the public key (note the larger size)
openssl pkey -in mldsa65.key -pubout -text -noout
# Sign a file
echo "test payload" > msg.bin
openssl pkeyutl -sign -inkey mldsa65.key -rawin -in msg.bin -out msg.sig
# Verify the signature
openssl pkeyutl -verify -inkey mldsa65.key -rawin -in msg.bin -sigfile msg.sig
# Output: Signature Verified Successfully
# Compare signature sizes
openssl genpkey -algorithm SLH-DSA-SHA2-128s -out slhdsa.key
openssl pkeyutl -sign -inkey slhdsa.key -rawin -in msg.bin -out msg.slh.sig
ls -l msg.sig msg.slh.sig
# msg.sig (ML-DSA-65): ~3.3 KB
# msg.slh.sig (SLH-DSA-128s): ~7.9 KBNote: On older OpenSSL (pre-3.5), use the OQS provider loaded against OpenSSL 3.x. The algorithm strings are the same but configuration differs.
Decision framework
| Question | Answer |
|---|---|
| I need quantum-safe key exchange now | ML-KEM-768 in hybrid mode (X25519MLKEM768) |
| I need quantum-safe signatures for certificates | ML-DSA-65 (when your CA supports it) |
| I need signatures that survive even if lattices break | SLH-DSA-128s |
| I am signing firmware with 20-year validity | SLH-DSA-128s (or SLH-DSA-192s for extra margin) |
| I need the smallest possible PQ signature | ML-DSA-44 (2,420 B) or wait for FN-DSA (~666 B) |
| I need hybrid (classical + PQ together) | X25519MLKEM768 for key exchange, composite certificates for signatures |
| I am not sure and want the safest default | ML-KEM-768 + ML-DSA-65 in hybrid mode |
FAQ
What is the difference between ML-KEM and ML-DSA?
ML-KEM does key exchange (two parties agree on a shared secret). ML-DSA does digital signatures (proving a message is authentic and unmodified). Different purposes, both based on lattice problems, both needed for a complete PQC migration.
Why are there three security levels per algorithm?
NIST defines security categories 1, 3, and 5 (roughly equivalent to AES-128, AES-192, AES-256 against a quantum attacker). Higher categories mean larger keys and signatures but more security margin. Category 3 (ML-KEM-768, ML-DSA-65) is the recommended default for most deployments.
Is SLH-DSA better than ML-DSA?
Not “better,” more conservative. SLH-DSA’s security relies only on hash functions, which have a longer track record than lattice assumptions. The cost: larger signatures and slower signing. For most use cases ML-DSA is the right choice. SLH-DSA is for high-assurance, long-lived signatures where conservatism matters more than size.
Can my existing HSM handle these algorithms?
Depends on the HSM. Most 2024-era HSMs do not support ML-DSA or ML-KEM natively yet. Software-based signing (OpenSSL, BoringSSL) works now. HSM support is expected to become standard during 2026-2027 as vendors release firmware updates. SLH-DSA is hash-only, so HSMs with SHA-2/SHA-3 accelerators can support it with firmware updates.
What is X25519MLKEM768?
A hybrid TLS 1.3 key exchange that combines classical X25519 (still secure today) with ML-KEM-768 (quantum-resistant). Both must be broken to compromise the session. This is the standard PQC deployment model for TLS and is already live in Chrome, Edge, and Cloudflare.