NIST PQC Standards Explained: FIPS 203, FIPS 204, and FIPS 205 Deep Dive

The Finalization of Post-Quantum Cryptography Standards

In August 2024, NIST officially released the first three finalized post-quantum cryptography (PQC) standards, marking the culmination of an eight-year standardization effort that began in 2016. These standards — FIPS 203, FIPS 204, and FIPS 205 — represent the algorithms that will protect global digital infrastructure against quantum computing attacks for decades to come.

This is not a future event. The standards are final. Implementation is underway. Organizations that have not begun their transition planning are already behind the timelines mandated by CNSA 2.0, PCI DSS 4.0, and multiple regulatory frameworks.

This guide provides a comprehensive technical deep dive into each standard: what it does, how it works, when to use it, and how it maps to the classical algorithms it replaces.

Overview: The Three NIST PQC Standards

Standard	Algorithm	Type	Replaces	Primary Use Case
FIPS 203	ML-KEM (Module-Lattice Key Encapsulation Mechanism)	Key Encapsulation	RSA key exchange, ECDH	TLS key exchange, key wrapping, encrypted transport
FIPS 204	ML-DSA (Module-Lattice Digital Signature Algorithm)	Digital Signature	RSA signatures, ECDSA	Code signing, certificates, document signing
FIPS 205	SLH-DSA (Stateless Hash-Based Digital Signature Algorithm)	Digital Signature	RSA signatures, ECDSA	Conservative alternative for signatures

All three standards are built on mathematical problems believed to be resistant to both classical and quantum computers. ML-KEM and ML-DSA are based on structured lattice problems (Module Learning With Errors), while SLH-DSA relies exclusively on hash function security.

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

What ML-KEM Does

ML-KEM is a Key Encapsulation Mechanism (KEM) — it enables two parties to establish a shared secret key over an insecure channel without that key being recoverable by a quantum-equipped adversary. It directly replaces RSA key exchange and ECDH key agreement in protocols like TLS, SSH, and IPsec.

How ML-KEM Works

ML-KEM is based on the Module Learning With Errors (MLWE) problem. At a high level:

1. Key Generation: Generate a public/private key pair based on polynomial matrices over a ring
2. Encapsulation: The sender uses the recipient’s public key to encapsulate a shared secret, producing a ciphertext
3. Decapsulation: The recipient uses their private key to recover the shared secret from the ciphertext

The security relies on the computational difficulty of distinguishing structured lattice samples from random ones — a problem for which no efficient quantum algorithm is known.

ML-KEM Parameter Sets

FIPS 203 defines three parameter sets corresponding to different security levels:

Parameter Set	NIST Security Level	Classical Equivalent	Public Key Size	Ciphertext Size	Shared Secret Size
ML-KEM-512	Level 1	AES-128	800 bytes	768 bytes	32 bytes
ML-KEM-768	Level 3	AES-192	1,184 bytes	1,088 bytes	32 bytes
ML-KEM-1024	Level 5	AES-256	1,568 bytes	1,568 bytes	32 bytes

Performance Benchmarks

ML-KEM is remarkably fast — significantly faster than RSA and competitive with ECDH:

Operation	ML-KEM-512	ML-KEM-768	ML-KEM-1024	ECDH P-256	RSA-2048
Key Generation	~20 μs	~30 μs	~45 μs	~50 μs	~50 ms
Encapsulation	~25 μs	~40 μs	~55 μs	~100 μs	~80 μs
Decapsulation	~25 μs	~40 μs	~55 μs	~100 μs	~2 ms

The trade-off is bandwidth: ML-KEM public keys and ciphertexts are larger than ECDH values (32 bytes for X25519). However, the computation is fast enough that ML-KEM introduces negligible latency even at scale.

ML-KEM Security Considerations

