Algorithms
NIST-standardized post-quantum algorithm specifications. All three algorithm families were finalized in August 2024. Key sizes and performance figures are provided as practical guidance for protocol and system design.
Key Encapsulation Mechanisms (KEMs)
ML-KEM (FIPS 203) replaces RSA-KEM and ECDH for key establishment. Based on Module-LWE (CRYSTALS-Kyber). All three parameter sets share a 32-byte shared secret output; they differ only in security level, key size, and ciphertext size.
| Parameter set | Security level | Public key | Secret key | Ciphertext | Shared secret | Encap / Decap |
|---|---|---|---|---|---|---|
| ML-KEM-512 | 1 (~AES-128) | 800 B | 1,632 B | 768 B | 32 B | ~50K / ~50K ops/s |
| ML-KEM-768 (recommended) | 3 (~AES-192) | 1,184 B | 2,400 B | 1,088 B | 32 B | ~35K / ~35K ops/s |
| ML-KEM-1024 | 5 (~AES-256) | 1,568 B | 3,168 B | 1,568 B | 32 B | ~25K / ~25K ops/s |
Performance figures are approximate single-core AVX2 throughput. Encap and Decap are symmetric in cost for ML-KEM; variation appears at higher security levels due to larger matrix dimensions.
ML-KEM selection guidance
- ML-KEM-512 — constrained environments and bandwidth-sensitive applications where Level 1 security is acceptable.
- ML-KEM-768 — recommended default. Used in X25519MLKEM768 and SecP256r1MLKEM768 hybrid TLS groups; appropriate for most TLS, HPKE, and general-purpose encryption deployments.
- ML-KEM-1024 — required under CNSA 2.0 for National Security Systems. Choose when protecting data with 50+ year confidentiality requirements or when the threat model includes nation-state adversaries.
Digital Signature Algorithms
ML-DSA (FIPS 204)
Module-Lattice Digital Signature Algorithm. Replaces RSA, ECDSA, and EdDSA for general digital signatures. Based on Module-LWE/SIS (CRYSTALS-Dilithium). Signing is the slower direction — ML-DSA signs more slowly than it verifies, unlike classical RSA or ECDSA where verification is the bottleneck.
| Parameter set | Security level | Public key | Secret key | Signature | Sign ops/s | Verify ops/s |
|---|---|---|---|---|---|---|
| ML-DSA-44 | 2 (~AES-128 / SHA-256 collision) | 1,312 B | 2,560 B | 2,420 B | ~10K | ~30K |
| ML-DSA-65 (recommended) | 3 (~AES-192) | 1,952 B | 4,032 B | 3,309 B | ~7K | ~20K |
| ML-DSA-87 | 5 (~AES-256) | 2,592 B | 4,896 B | 4,627 B | ~6K | ~15K |
Approximate order-of-magnitude figures, AVX2, single core (pq-crystals reference benchmarks). Verify throughput is always faster than sign for ML-DSA; size the signing fleet accordingly.
ML-DSA selection guidance
- ML-DSA-44 — high-volume signing: IoT device attestation, short-lived API tokens, OCSP responses. Smallest signatures.
- ML-DSA-65 — recommended default for TLS certificates, code signing, document signing, and JWTs where Level 3 security is appropriate.
- ML-DSA-87 — CNSA 2.0 requirement for classified PKI. Used in the Quantum Nexum three-tier CA hierarchy for maximum long-term assurance.
SLH-DSA (FIPS 205)
Stateless Hash-Based Digital Signature Algorithm. Based on SPHINCS+. Security assumptions rest entirely on the collision resistance of the underlying hash function — no lattice or structured-lattice assumptions required. This makes SLH-DSA the most conservative choice when the long-term trustworthiness of the mathematical assumptions matters more than performance or signature size.
Parameter naming convention: SLH-DSA-<hash>-<n><v>
where n is the security parameter (128 = Level 1, 192 = Level 3,
256 = Level 5) and v is the variant —
f (fast: larger signatures, faster signing, faster verification)
or s (small: smaller signatures, slower signing, slower
verification).
| Parameter set | Level | Public key | Secret key | Signature | Sign ops/s | Verify ops/s |
|---|---|---|---|---|---|---|
| SLH-DSA-SHAKE-128f | 1 (fast) | 32 B | 64 B | 17,088 B | ~500 | ~5,000 |
| SLH-DSA-SHAKE-128s | 1 (small) | 32 B | 64 B | 7,856 B | ~50 | ~1,000 |
| SLH-DSA-SHA2-256f | 5 (fast) | 64 B | 128 B | 49,856 B | ~30 | ~300 |
| SLH-DSA-SHA2-256s | 5 (small) | 64 B | 128 B | 29,792 B | ~3 | ~60 |
SLH-DSA performance is orders of magnitude slower than ML-DSA. The "f" variants sign faster and verify faster than the "s" variants at the cost of larger signatures. Public and secret keys are tiny compared to ML-DSA; signatures are large. Figures are approximate single-core (no AVX2 optimization available in most current implementations).
SLH-DSA selection guidance
- 128f / 256f — offline signing of firmware images, root CA certificates, and infrastructure artifacts where throughput matters more than signature size.
- 128s / 256s — archival documents and long-lived certificates where bandwidth is constrained and signing happens infrequently.
- CNSA 2.0 does not include SLH-DSA. Use SLH-DSA when you want hash-only security assumptions independent of CNSA requirements; use ML-DSA-87 for CNSA 2.0 compliance.
Security levels
| NIST level | Classical equivalent | ML-KEM | ML-DSA | SLH-DSA n |
|---|---|---|---|---|
| 1 | AES-128 key search | 512 | — | 128 |
| 2 | SHA-256 / SHA3-256 collision | — | 44 | — |
| 3 | AES-192 key search | 768 | 65 | 192 |
| 4 | SHA-384 / SHA3-384 collision | — | — | — |
| 5 | AES-256 key search | 1024 | 87 | 256 |
Hybrid mode
Combining a classical algorithm with a PQ algorithm in a single handshake or signature provides defense-in-depth during the transition period. A hybrid KEM is secure if either component is secure; an attacker who breaks the lattice assumption still cannot recover the session key without also breaking the classical component, and vice versa.
Widely deployed examples:
- X25519MLKEM768 — X25519 + ML-KEM-768, standardized hybrid TLS group, deployed in Chrome, Firefox, and Cloudflare.
- SecP256r1MLKEM768 — P-256 + ML-KEM-768, FIPS-compatible hybrid TLS group.
See hybrid for a full treatment of hybrid key exchange and signature construction.