PQC Algorithm Reference
This page is a quick-reference card for all NIST-standardized post-quantum cryptography parameter sets. Bookmark it. Use it when sizing buffers, choosing security levels, or comparing algorithms during architecture reviews. All values are from the final FIPS 203, FIPS 204, and FIPS 205 standards published by NIST in August 2024.
Last verified: August 5, 2026.
ML-KEM (FIPS 203) - Key Encapsulation Mechanism
ML-KEM (formerly Kyber) is the primary NIST-recommended key encapsulation mechanism for post-quantum key establishment. It is based on the Module Learning With Errors (M-LWE) problem.
Parameter sets
| Parameter | NIST Level | Public Key | Secret Key | Ciphertext | Shared Secret |
|---|---|---|---|---|---|
| ML-KEM-512 | 1 | 800 bytes | 1,632 bytes | 768 bytes | 32 bytes |
| ML-KEM-768 | 3 | 1,184 bytes | 2,400 bytes | 1,088 bytes | 32 bytes |
| ML-KEM-1024 | 5 | 1,568 bytes | 3,168 bytes | 1,568 bytes | 32 bytes |
Speed class
| Parameter | Keygen | Encapsulate | Decapsulate | Overall |
|---|---|---|---|---|
| ML-KEM-512 | Very fast | Very fast | Very fast | Very fast |
| ML-KEM-768 | Very fast | Very fast | Very fast | Very fast |
| ML-KEM-1024 | Fast | Fast | Fast | Fast |
All ML-KEM parameter sets complete operations in microseconds on modern hardware. Key generation, encapsulation, and decapsulation are all dominated by NTT (Number Theoretic Transform) operations and hash computations. There is no significant performance reason to avoid ML-KEM-768 or even ML-KEM-1024.
Size comparison with classical key exchange
| Algorithm | Client contribution | Server contribution | Total overhead |
|---|---|---|---|
| X25519 (classical) | 32 bytes | 32 bytes | 64 bytes |
| ML-KEM-768 (standalone) | 1,184 bytes | 1,088 bytes | 2,272 bytes |
| X25519MLKEM768 (hybrid) | 32 + 1,184 = 1,216 bytes | 32 + 1,088 = 1,120 bytes | 2,336 bytes |
When to use which level
- ML-KEM-512 (Level 1): Equivalent to AES-128 security against quantum attack. Use when bandwidth is extremely constrained and NIST Level 1 is acceptable for your threat model.
- ML-KEM-768 (Level 3): Equivalent to AES-192 security. The default recommendation for general-purpose use. Used in Chrome, Firefox, and Cloudflare hybrid key exchange (X25519MLKEM768).
- ML-KEM-1024 (Level 5): Equivalent to AES-256 security. Use when compliance requires the highest security level or when protecting data with very long secrecy requirements.
IANA code points for TLS
| Named Group | Code Point | Usage |
|---|---|---|
| mlkem512 | 0x0512 | Standalone ML-KEM-512 |
| mlkem768 | 0x0768 | Standalone ML-KEM-768 |
| mlkem1024 | 0x1024 | Standalone ML-KEM-1024 |
| X25519MLKEM768 | 0x4588 | Hybrid (RFC 9936) |
| SecP256r1MLKEM768 | 0x4589 | Hybrid with P-256 |
ML-DSA (FIPS 204) - Digital Signature Algorithm
ML-DSA (formerly Dilithium) is the primary NIST-recommended post-quantum digital signature algorithm. It is based on Module-LWE and Module-SIS problems.
Cloudflare’s 1.1.1.1 resolver now validates experimental DNSSEC records using ML-DSA-44. The algorithm is standardized in FIPS 204, while the ML-DSA-44 DNSSEC mapping remains an Internet-Draft rather than an RFC.
Parameter sets
| Parameter | NIST Level | Public Key | Secret Key | Signature |
|---|---|---|---|---|
| ML-DSA-44 | 2 | 1,312 bytes | 2,560 bytes | 2,420 bytes |
| ML-DSA-65 | 3 | 1,952 bytes | 4,032 bytes | 3,309 bytes |
| ML-DSA-87 | 5 | 2,592 bytes | 4,896 bytes | 4,627 bytes |
Speed class
| Parameter | Keygen | Sign | Verify | Overall |
|---|---|---|---|---|
| ML-DSA-44 | Fast | Medium | Fast | Fast |
| ML-DSA-65 | Fast | Medium | Fast | Fast |
| ML-DSA-87 | Fast | Medium | Fast | Fast |
Signing in ML-DSA uses rejection sampling (the “Fiat-Shamir with Aborts” paradigm), which means signing time has variance. Most signing operations complete within a few hundred microseconds, but occasional attempts require multiple retries. Verification is consistently fast because it does not involve rejection sampling.
Size comparison with classical signatures
| Algorithm | Public Key | Signature | Combined (cert context) |
|---|---|---|---|
| ECDSA P-256 | 64 bytes | 64 bytes | 128 bytes |
| RSA-2048 | 256 bytes | 256 bytes | 512 bytes |
| Ed25519 | 32 bytes | 64 bytes | 96 bytes |
| ML-DSA-44 | 1,312 bytes | 2,420 bytes | 3,732 bytes |
| ML-DSA-65 | 1,952 bytes | 3,309 bytes | 5,261 bytes |
| ML-DSA-87 | 2,592 bytes | 4,627 bytes | 7,219 bytes |
When to use which level
- ML-DSA-44 (Level 2): Approximately equivalent to AES-128/SHA-256 classical security. Suitable for general-purpose document signing, code signing, and short-lived TLS certificates. Smallest PQ signatures in the ML-DSA family.
- ML-DSA-65 (Level 3): Approximately equivalent to AES-192 security. The recommended default for most use cases, including TLS certificate chains and long-lived signing keys.
- ML-DSA-87 (Level 5): Approximately equivalent to AES-256 security. Use for root CA certificates, high-value code signing, and environments requiring the strongest available security margin.
TLS 1.3 status, September 2026: the IESG has approved draft-ietf-tls-mldsa-05, Use of ML-DSA in TLS 1.3, for publication as an Informational RFC. The draft maps ML-DSA-44, ML-DSA-65, and ML-DSA-87 to TLS 1.3 authentication. It is IESG-approved, but the final RFC number is still pending. This is separate from RFC 10024 hybrid ML-KEM key establishment and does not by itself make ML-DSA certificates available in the public Web PKI.
OID assignments (RFC 9881)
| Parameter | OID |
|---|---|
| ML-DSA-44 | 2.16.840.1.101.3.4.3.17 |
| ML-DSA-65 | 2.16.840.1.101.3.4.3.18 |
| ML-DSA-87 | 2.16.840.1.101.3.4.3.19 |
SLH-DSA (FIPS 205) - Stateless Hash-Based Signatures
SLH-DSA (formerly SPHINCS+) is a stateless hash-based signature scheme. Its security relies solely on hash function properties, making it the most conservative PQC signature choice. It is intended as a fallback if lattice-based assumptions (used in ML-DSA) are ever broken.
Parameter sets (SHA-2 variants)
| Parameter | NIST Level | Public Key | Secret Key | Signature | Speed variant |
|---|---|---|---|---|---|
| SLH-DSA-SHA2-128s | 1 | 32 bytes | 64 bytes | 7,856 bytes | Small |
| SLH-DSA-SHA2-128f | 1 | 32 bytes | 64 bytes | 17,088 bytes | Fast |
| SLH-DSA-SHA2-192s | 3 | 48 bytes | 96 bytes | 16,224 bytes | Small |
| SLH-DSA-SHA2-192f | 3 | 48 bytes | 96 bytes | 35,664 bytes | Fast |
| SLH-DSA-SHA2-256s | 5 | 64 bytes | 128 bytes | 29,792 bytes | Small |
| SLH-DSA-SHA2-256f | 5 | 64 bytes | 128 bytes | 49,856 bytes | Fast |
Parameter sets (SHAKE variants)
| Parameter | NIST Level | Public Key | Secret Key | Signature | Speed variant |
|---|---|---|---|---|---|
| SLH-DSA-SHAKE-128s | 1 | 32 bytes | 64 bytes | 7,856 bytes | Small |
| SLH-DSA-SHAKE-128f | 1 | 32 bytes | 64 bytes | 17,088 bytes | Fast |
| SLH-DSA-SHAKE-192s | 3 | 48 bytes | 96 bytes | 16,224 bytes | Small |
| SLH-DSA-SHAKE-192f | 3 | 48 bytes | 96 bytes | 35,664 bytes | Fast |
| SLH-DSA-SHAKE-256s | 5 | 64 bytes | 128 bytes | 29,792 bytes | Small |
| SLH-DSA-SHAKE-256f | 5 | 64 bytes | 128 bytes | 49,856 bytes | Fast |
Speed class
| Variant type | Keygen | Sign | Verify | Overall |
|---|---|---|---|---|
| Small (“s”) | Fast | Slow | Medium | Slow |
| Fast (“f”) | Fast | Medium | Medium | Medium |
SLH-DSA signing is significantly slower than ML-DSA. The “s” (small) variants can take hundreds of milliseconds for a single signing operation on commodity hardware. The “f” (fast) variants are faster but produce signatures roughly 2x larger.
Small versus fast: the tradeoff
| Aspect | Small (“s”) | Fast (“f”) |
|---|---|---|
| Signature size | Smaller (7.8 KB to 29.8 KB) | Larger (17 KB to 49.9 KB) |
| Signing speed | Slow (100s of ms) | Medium (10s of ms) |
| Verification speed | Medium | Medium |
| Use case | Bandwidth-constrained, infrequent signing | Latency-sensitive, frequent signing |
SHA-2 versus SHAKE: which hash function
Both SHA-2 and SHAKE variants provide identical security levels and produce identical signature sizes. The choice depends on:
- SHA-2: Better hardware acceleration support on most current platforms. Preferred when SHA-2 hardware instructions are available.
- SHAKE: Based on Keccak (SHA-3 family). Preferred in environments with SHAKE/SHA-3 hardware acceleration or where SHA-2 avoidance is a compliance requirement.
For most deployments, SHA-2 variants are the default choice due to wider hardware acceleration support.
When to use SLH-DSA
SLH-DSA is not meant to replace ML-DSA for general use. Consider SLH-DSA when:
- You need a fallback algorithm independent of lattice assumptions
- Your threat model requires defense-in-depth against potential future breaks in lattice cryptography
- You are signing infrequently (firmware images, root CA certificates) where signing speed is not critical
- You need the smallest possible public keys (32 to 64 bytes) and signature size is acceptable
Size context
To put SLH-DSA signature sizes in perspective:
| What | Size |
|---|---|
| A typical HTTPS response header | ~500 bytes |
| An ML-DSA-65 signature | 3,309 bytes |
| An SLH-DSA-SHA2-128s signature | 7,856 bytes |
| An SLH-DSA-SHA2-256f signature | 49,856 bytes |
| A typical small web page | ~50,000 bytes |
NIST security levels explained
The NIST security level indicates the minimum computational effort required to break the algorithm:
| Level | Classical equivalent | Quantum equivalent | Meaning |
|---|---|---|---|
| 1 | AES-128 | Grover on AES-128 | At least as hard to break as AES-128 |
| 2 | SHA-256 collision | Grover on SHA-256 | At least as hard as finding SHA-256 collisions |
| 3 | AES-192 | Grover on AES-192 | At least as hard to break as AES-192 |
| 4 | SHA-384 collision | Grover on SHA-384 | At least as hard as finding SHA-384 collisions |
| 5 | AES-256 | Grover on AES-256 | At least as hard to break as AES-256 |
For key encapsulation (ML-KEM), NIST defined Levels 1, 3, and 5. For digital signatures, ML-DSA targets Levels 2, 3, and 5. SLH-DSA targets Levels 1, 3, and 5.
Complete size comparison chart
All sizes in bytes. This is the single table you need for architecture planning:
| Algorithm | Type | PK | SK | Sig/CT | NIST Level |
|---|---|---|---|---|---|
| ML-KEM-512 | KEM | 800 | 1,632 | 768 | 1 |
| ML-KEM-768 | KEM | 1,184 | 2,400 | 1,088 | 3 |
| ML-KEM-1024 | KEM | 1,568 | 3,168 | 1,568 | 5 |
| ML-DSA-44 | Sig | 1,312 | 2,560 | 2,420 | 2 |
| ML-DSA-65 | Sig | 1,952 | 4,032 | 3,309 | 3 |
| ML-DSA-87 | Sig | 2,592 | 4,896 | 4,627 | 5 |
| SLH-DSA-SHA2-128s | Sig | 32 | 64 | 7,856 | 1 |
| SLH-DSA-SHA2-128f | Sig | 32 | 64 | 17,088 | 1 |
| SLH-DSA-SHA2-192s | Sig | 48 | 96 | 16,224 | 3 |
| SLH-DSA-SHA2-192f | Sig | 48 | 96 | 35,664 | 3 |
| SLH-DSA-SHA2-256s | Sig | 64 | 128 | 29,792 | 5 |
| SLH-DSA-SHA2-256f | Sig | 64 | 128 | 49,856 | 5 |
For SLH-DSA SHAKE variants, the sizes are identical to their SHA-2 counterparts at the same security level and speed variant.
Algorithm selection decision tree
-
Need key exchange/encapsulation? Use ML-KEM-768 (default) or ML-KEM-1024 (highest security).
-
Need digital signatures with reasonable sizes? Use ML-DSA-65 (default) or ML-DSA-87 (highest security).
-
Need signatures independent of lattice assumptions? Use SLH-DSA-SHA2-128s (smallest signatures) or SLH-DSA-SHA2-128f (fastest signing).
-
Need smallest possible public keys? SLH-DSA wins at 32 to 64 bytes, versus ML-DSA at 1,312 to 2,592 bytes.
-
Need smallest possible signatures? ML-DSA wins at 2,420 to 4,627 bytes, versus SLH-DSA at 7,856 to 49,856 bytes.
-
Bandwidth-constrained protocol (IoT, embedded)? ML-KEM-512 + ML-DSA-44 gives the smallest combined PQ footprint while still providing NIST Level 1/2 security.
What about HQC?
NIST selected HQC (Hamming Quasi-Cyclic) in 2025 as a backup KEM algorithm for standardization. It is code-based (not lattice-based) and provides algorithm diversity in case lattice problems are broken. The HQC standard is expected in 2027. HQC has significantly larger key and ciphertext sizes than ML-KEM:
| Parameter | Public Key | Ciphertext | Shared Secret |
|---|---|---|---|
| HQC-128 | ~2,249 bytes | ~4,497 bytes | 32 bytes |
| HQC-192 | ~4,522 bytes | ~9,026 bytes | 32 bytes |
| HQC-256 | ~7,245 bytes | ~14,469 bytes | 32 bytes |
These sizes are approximate (final standard may adjust parameters). HQC is not a replacement for ML-KEM in bandwidth-sensitive applications, but provides essential cryptographic diversity.
FAQ
Q: Which algorithm should I deploy first?
ML-KEM-768 for key exchange. It is already deployed in major browsers and adds meaningful protection against harvest-now-decrypt-later attacks today.
Q: Why does ML-DSA have Level 2 instead of Level 1?
ML-DSA-44 targets NIST Level 2 (SHA-256 collision resistance equivalent) rather than Level 1. This is because signature schemes face different attack models than KEMs. The lowest ML-DSA parameter set still provides substantial security margin.
Q: Are the SHAKE variants of SLH-DSA slower than SHA-2 variants?
On most current hardware, yes, marginally. SHA-2 benefits from widespread hardware acceleration (Intel SHA extensions, ARM SHA2 instructions). The difference is typically 10 to 30 percent depending on the platform.
Q: How do these sizes compare to RSA-2048?
RSA-2048 uses 256-byte keys and 256-byte signatures. ML-DSA-65 uses 1,952-byte keys and 3,309-byte signatures, roughly 8x and 13x larger respectively. ML-KEM-768 ciphertexts (1,088 bytes) are about 4x larger than an RSA-2048 ciphertext.
Q: Can I use ML-KEM for encryption directly?
ML-KEM is a Key Encapsulation Mechanism, not an encryption algorithm. It produces a shared secret (always 32 bytes) that you then use with a symmetric cipher (AES-256-GCM, ChaCha20-Poly1305) to encrypt data. You cannot encrypt arbitrary-length messages directly with ML-KEM.
Q: What is the recommended default for new systems?
ML-KEM-768 for key encapsulation and ML-DSA-65 for digital signatures. Both target NIST Level 3, which provides a comfortable security margin without excessive overhead.
Q: Will these parameter sizes change?
The FIPS 203, 204, and 205 standards are finalized. The parameter sets and their sizes will not change. NIST may add new parameter sets in future updates, but existing ones are stable.
Sources
- NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard — All ML-KEM parameter sets, key sizes, and ciphertext sizes
- NIST FIPS 204: Module-Lattice-Based Digital Signature Standard — All ML-DSA parameter sets, key sizes, and signature sizes
- NIST FIPS 205: Stateless Hash-Based Digital Signature Standard — All SLH-DSA parameter sets including SHA-2 and SHAKE variants
- RFC 9881: ML-DSA Algorithm Identifiers for X.509 — OID assignments for ML-DSA (2.16.840.1.101.3.4.3.17/18/19)
- RFC 10024: PQ/T Hybrid Key Agreement Mechanisms for TLS 1.3 — IANA code points for hybrid TLS groups (X25519MLKEM768 = 0x4588)
- NIST: Post-Quantum Cryptography — HQC selection — HQC selected March 2025 as backup KEM for standardization (expected 2027)