• ML-KEM-768 is the recommended default for most applications, providing Level 3 security (equivalent to AES-192)
• ML-KEM-1024 is appropriate for classified/defense applications requiring Level 5 security
• ML-KEM-512 provides adequate security for most use cases but offers less margin against future cryptanalytic advances
• CNSA 2.0 requires ML-KEM-1024 for national security systems

ML-KEM Use Cases

• TLS 1.3 key exchange: Hybrid X25519+ML-KEM-768 (already deployed in Chrome, Firefox, Cloudflare)
• VPN/IPsec IKEv2: Post-quantum key agreement for site-to-site and remote access VPNs
• SSH key exchange: Post-quantum session establishment
• Key wrapping: Encapsulating symmetric keys for transport or storage
• S/MIME and email encryption: Protecting email content with quantum-safe key exchange

Mapping: ECDH → ML-KEM

Classical Operation	ML-KEM Equivalent	Notes
X25519 key agreement	ML-KEM-768 encapsulation	Hybrid recommended during transition
ECDH P-384	ML-KEM-1024	For higher security requirements
RSA key transport	ML-KEM-768/1024	KEM replaces key transport entirely
DH-2048 key agreement	ML-KEM-768	Significant performance improvement

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

What ML-DSA Does

ML-DSA is a digital signature algorithm — it allows a signer to produce a signature over a message using their private key, and any verifier can confirm the signature’s validity using the signer’s public key. It replaces RSA signatures and ECDSA in certificates, code signing, document authentication, and protocol authentication.

How ML-DSA Works

ML-DSA is also based on the Module Learning With Errors problem, but applied to digital signatures using a Fiat-Shamir with Aborts technique:

1. Key Generation: Generate a signing key and verification key from structured lattice matrices
2. Signing: Generate a signature by computing a commitment, challenge, and response — with rejection sampling to prevent information leakage
3. Verification: Verify the signature by checking the algebraic relationship between commitment, challenge, and response using the public verification key

ML-DSA Parameter Sets

Parameter Set	NIST Security Level	Classical Equivalent	Public Key Size	Signature Size	Signing Key Size
ML-DSA-44	Level 2	SHA-256 collision	1,312 bytes	2,420 bytes	2,560 bytes
ML-DSA-65	Level 3	AES-192	1,952 bytes	3,309 bytes	4,032 bytes
ML-DSA-87	Level 5	AES-256	2,592 bytes	4,627 bytes	4,896 bytes

Performance Benchmarks

ML-DSA signature operations are fast, though verification is the standout performance characteristic:

Operation	ML-DSA-44	ML-DSA-65	ML-DSA-87	ECDSA P-256	RSA-2048
Key Generation	~60 μs	~100 μs	~160 μs	~50 μs	~50 ms
Signing	~150 μs	~250 μs	~400 μs	~80 μs	~2 ms
Verification	~50 μs	~80 μs	~120 μs	~150 μs	~80 μs

ML-DSA verification is faster than ECDSA verification, which matters significantly for applications that verify many more signatures than they create (certificate chain validation, blockchain verification, package managers).

ML-DSA Security Considerations

• ML-DSA-65 is the recommended default for general-purpose digital signatures
• ML-DSA-87 is required by CNSA 2.0 for national security systems
• ML-DSA-44 is appropriate where Level 2 security is sufficient and signature size must be minimized
• The primary challenge with ML-DSA is signature and key size — significantly larger than ECDSA

ML-DSA Use Cases

• X.509 certificates: CA certificates, TLS server certificates, client certificates
• Code signing: Software distribution, firmware updates, package managers
• Document signing: PDF signatures, legal documents, contracts
• Protocol authentication: TLS handshake authentication, SSH host keys
• Timestamping: Cryptographic timestamp authorities
• Blockchain and distributed systems: Transaction signing

Mapping: RSA/ECDSA → ML-DSA

Classical Operation	ML-DSA Equivalent	Notes
RSA-2048 signature	ML-DSA-44	Smaller key, larger signature
RSA-3072 signature	ML-DSA-65	Recommended general replacement
ECDSA P-256	ML-DSA-44 or ML-DSA-65	Significant size increase
ECDSA P-384	ML-DSA-87	For high-security applications
Ed25519	ML-DSA-44	Ed25519 is 64-byte sig → 2,420 bytes

