Parameters & Sizes

Post-quantum keys, ciphertexts, and signatures are far larger than RSA-2048 or elliptic-curve equivalents. This page consolidates the sizes across standardized, selected, and notable candidate/historical schemes alongside the classical baselines, and explains what those sizes mean once they hit real protocols.

Consolidated size table

All values are in bytes. KEM rows give the public encapsulation key (ek) and ciphertext (ct); signature rows give the public key (pk) and signature (sig). Sizes are approximate where rounding or encoding varies.

Falcon signature sizes shown are the fixed-length padded values (666 / 1280). The standard Falcon-512 / Falcon-1024 produce variable-length signatures — typically ~650 / ~1270 bytes, up to 752 / 1462 — so libraries report the padded numbers here while falcon.html gives the variable-length detail.

HQC does not yet have a finalized FIPS standard, so its sizes may be adjusted slightly as the final standard draft is settled.

Reading the table — the tradeoffs

• Lattice KEMs (ML-KEM) are well-balanced: roughly 1 KB each way, fast. This is why ML-KEM-768 is the common default.
• Classic McEliece inverts the tradeoff: tiny ciphertexts but a public key over a quarter-megabyte, which makes it impractical to ship keys per-connection but attractive where a public key is pinned once and reused.
• ML-DSA signatures sit in the 2.4–4.6 KB range — large but manageable.
• Falcon: among the post-quantum signature schemes selected by NIST, Falcon/FN-DSA has a very compact overall size, at the cost of a difficult-to-secure signer.
• SLH-DSA pays heavily in signature size, and its f ("fast") variants trade even larger signatures for faster signing versus the s ("small") variants.

What the sizes mean for protocols

Size is not a cosmetic concern — it interacts with hard protocol and network limits:

1. TLS record and ClientHello limits. A hybrid key share (X25519 + ML-KEM-768) pushes the ClientHello toward or past common ~1.5 KB assumptions, and some middleboxes mishandle large or fragmented initial flights. A full PQC certificate chain (multiple ML-DSA-65 public keys and signatures) can run to tens of kilobytes, adding round-trips.
2. MTU and fragmentation. The typical Ethernet MTU is 1500 bytes. KEM ciphertexts and signatures routinely exceed a single packet, forcing IP/QUIC fragmentation or extra TLS records, which raises latency and amplifies packet-loss impact.
3. UDP-based protocols (DTLS, QUIC, IKE). These are especially sensitive: large handshake messages must be fragmented at the application layer, and oversized first flights enable amplification-attack concerns.
4. Certificate storage and chains. Each hop in an X.509 chain now carries a multi-kilobyte signature plus a multi-kilobyte public key. Deep chains multiply this; consider chain shortening and intermediate suppression.

Why ML-KEM-768 / ML-DSA-65 are common defaults

They sit at the sweet spot: Level 3 security margin, sub-2 KB public keys, sub-3.5 KB signatures/ciphertexts, fast constant-time implementations, and the widest interoperability across libraries and TLS stacks. Unless you have a confidentiality horizon that demands Level 5 or a size budget that forces Falcon, this pairing is the safe starting point.

Related

Standards & references

• FIPS 203 (ML-KEM) — defines the KEM parameter sets and their sizes.
• FIPS 204 (ML-DSA) — defines the lattice signature parameter sets and their sizes.
• FIPS 205 (SLH-DSA) — defines the hash-based signature parameter sets and their sizes.
• NIST Post-Quantum Cryptography project — the source for all standardized and candidate parameters.
• Resources — full standards register