Post-quantum key and signature sizes, explained
Switch an RSA-2048 or Ed25519 deployment to a post-quantum algorithm and the first thing you notice is not the math, it is the byte count. A key or signature that used to fit comfortably in a single network packet might not anymore. This is not an implementation flaw or a rushed standard; it is a direct consequence of the hard problem each algorithm is built on. Understanding why the sizes grew, and by how much, makes it much easier to decide where that growth actually matters and where it does not.
Why the underlying math produces bigger objects
Classical public-key cryptography in wide use today, RSA and elliptic-curve schemes like X25519 and Ed25519, gets its compactness from number-theoretic structure. An elliptic curve point is just a coordinate pair on a curve; a 256-bit curve gives you a 32-byte key because the hard problem (discrete log) is believed to need roughly that many bits of representation to reach a given security level, with no extra packaging required.
Post-quantum schemes standardized by NIST do not have that shortcut, because they rest on different hard problems that do not compress as neatly:
- Lattice-based schemes (ML-KEM, ML-DSA, Falcon) represent keys as vectors or matrices of polynomial coefficients over a ring. Security depends on the dimension and modulus of that structure, and both have to stay large enough to resist known lattice-reduction attacks. The result is public keys and ciphertexts measured in hundreds to thousands of bytes, not tens.
- Hash-based schemes (SLH-DSA) build a signature out of many one-time signatures stitched together with a Merkle tree. The public key can be tiny, just a hash value, but a signature has to carry enough of the tree's authentication path and one-time signature material to prove the leaf is genuine. That pushes signatures into the tens of kilobytes.
Put simply, elliptic curves get a direct geometric representation of the hard problem. Lattices need enough redundancy that an attacker cannot efficiently find a short vector. Hash-based schemes trade a tiny key for a large signature because they have only hash function security to rely on, with no algebraic shortcut available to shrink the proof.
The actual numbers
Here is what NIST's finalized standards specify for key exchange, next to the classical scheme it mostly replaces.
| Algorithm | Security category | Public key | Ciphertext |
|---|---|---|---|
| X25519 (ECDH) | approx. 128-bit | 32 B | n/a, produces a shared secret rather than a ciphertext |
| ML-KEM-512 (FIPS 203) | Level 1 | 800 B | 768 B |
| ML-KEM-768 (FIPS 203) | Level 3 | 1184 B | 1088 B |
| ML-KEM-1024 (FIPS 203) | Level 5 | 1568 B | 1568 B |
And for signatures:
| Algorithm | Security category | Public key | Signature |
|---|---|---|---|
| Ed25519 | approx. 128-bit | 32 B | 64 B |
| RSA-2048 | 112-bit | 256 B | 256 B |
| Falcon-512 / FN-DSA | Level 1 | 897 B | approx. 666 B |
| ML-DSA-44 (FIPS 204) | Level 2 | 1312 B | 2420 B |
| ML-DSA-65 (FIPS 204) | Level 3 | 1952 B | 3309 B |
| ML-DSA-87 (FIPS 204) | Level 5 | 2592 B | 4627 B |
| SLH-DSA, 128s (FIPS 205) | Level 1 | 32 to 64 B | 7856 B |
| SLH-DSA, 256s (FIPS 205) | Level 5 | 32 to 64 B | 29792 B |
Two patterns stand out. First, ML-KEM's growth over X25519 is modest in relative terms, a few hundred bytes up to a bit over a kilobyte, which is a large part of why key exchange has been the easier half of the PQC transition. Second, signatures scale much worse: an ML-DSA-44 signature is roughly 38 times the size of an Ed25519 signature, and SLH-DSA at its most conservative parameter set is nearly 500 times larger. If your protocol sends a signature per message rather than once per session, that multiplier is what will actually hurt.
Where this bites: TLS handshakes and certificate chains
A TLS 1.3 handshake using ML-KEM-768 for key exchange adds roughly a kilobyte to the ClientHello and ServerHello compared with X25519. That is well within a single TCP segment on most networks and rarely noticeable outside of genuinely constrained links such as satellite backhaul, LoRa, or legacy embedded radios.
Certificates are where the pain concentrates, because a chain carries a public key and a signature for every certificate in it. Swap a three-certificate chain from Ed25519 or RSA to ML-DSA-65 and you are adding roughly 2 KB of public key material and nearly 10 KB of signatures across the chain, before counting the leaf certificate's own key-exchange parameters. That can push some handshakes past the point where they fit in the initial congestion window, adding a round trip on lossy connections. It is also enough to break assumptions baked into DNSSEC record sizes, firmware signing formats, and anything that encodes a fixed maximum record length.
Falcon versus ML-DSA, and where SLH-DSA fits
NIST standardized both ML-DSA (FIPS 204, the primary general-purpose signature) and Falcon (soon to be renamed FN-DSA) because the two make different tradeoffs on a related lattice family. ML-DSA uses simpler arithmetic, Module-LWE with deterministic rounding and no floating point, which makes a constant-time implementation much easier to get right and to audit, at the cost of signatures three to four times larger than Falcon's. Falcon reaches compact signatures by signing with a trapdoor sampler over NTRU lattices, but that sampler needs careful floating-point Gaussian sampling, which is considerably harder to implement without timing side channels.
If your priority is signature size, think firmware images, constrained bandwidth, or deep certificate chains, Falcon is worth the added implementation effort. If your priority is a conservative implementation that many platforms can get right on the first attempt, ML-DSA is the safer default, and it is the one most TLS stacks and libraries have adopted first.
SLH-DSA sits in a different category. Its security reduces only to properties of the hash function, with no algebraic structure that a future mathematical advance could undermine the way it might for a lattice problem. That conservatism is also why NSA's CNSA 2.0 does not include it: the agency wants the smaller, faster lattice schemes for routine use, and reserves hash-based constructions, specifically LMS and XMSS, for firmware signing, where a signature is generated rarely and verified on a resource-constrained device. Use SLH-DSA where you want a long-term hedge against an unforeseen lattice break and can afford tens of kilobytes per signature. Do not default to it for anything latency-sensitive.
Practical guidance
For most protocols, the size increase from ML-KEM is manageable and should not force an architecture change. For signatures, size is a real design input, not an afterthought:
- Certificate chains: budget for two to five times the current handshake byte count, and test against real network paths, not just loopback.
- High-frequency signing, logging, telemetry, per-message authentication: avoid SLH-DSA; prefer ML-DSA-44 or Falcon-512 if the implementation effort is affordable.
- Firmware and code signing: SLH-DSA, or LMS/XMSS, is fine, because you sign once per release and the size cost is paid once, not per transaction.
- Constrained links such as satellite, LPWAN, or legacy embedded radios: Falcon's smaller signatures are usually worth the extra implementation cost, but measure before committing.
If you want the exact delta for your own protocol's handshake or certificate chain rather than an estimate, the size comparator on this site's home page lets you pick algorithm pairs and get the byte totals directly, which is usually faster than working it out from the specs by hand.