Certificate Size Impact

The most significant operational impact of ML-DSA is on certificate chains:

Classical TLS certificate chain (RSA-2048):
  Root CA cert:       ~1,500 bytes
  Intermediate cert:  ~1,500 bytes  
  Server cert:        ~1,500 bytes
  Total chain:        ~4,500 bytes

ML-DSA-65 TLS certificate chain:
  Root CA cert:       ~5,000 bytes
  Intermediate cert:  ~5,000 bytes
  Server cert:        ~5,000 bytes
  Total chain:        ~15,000 bytes

Increase: ~3.3x larger certificate chains

This impacts TLS handshake size and may require MTU considerations, particularly for constrained networks and IoT devices.

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

What SLH-DSA Does

SLH-DSA is a digital signature algorithm based entirely on hash functions — no lattice mathematics involved. It provides a conservative alternative to ML-DSA for organizations that want digital signatures based on the most well-understood security assumptions (hash function security only).

How SLH-DSA Works

SLH-DSA (formerly SPHINCS+) uses a hypertree construction — a tree of trees — where:

1. Each signature is produced using a one-time signature scheme (WOTS+) at the leaves
2. A Merkle tree authenticates WOTS+ public keys
3. Multiple layers of Merkle trees are stacked (hypertree) to keep tree heights manageable
4. A FORS (Forest of Random Subsets) few-time signature scheme handles the top-level signing

The security rests entirely on the preimage resistance, second-preimage resistance, and collision resistance of the underlying hash function.

SLH-DSA Parameter Sets

SLH-DSA offers multiple parameter sets balancing signature size against signing speed:

Parameter Set	Security Level	Variant	Public Key	Signature Size	Signing Speed
SLH-DSA-128s	Level 1	Small	32 bytes	7,856 bytes	Slow
SLH-DSA-128f	Level 1	Fast	32 bytes	17,088 bytes	Fast
SLH-DSA-192s	Level 3	Small	48 bytes	16,224 bytes	Slow
SLH-DSA-192f	Level 3	Fast	48 bytes	35,664 bytes	Fast
SLH-DSA-256s	Level 5	Small	64 bytes	29,792 bytes	Slow
SLH-DSA-256f	Level 5	Fast	64 bytes	49,856 bytes	Fast

The “s” (small) variants produce smaller signatures but are slower to sign. The “f” (fast) variants sign quickly but produce significantly larger signatures.

Performance Benchmarks

Operation	SLH-DSA-128f	SLH-DSA-128s	ML-DSA-44	ECDSA P-256
Key Generation	~1 ms	~1 ms	~60 μs	~50 μs
Signing	~5 ms	~75 ms	~150 μs	~80 μs
Verification	~1 ms	~3 ms	~50 μs	~150 μs

SLH-DSA is significantly slower than ML-DSA and produces much larger signatures. However, its security assumptions are extremely conservative.

SLH-DSA Security Considerations

• Security based only on hash functions — the most conservative possible assumption
• Appropriate when lattice-based cryptography is considered too new or when maximum long-term confidence is required
• Not recommended for high-volume applications due to performance and signature size
• CNSA 2.0 accepts SLH-DSA as an alternative to ML-DSA for firmware/software signing

SLH-DSA Use Cases

• Root CA certificates: Long-lived certificates where conservation is paramount
• Firmware signing: Where signature verification is infrequent but integrity is critical
• Code signing for critical infrastructure: Nuclear, aerospace, defense systems
• Long-term document archival: Signatures that must remain verifiable for 50+ years
• Backup/fallback algorithm: In case lattice-based algorithms face future cryptanalytic advances

When to Choose SLH-DSA vs. ML-DSA

