Find the ML-KEM, ML-DSA or SLH-DSA parameter set that replaces your key, its exact size in bytes, and the NIST transition date for your strength.
Real migrations
All twelve sets approved in FIPS 203, 204 and 205, in bytes. The SLH-DSA SHAKE variants carry the same sizes and categories as the SHA2 sets shown.
| Parameter set | Replaces | Level | Public key | Ciphertext / sig |
|---|---|---|---|---|
| ML-KEM-512 | Key establishment | 1 | 800 | 768 |
| ML-KEM-768 | Key establishment | 3 | 1,184 | 1,088 |
| ML-KEM-1024 | Key establishment | 5 | 1,568 | 1,568 |
| ML-DSA-44 | Signature | 2 | 1,312 | 2,420 |
| ML-DSA-65 | Signature | 3 | 1,952 | 3,309 |
| ML-DSA-87 | Signature | 5 | 2,592 | 4,627 |
| SLH-DSA-SHA2-128s | Signature | 1 | 32 | 7,856 |
| SLH-DSA-SHA2-128f | Signature | 1 | 32 | 17,088 |
| SLH-DSA-SHA2-192s | Signature | 3 | 48 | 16,224 |
| SLH-DSA-SHA2-192f | Signature | 3 | 48 | 35,664 |
| SLH-DSA-SHA2-256s | Signature | 5 | 64 | 29,792 |
| SLH-DSA-SHA2-256f | Signature | 5 | 64 | 49,856 |
NIST IR 8547 Tables 2 and 4, and Section 4.1.3 for symmetric cryptography. The report is an initial public draft, so these are NIST's stated intentions rather than rules already in force. The date follows the algorithm's security strength, not its name.
| Family | Security strength | NIST intent |
|---|---|---|
| RSA, DH, ECDH, ECDSA, EdDSA, DSA | 112 bits | Deprecated after 2030, disallowed after 2035 |
| RSA, DH, ECDH, ECDSA, EdDSA, DSA | 128 bits or more | Disallowed after 2035 |
| AES, SHA-2, SHA-3 | 112 bits | Disallowed in 2030 |
| AES, SHA-2, SHA-3 | 128 bits or more | No post-quantum deadline |
Both were chosen for standardization and neither has a published FIPS, so no key or signature size is quoted here. HQC's parameters already changed once between rounds.
| Algorithm | Selected | Status |
|---|---|---|
| HQC | 2025 | Final standard expected 2027 |
| FN-DSA | 2022 | No FIPS 206 draft published |
Sizes and security categories are transcribed from FIPS 203, 204 and 205. Transition dates come from NIST IR 8547, an initial public draft, and may change before it is finalized. Check your own sector's rules, which can require an earlier migration.
You might also find these calculators useful
See which AES, RSA, ECC and hash key sizes are equally strong.
Guess resistance, crack time and NIST 800-63B rev 4 checks
Generate and verify SHA-256, MD5, SHA-1, SHA-512 and SHA-3 digests
Crack times by hash algorithm, work factor and GPU count
Post-quantum migration is a lookup, not a guess. NIST published the replacement algorithms in August 2024 and the transition schedule in November 2024, and both are keyed to something measurable: the security strength of the key you hold now. Enter that key and this page returns the FIPS 203, 204 or 205 parameter set that replaces it, the exact byte counts you will put on the wire instead, and the year NIST intends to deprecate and then disallow what you have. Where NIST's answer is to change nothing, the page says so rather than inventing work.
Post-quantum cryptography (PQC), also called quantum-safe cryptography, is the set of algorithms designed to stay secure against an attacker holding a cryptographically relevant quantum computer. The distinction that matters is which attack applies. Shor's algorithm solves integer factorisation and the discrete logarithm in polynomial time, so RSA, Diffie-Hellman, DSA and elliptic-curve schemes lose all of their strength — there is no larger key that repairs them, which is why they must be replaced rather than resized. Grover's algorithm is a generic search that at best halves the exponent of a brute-force key search, so symmetric ciphers and hash functions are weakened in theory but not broken, and NIST does not ask you to change them. NIST standardized three replacements in August 2024: ML-KEM (FIPS 203) for key establishment, ML-DSA (FIPS 204) for digital signatures, and SLH-DSA (FIPS 205) for signatures whose security rests only on hash functions.
Strength remaining against a quantum attacker
TLS is the case IR 8547 singles out for early migration, because a recorded handshake is a harvest-now target. Swapping ECDH P-256 for ML-KEM-768 takes the key exchange from 64 bytes to 1,184 plus a 1,088-byte ciphertext, which is why the deployed answer so far is a hybrid that sends both.
Signatures must stay verifiable for as long as the artefact ships, so the migration is about the verifier's lifetime rather than the signer's. ML-DSA-65 at 3,309 bytes is the usual choice; SLH-DSA is the option when you want security resting only on hash functions, at 16,224 bytes for the compact level-3 set.
A boot ROM has a fixed signature slot and a device life measured in decades. SLH-DSA-SHA2-128s has the smallest public key of any standardized set at 32 bytes, but its signature is 7,856 — the trade runs the opposite way from lattice schemes, and the slot size usually decides it.
Where the air interface charges per byte, ML-KEM-512 is the smallest standardized KEM at 800 bytes of public key and a 768-byte ciphertext. Compare that against your MTU and duty cycle before choosing a level, because a level-5 target nearly doubles both figures.
Data that must stay confidential for decades is the clearest harvest-now case, and it is also the one place a top-level KEM is easy to justify. The archive's symmetric layer usually needs no change at all: AES-256 has no post-quantum deadline in IR 8547.
Every certificate in a chain carries a public key and a signature, so the size increase compounds with depth. Sum the public key and signature figures for each level of your hierarchy before assuming a chain still fits the buffers your clients allocate.
NIST IR 8547 keys its schedule to security strength. A public-key algorithm providing 112 bits is to be deprecated after 2030 and disallowed after 2035; one providing 128 bits or more is to be disallowed after 2035 with no earlier deprecation. RSA-2048 and RSA-3072 therefore have different dates, and reading the deadline off the word "RSA" gets one of them wrong.
Traffic captured today can be stored and decrypted once a quantum computer exists, so confidentiality that must outlast the machine is already at risk. IR 8547 says NIST expects to prioritise migration to quantum-resistant key establishment inside application-specific guidance, particularly for interactive protocols such as TLS and IKE, ahead of the general 2035 date. Signatures do not carry the same retroactive exposure: a signature verified today cannot be forged retroactively.
An ECDH P-256 exchange puts 64 bytes of public key on the wire; ML-KEM-768 puts 1,184, plus a 1,088-byte ciphertext. An ECDSA P-256 signature is 64 bytes; ML-DSA-65 is 3,309 and SLH-DSA-SHA2-256s is 29,792. Those numbers decide whether a record fits in one packet, whether a firmware slot holds the signature, and whether a handshake still fits your MTU. They are the reason to plan with real byte counts rather than algorithm names.
NIST defines five security strength categories, but the standardized parameter sets do not fill them evenly. ML-KEM is claimed at levels 1, 3 and 5; ML-DSA at 2, 3 and 5; SLH-DSA at 1, 3 and 5. Nothing in FIPS 203, 204 or 205 is claimed at level 4. Picking a target level that no algorithm offers silently promotes you to the next one up, and NIST itself describes levels 4 and 5 as likely excessive.
To replace the public-key algorithms that a quantum computer would break outright. Shor's algorithm solves factorisation and the discrete logarithm efficiently, which removes all of the security of RSA, Diffie-Hellman, DSA and elliptic-curve cryptography — the schemes that today protect key exchange and digital signatures. Post-quantum algorithms are built on different mathematical problems, principally structured lattices and hash functions, for which no comparable quantum attack is known. The purpose is not to make encryption stronger in general; symmetric encryption already survives, and NIST asks you to keep it.
Three, all finalized in August 2024. ML-KEM (FIPS 203) is the key-encapsulation mechanism, with parameter sets ML-KEM-512, ML-KEM-768 and ML-KEM-1024; FIPS 203 names ML-KEM-768 as its recommended default. ML-DSA (FIPS 204) is the general-purpose signature scheme, with ML-DSA-44, ML-DSA-65 and ML-DSA-87. SLH-DSA (FIPS 205) is the hash-based signature scheme, approving twelve parameter sets whose security rests only on hash function properties. HQC was selected in March 2025 as a backup to ML-KEM, with a final standard expected in 2027, and FN-DSA is still awaiting a FIPS 206 draft.
Yes, at 128 bits and above, and NIST says so directly. Grover's algorithm searches a keyspace in quadratically fewer steps, which taken at face value halves the effective key length — that theoretical floor is what this page shows. NIST's own answer to whether AES keys should be doubled now is that Grover cannot be parallelised efficiently and quantum hardware is far more expensive, so it is "quite likely that Grover's algorithm will provide little or no advantage in attacking AES, and AES 128 will remain secure for decades to come." No FIPS 203, 204 or 205 parameter set replaces AES, and IR 8547 sets no post-quantum deadline for symmetric cryptography at 128 bits or above.
Under NIST IR 8547, which is still an initial public draft, the schedule follows security strength rather than the algorithm's name. Public-key algorithms providing 112 bits — RSA-2048, 224-bit curves, 2048-bit Diffie-Hellman — are to be deprecated after 2030 and disallowed after 2035. Those providing 128 bits or more are to be disallowed after 2035. National Security Memorandum 10, quoted in the same report, sets 2035 as the target for completing federal migration. Sector rules and application-specific NIST guidance may require an earlier move, and IR 8547 says key establishment in protocols such as TLS is expected to be prioritised.
Enough to matter, and it varies by more than an order of magnitude within the standards. For key establishment, ML-KEM-768 has a 1,184-byte public key and a 1,088-byte ciphertext, against roughly 64 bytes for an ECDH P-256 public key. For signatures, ML-DSA-65 has a 1,952-byte public key and a 3,309-byte signature, against about 64 bytes each for ECDSA P-256. SLH-DSA inverts the trade: a 32-byte public key at level 1, but signatures from 7,856 bytes up to 49,856 for the fast level-5 set. The public key and signature figures on this page come from the tables in FIPS 203, 204 and 205.
The security assumption, and the size trade that follows from it. ML-DSA is lattice-based: its security rests on the Module Learning With Errors problem, and it is fast with moderate signatures of 2,420 to 4,627 bytes. SLH-DSA is stateless hash-based: its security rests only on the properties of the underlying hash function, so it survives any future break of lattice assumptions, but its signatures run from 7,856 to 49,856 bytes. NIST standardized both deliberately. ML-DSA is the general-purpose choice; SLH-DSA is for cases where a single conservative assumption is worth the bytes, such as firmware roots of trust.
Five categories that express a post-quantum parameter set's strength by comparison with a well-studied symmetric primitive rather than a single bit count. Level 1 is at least as hard as a key search on AES-128, level 3 as AES-192, and level 5 as AES-256; levels 2 and 4 are pinned to collision search on SHA-256 and SHA-384. NIST's own assessment is that levels 4 and 5 are "likely excessive," 2 and 3 "probably secure for the foreseeable future," and 1 "likely secure for the foreseeable future, unless quantum computers improve faster than is anticipated." No standardized parameter set is claimed at level 4.
Recording encrypted traffic today so it can be decrypted once a quantum computer becomes available. It changes the migration order, because it makes confidentiality retroactively vulnerable while authenticity is not: a session key protected by ECDH in 2026 can be recovered in 2040, but a signature verified in 2026 cannot be forged after the fact. That asymmetry is why IR 8547 expects key establishment in interactive protocols to be prioritised over signatures, and why data with a long confidentiality requirement is the first thing to move.
It is the common deployment answer during the transition, and NIST accommodates it. A hybrid key establishment combines a classical scheme with a post-quantum one so that the shared secret stays safe if either component is later broken, which hedges against an undiscovered weakness in a young algorithm. NIST's PQC FAQ states it will accommodate hybrid key establishment and dual signatures in FIPS 140 validation when suitably combined with an approved scheme, and SP 800-56C already describes an approved generic composite technique. The cost is size: you send both, so the byte figures on this page are a floor, not the total.