PQC parameter reference
ML-KEM, ML-DSA and SLH-DSA: parameter sets, key and signature sizes
The three NIST post-quantum standards are named ML-KEM, ML-DSA and SLH-DSA. This page is the parameter table: exact key, ciphertext and signature sizes, the security category of each set, and what each one is a replacement for.
Decision brief
- Primary query
- ml-kem
- Best for
- Engineers who run PKI or own cryptographic change and need reviewable evidence rather than a spreadsheet.
- Safety boundary
- Evidence supports decisions; it is not proof of implementation safety or compliance.
NIST finalized FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) in August 2024. ML-KEM is a key-encapsulation mechanism and replaces the key exchange in a protocol, not a signature. ML-DSA and SLH-DSA are signature schemes and replace RSA and ECDSA signatures. Confusing the two roles is the most expensive early mistake in a migration plan, because it produces a rollout schedule that targets the wrong systems.
Sizes are the constraint that actually drives the work. An ML-KEM-768 encapsulation key is 1184 bytes against 32 for an X25519 public key. An ML-DSA-65 signature is 3309 bytes against 64 for an ECDSA P-256 signature and 256 for an RSA-2048 signature. Anything with a fixed record size, a fixed certificate slot, a UDP-sized budget, or a smartcard with a few kilobytes of storage has to be re-examined against these numbers rather than against the algorithm name.
The standardized parameters are not identical to the round-three submissions they came from. ML-DSA-65 signatures are 3309 bytes; the Dilithium3 submission produced 3293. ML-DSA-87 is 4627 where Dilithium5 was 4595. Test vectors, buffer sizes and interoperability claims written against Kyber or Dilithium therefore do not transfer to ML-KEM or ML-DSA unchanged, and a library that still advertises the old names is very likely still implementing the old parameters.
Reference
Values you can look up and check against your own systems
ML-KEM (FIPS 203) key encapsulation
Replaces the key exchange step. The shared secret is 32 bytes for every parameter set.
| Parameter set | Security category | Encapsulation key | Decapsulation key | Ciphertext |
|---|---|---|---|---|
| ML-KEM-512 | 1 | 800 bytes | 1632 bytes | 768 bytes |
| ML-KEM-768 | 3 | 1184 bytes | 2400 bytes | 1088 bytes |
| ML-KEM-1024 | 5 | 1568 bytes | 3168 bytes | 1568 bytes |
ML-DSA (FIPS 204) lattice signatures
The general-purpose signature replacement. Sizes differ from the Dilithium submission they derive from.
| Parameter set | Security category | Public key | Private key | Signature |
|---|---|---|---|---|
| ML-DSA-44 | 2 | 1312 bytes | 2560 bytes | 2420 bytes |
| ML-DSA-65 | 3 | 1952 bytes | 4032 bytes | 3309 bytes |
| ML-DSA-87 | 5 | 2592 bytes | 4896 bytes | 4627 bytes |
SLH-DSA (FIPS 205) hash-based signatures
Stateless and based only on hash-function security, which is why it is the conservative choice for firmware and code signing. The s sets are small and slow to sign; the f sets are fast and large.
| Parameter set | Security category | Public key | Private key | Signature |
|---|---|---|---|---|
| SLH-DSA-128s | 1 | 32 bytes | 64 bytes | 7856 bytes |
| SLH-DSA-128f | 1 | 32 bytes | 64 bytes | 17088 bytes |
| SLH-DSA-192s | 3 | 48 bytes | 96 bytes | 16224 bytes |
| SLH-DSA-192f | 3 | 48 bytes | 96 bytes | 35664 bytes |
| SLH-DSA-256s | 5 | 64 bytes | 128 bytes | 29792 bytes |
| SLH-DSA-256f | 5 | 64 bytes | 128 bytes | 49856 bytes |
Size change against what you have now
The ratio, not the absolute number, is what breaks a fixed-size field or a constrained device.
| Today | Size | Successor | Size | Growth |
|---|---|---|---|---|
| X25519 public key | 32 bytes | ML-KEM-768 encapsulation key | 1184 bytes | 37x |
| ECDH P-256 public key | 65 bytes | ML-KEM-768 encapsulation key | 1184 bytes | 18x |
| ECDSA P-256 signature | 64 bytes | ML-DSA-65 signature | 3309 bytes | 52x |
| RSA-2048 signature | 256 bytes | ML-DSA-65 signature | 3309 bytes | 13x |
| RSA-2048 public key | 256 bytes | ML-DSA-65 public key | 1952 bytes | 8x |
| ECDSA P-256 signature | 64 bytes | SLH-DSA-128s signature | 7856 bytes | 123x |
Which standard applies to which job
| Job | Standard | Usual choice |
|---|---|---|
| TLS key exchange | FIPS 203 ML-KEM | ML-KEM-768, usually inside a hybrid group with X25519 |
| TLS certificate signature | FIPS 204 ML-DSA | ML-DSA-44 or ML-DSA-65, subject to CA and client support |
| Code and firmware signing | FIPS 205 SLH-DSA | A small (s) parameter set, where a slow signing operation is acceptable |
| Long-lived document signing | FIPS 204 or 205 | SLH-DSA where the verification horizon exceeds confidence in lattice assumptions |
| Symmetric encryption and hashing | No change required | AES-256 and SHA-384 or SHA-512, per existing guidance |
Capabilities
What the operating model needs to do
Role before parameter
Decide whether a system needs a KEM or a signature first. The parameter set is the second question, not the first.
Size budgets
Check every fixed-size field, record format, packet budget and hardware key slot against the byte counts before committing to a parameter set.
Category matching
Match the NIST security category to the classical strength you are replacing rather than reaching for the largest set by default.
Name discipline
Track whether a dependency implements ML-KEM or still ships Kyber, because the parameters and test vectors are not the same.
Workflow
A repeatable path to evidence
Use explicit scope, accountable decisions, and verification gates. Keep unknowns visible so progress is not manufactured by narrowing the denominator.
- 1
Classify
Separate key-establishment uses from signature uses across the inventory. They migrate on different schedules and depend on different vendors.
- 2
Select
Choose a parameter set per use, recording the size budget and the security category that justified it.
- 3
Measure
Test the real handshake, certificate, or artifact size against protocol and hardware limits before rollout, not after.
- 4
Record
Store the chosen algorithm and parameter set as an inventory attribute so drift back to a classical primitive is detectable.
Expected deliverables
Artifacts the next team can inspect
- Key-establishment and signature use inventory
- Parameter set selection with recorded justification
- Size budget test results per protocol and device class
- Library and vendor support matrix by algorithm name
- Policy entry naming approved parameter sets
Buyer checklist
Questions for a proof of value
- 01Which systems need a KEM and which need a signature?
- 02Which fixed-size fields or hardware key slots cannot hold the successor size?
- 03Do our dependencies implement the standardized parameters, or the earlier Kyber and Dilithium submissions?
- 04What security category does each system actually require?
- 05Can the inventory tell us if a migrated system silently reverted to a classical primitive?
Limits and cautions
What this page does not promise
- Sizes above are the standardized FIPS 203, 204 and 205 parameters. Round-three Kyber and Dilithium values differ and are not interchangeable.
- A NIST security category is a claim about a defined attack model, not a promise about a specific implementation.
- SLH-DSA signing is substantially slower than ML-DSA signing. Confirm signing throughput before choosing it for a high-volume path.
- Hardware and HSM support for these algorithms is uneven. Verify against the specific firmware version you will deploy.
Continue evaluating
Related decision pages
Implementation guide
How to build and maintain a cryptographic inventory
A practical guide to inventory scope, evidence, asset identity, confidence, ownership, CBOM export, continuous discovery, and migration use.
Read pageCBOM guide
Cryptographic bill of materials: what a CBOM contains and how to use it
Understand CBOM scope, CycloneDX cryptographic assets, evidence, relationships, confidence, validation, diffs, and post-quantum migration use.
Read pagePQC migration guide
Post-quantum cryptography migration: an operating roadmap
A practical roadmap for PQC inventory, prioritization, standards tracking, vendor dependencies, interoperability testing, rollout, verification, and drift control.
Read pageCryptographic inventory software
A cryptographic inventory your engineering teams can keep current
Discover cryptographic assets in source, dependencies, configuration, containers, and authorized TLS endpoints. Preserve evidence, ownership, and change history in one inventory.
Read pageTalk to us about one representative repository
Qubrisk is in development and there is no self-serve signup yet. Tell us what your estate looks like and we will show you the evidence, the CBOM output, and the limits, without a sales sequence.