Factor	Choose ML-DSA	Choose SLH-DSA
Performance matters	✓
Signature size constrained	✓
High-volume signing	✓
Maximum security conservatism		✓
Long-lived signatures (50+ years)		✓
Fallback/diversification		✓
Constrained environments	✓
Certificate chains	✓

NIST Security Levels Explained

NIST defines five security levels for post-quantum algorithms, based on the computational effort required to break them:

Level	Equivalent Security	Definition
Level 1	AES-128	At least as hard as breaking AES-128
Level 2	SHA-256 collision	At least as hard as finding SHA-256 collisions
Level 3	AES-192	At least as hard as breaking AES-192
Level 4	SHA-384 collision	At least as hard as finding SHA-384 collisions
Level 5	AES-256	At least as hard as breaking AES-256

For most commercial applications, Level 3 provides an excellent balance of security and performance. Level 5 is mandated by CNSA 2.0 for national security systems and recommended for data requiring the highest protection levels.

Implementation Status Across Libraries

Current Library Support (2026)

Library	ML-KEM	ML-DSA	SLH-DSA	FIPS Validated
OpenSSL 3.4+	✓ (via oqs-provider)	✓ (via oqs-provider)	✓ (via oqs-provider)	Pending
BoringSSL	✓ (ML-KEM-768)	✓	Partial	Google internal
AWS-LC	✓	✓	✓	FIPS 140-3 pending
liboqs (OQS)	✓ (all parameter sets)	✓ (all)	✓ (all)	Reference only
Bouncy Castle	✓	✓	✓	Partial
Windows CNG	✓ (preview)	✓ (preview)	Planned	Pending
NSS (Firefox)	✓ (ML-KEM-768)	Planned	Planned	Pending
wolfSSL	✓	✓	✓	FIPS 140-3 pending
mbedTLS	✓	✓	Partial	Pending

FIPS 140-3 Validation Timeline

FIPS validation for PQC algorithms is critical for regulated industries:

• NIST CMVP is actively processing PQC algorithm validation requests
• First validated modules expected in late 2025 / early 2026
• Full ecosystem validation (HSMs, cloud KMS, etc.) expected through 2026-2027
• Organizations should plan for a 12-18 month window after standard publication for validated implementations

Protocol Integration

Protocol	ML-KEM Status	ML-DSA Status	Notes
TLS 1.3	Hybrid deployed (Chrome, Firefox, Cloudflare)	Draft RFC	Key exchange is ahead of authentication
SSH	Draft RFC, some implementations	Draft RFC	OpenSSH considering integration
IPsec/IKEv2	RFC 9370 (framework)	Limited	VPN vendors actively implementing
S/MIME	Draft standards	Draft standards	Email encryption transition
X.509	N/A	Hybrid certificates proposed	Certificate migration is complex
DNSSEC	N/A	Research phase	Signature size is a challenge

Practical Implementation Guidance

Priority Order for Deployment

Based on HNDL risk, algorithm maturity, and implementation readiness:

Phase 1 (Now — 2026): Deploy ML-KEM-768 in hybrid mode for TLS key exchange

• Protects against Harvest Now, Decrypt Later immediately
• Hybrid mode provides safety net if ML-KEM has undiscovered issues
• Implementations are available and tested in major browsers and servers

Phase 2 (2026-2027): Begin ML-DSA certificate deployment for internal systems

• Start with internal PKI where you control both ends
• Test certificate chain sizes and protocol behavior
• Implement hybrid certificates where supported

Phase 3 (2027-2028): Migrate public-facing certificates to ML-DSA

• Requires broad client support for ML-DSA verification
• CDN and WAF providers must support larger certificates
• Consider SLH-DSA for root CAs as diversification

Phase 4 (2028-2030): Complete migration, remove classical algorithms

• Transition from hybrid to pure PQC where appropriate
• Maintain classical fallback only for legacy interoperability
• CNSA 2.0 mandates pure PQC for national security by 2033-2035

