PQC at a Glance
PQC at a Glance is the one-screen reference for the whole NIST post-quantum portfolio: ML-KEM for key establishment, ML-DSA, SLH-DSA, and the draft FN-DSA for signatures, and the code-based backup KEM HQC, all in a single comparison with the sizes that decide the engineering work. The compute for these algorithms is fast on mainstream hardware, so the thing to plan around is bytes: the public keys, ciphertexts, and signatures that ripple into certificates, handshakes, transport, and storage. Every figure here is drawn from the standard, and the draft and pre-standard values are marked so you never point a compliance requirement at an algorithm that is still moving.
The short version:
- There are two jobs. ML-KEM does key establishment, and ML-DSA, SLH-DSA, and FN-DSA do signatures. HQC is the backup KEM on different math.
- The defaults most programs land on are ML-KEM-768 for key exchange and ML-DSA-65 for general-purpose signing.
- The security categories (1, 3, 5) map to classical strength tiers, roughly AES-128, AES-192, and AES-256. Higher category means a wider margin and larger artifacts.
- The cost is size, so the comparison to internalize is public-key, ciphertext, and signature bytes, which is where the migration effort lives.
- FN-DSA and HQC are pre-standard, so their figures are planning targets to re-verify against the final text, and they cannot satisfy FIPS 140-3 approved-algorithm requirements yet.
What are all the post-quantum standards side by side?
Every finalized and selected NIST standard in one table. The KEMs list public key, private key, and ciphertext; the signatures list public key, private key, and signature, because those are the artifacts each type puts on the wire. Sizes are in bytes and come verbatim from the standards (FIPS 203/204/205 Tables) and, for the pre-standard algorithms, from the FALCON and HQC specifications pending the final text.
| Algorithm | Type | Family | NIST category | Public key | Private key | Ciphertext / signature | Primary use |
|---|---|---|---|---|---|---|---|
| ML-KEM-512 | KEM | Lattice | 1 | 800 | 1,632 | 768 (ct) | Key establishment, constrained tier |
| ML-KEM-768 | KEM | Lattice | 3 | 1,184 | 2,400 | 1,088 (ct) | Key establishment, default |
| ML-KEM-1024 | KEM | Lattice | 5 | 1,568 | 3,168 | 1,568 (ct) | Key establishment, high assurance |
| ML-DSA-44 | Signature | Lattice | 2 | 1,312 | 2,560 | 2,420 (sig) | Signatures, lightweight tier |
| ML-DSA-65 | Signature | Lattice | 3 | 1,952 | 4,032 | 3,309 (sig) | Signatures, default |
| ML-DSA-87 | Signature | Lattice | 5 | 2,592 | 4,896 | 4,627 (sig) | Signatures, national-security tier |
| SLH-DSA-128s | Signature | Hash | 1 | 32 | 64 | 7,856 (sig) | Conservative signing, roots of trust |
| SLH-DSA-128f | Signature | Hash | 1 | 32 | 64 | 17,088 (sig) | Conservative signing, faster variant |
| SLH-DSA-192s | Signature | Hash | 3 | 48 | 96 | 16,224 (sig) | Conservative signing, category 3 |
| SLH-DSA-192f | Signature | Hash | 3 | 48 | 96 | 35,664 (sig) | Conservative signing, faster variant |
| SLH-DSA-256s | Signature | Hash | 5 | 64 | 128 | 29,792 (sig) | Conservative signing, category 5 |
| SLH-DSA-256f | Signature | Hash | 5 | 64 | 128 | 49,856 (sig) | Conservative signing, faster variant |
| FN-DSA-512 | Signature (draft) | Lattice (NTRU) | 1 | 897 | pending | 666 (sig) | Compact signatures, size-sensitive |
| FN-DSA-1024 | Signature (draft) | Lattice (NTRU) | 5 | 1,793 | pending | 1,280 (sig) | Compact signatures, category 5 |
| HQC-128 | KEM (pre-standard) | Code | 1 | 2,241 | 2,321 | 4,433 (ct) | Backup KEM, family diversity |
| HQC-192 | KEM (pre-standard) | Code | 3 | 4,514 | 4,602 | 8,978 (ct) | Backup KEM, category 3 |
| HQC-256 | KEM (pre-standard) | Code | 5 | 7,237 | 7,333 | 14,421 (ct) | Backup KEM, category 5 |
The SLH-DSA private-key sizes are 4n bytes from the parameter n (16, 24, 32 for categories 1, 3, 5), and the SHA-2 and SHAKE instantiations of each SLH-DSA set share the same key and signature sizes. FN-DSA private-key size is marked pending because the final FIPS 206 encoding is not published. For the classical baseline these replace: a secp256k1 or P-256 elliptic-curve public key is 32 to 33 bytes and an ECDSA signature is on the order of 64 to 72 bytes, so every row here is a step up in size, which is the whole planning story.
Sources:
NIST FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard, August 2024 (ML-KEM sizes).
NIST FIPS 204, Module-Lattice-Based Digital Signature Standard, Tables 1 and 2, August 2024 (ML-DSA sizes and categories).
NIST FIPS 205, Stateless Hash-Based Digital Signature Standard, Table 2 and §11, August 2024 (SLH-DSA sizes and categories).
FALCON specification, falcon-sign.info (FN-DSA-512 and FN-DSA-1024 pre-standard figures). [OPERATOR VERIFY: re-verify FN-DSA sizes against FIPS 206 once published; none announced as of 2026-07-12.]
HQC specification, pqc-hqc.org (HQC pre-standard figures). [OPERATOR VERIFY: re-verify HQC sizes and parameter-set names against the NIST HQC draft/final standard once published.]
What are the NIST security categories?
The category number is the security tier, and it maps every algorithm onto the same scale so a KEM and a signature at the same category carry a comparable margin. NIST defined five categories by pinning each to the difficulty of attacking a well-known symmetric primitive:
| Category | Classical anchor | Rough strength |
|---|---|---|
| 1 | As hard to break as AES-128 key search | Baseline post-quantum tier |
| 2 | As hard as finding an SHA-256 collision | Between 1 and 3 |
| 3 | As hard to break as AES-192 key search | Common general-purpose margin |
| 5 | As hard to break as AES-256 key search | Highest tier, national-security work |
Category 4 exists in the definition (SHA-384 collision hardness) but no standardized parameter set targets it, which is why the table jumps from 3 to 5. The practical read is that categories 1 through 5 are increasing margins at increasing artifact cost, and most programs default to category 3 unless policy or a long data lifetime calls for category 5.
Source: NIST, “Submission Requirements and Evaluation Criteria for the Post-Quantum Cryptography Standardization Process,” §4.A.5, which defines the five security categories against AES and SHA anchors.
Which post-quantum algorithm should I use?
Start from the job, then the tier. Key establishment is a different problem from signing, and picking the wrong family for the job is the most common early error. The guidance most estates converge on:
- For key establishment, deploy ML-KEM-768. It is NIST’s recommended default, category 3, and the direct replacement for ECDH in TLS and similar protocols. Run it as a hybrid with a classical algorithm so the session holds if either component survives. This is the urgent half of the transition, because it closes harvest-now-decrypt-later exposure.
- For general-purpose signatures, deploy ML-DSA-65. It is the balanced category-3 default and the signature counterpart to ML-KEM-768, with artifacts that certificate chains and code-signing pipelines can absorb.
- For long-lived roots of trust and firmware, consider SLH-DSA. Its security rests only on hash-function strength, so it is the hedge against a lattice break, and its slow signing and very large signatures are affordable where signing is infrequent and the trust horizon is decades.
- Where signature size is the binding constraint, keep FN-DSA on the roadmap. Its signatures are the smallest on the standardization track, but it is still a draft and its floating-point sampler is the hardest of the standardized signatures to implement in constant time, so it is a design-for-later target rather than a deploy-today choice.
- For KEM family diversity, track HQC. It is the code-based backup so a future lattice break would leave key establishment a second, independent option. It is selected but pre-standard, so deploy ML-KEM now and keep HQC on the roadmap rather than waiting for it.
The architectural throughline under all of this is crypto-agility: choose the finalized default now, deploy it as a swappable provider, and build so the next algorithm or parameter change is a configuration update rather than a re-engineering project. That is what lets a program adopt the pre-standard algorithms cleanly the day their final text lands.
Source: NIST FIPS 203, §8, which names ML-KEM-768 as the recommended default and advises the strongest practical parameter set when first establishing protections.
Why are the post-quantum sizes so much bigger than classical?
The extra bytes are the direct cost of the hard math that resists a quantum computer, and they are the reason a post-quantum migration is a bandwidth and protocol project rather than a compute one. A classical elliptic-curve public key is 32 bytes because the elliptic-curve discrete logarithm is hard per bit; the post-quantum problems (lattice, code, and hash based) need larger objects to reach the same margin against Shor’s algorithm. The size profile splits by family:
- Lattice KEMs and signatures (ML-KEM, ML-DSA) land in the low kilobytes, which is why they are the deployable defaults.
- Hash-based signatures (SLH-DSA) carry the largest signatures in the portfolio, from about 8 kilobytes to nearly 50, in exchange for the most conservative security foundation.
- Code-based KEMs (HQC) run several times larger than the comparable ML-KEM set, which is the price of an independent, non-lattice foundation.
- NTRU-lattice signatures (FN-DSA) are the compact outlier, smaller than ML-DSA, which is the entire reason the scheme stays in the portfolio despite its implementation difficulty.
The engineering consequence is consistent across families: larger keys and signatures stress certificate chains, parsers, transport limits, handshake round trips, and storage. Compute is rarely the constraint. Bytes on the wire are.
Common misconceptions
- “The number in the name is a key length.” It is not. The 512, 768, 65, 87, 128, 1024 numbers reflect internal lattice dimensions or targeted security levels, mapped to a NIST category. The real sizes are the byte figures in the table, which are much larger.
- “Higher category is always better.” Higher category is a wider margin at a larger artifact cost. Category 3 (ML-KEM-768, ML-DSA-65) suits most work, and category 5 is reserved for national-security systems or long data lifetimes where the extra bytes are worth it.
- “There is one post-quantum algorithm.” There are two jobs and several algorithms across three math families, deliberately, so that a break in one family does not take down the whole transition.
- “The draft algorithms are ready to deploy for compliance.” FN-DSA and HQC are pre-standard. They cannot satisfy FIPS 140-3 approved-algorithm requirements yet, so validated deployment relies on ML-KEM, ML-DSA, and SLH-DSA.
- “Post-quantum replaces my symmetric crypto too.” It does not. AES-256 and the SHA-2 and SHA-3 hashes carry forward with at most a parameter bump, so this table is the public-key story, which is the whole migration.
Questions people ask
Which two algorithms do I actually deploy first? ML-KEM-768 for key establishment, run as a hybrid with a classical algorithm, and ML-DSA-65 for general-purpose signatures. Key exchange is urgent because of HNDL; signatures follow on a slower, deliberate track.
What is the difference between a KEM and a signature here? A KEM (ML-KEM, HQC) agrees on a shared secret over an open network, replacing key exchange. A signature (ML-DSA, SLH-DSA, FN-DSA) proves authenticity and integrity, replacing certificate and code signing. They solve separate problems and are not interchangeable.
Why is SLH-DSA in the table if its signatures are so large? Because its security rests only on hash functions, the oldest and best-studied assumption in the field, which makes it the conservative hedge for long-lived roots of trust and firmware where a lattice break would be catastrophic. The large signatures are affordable in those low-volume roles.
Are FN-DSA and HQC safe to build on now? Design toward them, but do not depend on them for compliance. Both are pre-standard, their parameters and encodings may change, and their figures here are planning references to re-verify against the final text. Deploy the finalized defaults now and keep the drafts on the roadmap through crypto-agility.
How do these categories compare to my current AES and RSA? Category 1 is roughly AES-128 strength, category 3 roughly AES-192, and category 5 roughly AES-256. On the public-key side these replace RSA and elliptic-curve algorithms outright, since Shor’s algorithm breaks those and does not touch the post-quantum families.
Where do the exact sizes come from? From the standards themselves: FIPS 203 for ML-KEM, FIPS 204 Tables 1 and 2 for ML-DSA, and FIPS 205 Table 2 for SLH-DSA. The FN-DSA and HQC figures come from the FALCON and HQC specifications pending their final NIST standards, and are marked accordingly.
Everything here is the map, given freely. When your team needs these standards sized, sequenced, and matched to your own protocols and estate, that’s what an alignment briefing is for.
Last verified 2026-07-12 · Maintained by Addie LaMarr, LaMarr Labs.