Code Example: ML-KEM Key Exchange (OpenSSL 3.x with OQS Provider)

// ML-KEM-768 key encapsulation using OpenSSL 3.x
#include <openssl/evp.h>
#include <openssl/core_names.h>

// Generate ML-KEM-768 key pair
EVP_PKEY_CTX *ctx = EVP_PKEY_CTX_new_from_name(NULL, "mlkem768", NULL);
EVP_PKEY_keygen_init(ctx);
EVP_PKEY *key = NULL;
EVP_PKEY_keygen(ctx, &key);

// Encapsulation (sender side)
EVP_PKEY_CTX *enc_ctx = EVP_PKEY_CTX_new(peer_public_key, NULL);
EVP_PKEY_encapsulate_init(enc_ctx, NULL);

size_t ct_len, ss_len;
EVP_PKEY_encapsulate(enc_ctx, NULL, &ct_len, NULL, &ss_len);

unsigned char *ciphertext = OPENSSL_malloc(ct_len);
unsigned char *shared_secret = OPENSSL_malloc(ss_len);
EVP_PKEY_encapsulate(enc_ctx, ciphertext, &ct_len, shared_secret, &ss_len);

// Decapsulation (recipient side)
EVP_PKEY_CTX *dec_ctx = EVP_PKEY_CTX_new(my_private_key, NULL);
EVP_PKEY_decapsulate_init(dec_ctx, NULL);
EVP_PKEY_decapsulate(dec_ctx, shared_secret, &ss_len, ciphertext, ct_len);

Code Example: ML-DSA Signature (Python with oqs-python)

import oqs

# ML-DSA-65 signature generation and verification
signer = oqs.Signature("Dilithium3")  # ML-DSA-65

# Generate signing key pair
public_key = signer.generate_keypair()

# Sign a message
message = b"Critical firmware update v2.4.1"
signature = signer.sign(message)

# Verify signature (can be done by any party with public key)
verifier = oqs.Signature("Dilithium3")
is_valid = verifier.verify(message, signature, public_key)
assert is_valid, "Signature verification failed"

How QCecuring CBOM Supports Standards Adoption

Implementing FIPS 203, 204, and 205 requires knowing where classical algorithms currently exist in your infrastructure. QCecuring CBOM provides:

• Complete cryptographic inventory: Every algorithm, key size, and protocol usage across your environment
• Algorithm-to-standard mapping: Automatically identifies which FIPS standard replaces each classical algorithm in use
• Migration progress tracking: Dashboard showing percentage of infrastructure migrated from RSA/ECDH/ECDSA to ML-KEM/ML-DSA/SLH-DSA
• Library version monitoring: Tracks which versions of cryptographic libraries are deployed and whether they support the finalized standards
• Compliance gap analysis: Maps current cryptographic posture against CNSA 2.0, PCI DSS 4.0, and other regulatory requirements

Without a CBOM, organizations cannot systematically identify where classical algorithms remain or verify that migration is complete.

Key Takeaways

• Three standards are final and published: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) — no more waiting for standardization
• ML-KEM replaces RSA/ECDH key exchange with faster performance and larger key/ciphertext sizes (1-1.5 KB)
• ML-DSA replaces RSA/ECDSA signatures with fast verification but significantly larger signatures (2.4-4.6 KB)
• SLH-DSA provides a conservative hash-based alternative for signatures where maximum long-term confidence is required
• ML-KEM-768 and ML-DSA-65 are the recommended defaults for most commercial applications
• CNSA 2.0 requires Level 5 (ML-KEM-1024, ML-DSA-87) for national security systems
• Implementation is available today in major libraries — waiting for FIPS 140-3 validation is the remaining blocker for regulated industries
• Hybrid deployment is the recommended transition strategy — deploy PQC alongside classical algorithms for safety
• Certificate chain size is the biggest operational challenge for ML-DSA adoption in TLS
• QCecuring CBOM identifies every algorithm requiring migration and tracks progress against FIPS standard adoption targets