How big are post-quantum keys and signatures, and what do they break in practice?

As of November 7, 2026, the signatures and public keys inside one typical TLS handshake weigh 1,248 bytes with today's RSA/ECDSA mix — and would weigh 14,724 bytes if every one of them became ML-DSA-44, about 12 times more (Luke Valenta, Cloudflare, PKI Consortium PQC Conference, January 15, 2025). That byte bill, not the lattice math, is what strains fixed budgets like DNSSEC's ≈1,232-byte UDP ceiling (IETF draft, October 16, 2026) and kilobyte-scale firmware images (NSA CNSA 2.0: post-quantum-only firmware signing for national security systems by 2030). The public record still shows 0 RSA-2048 keys broken by a quantum computer and 0 breaches attributed to a quantum attack — both re-verified today. Rosetta Quantum publishes the byte arithmetic with a source next to every number, so a security team can budget the migration instead of fearing it.

How big are post-quantum keys and signatures, really?

Between roughly 2 and 120 times their classical counterparts, depending on the scheme — and the spread is the story. Per the standards finalized on August 13, 2024 and the size table Cloudflare presented at the PKI Consortium conference (January 15, 2025): an Ed25519 signature is 64 bytes and an RSA-2048 signature is 256 bytes; an ML-DSA-44 signature (FIPS 204) is 2,420 bytes with a 1,312-byte public key — about 38 times Ed25519; an SLH-DSA-128s signature (FIPS 205) is 7,856 bytes — about 123 times — and the faster 128f variant reaches 17,088 bytes; Falcon-512 is the compact outlier at 666 bytes per signature and 897 bytes per public key, but its standard, FIPS 206, had no published draft as of our November 1, 2026 scan. On the key-agreement side, hybrid ML-KEM-768 (FIPS 203) moves about 1,100 bytes per peer where X25519 moved 32 — an over-30x increase, in Google's own words (Chrome security blog, May 23, 2024).

What ML-KEM, ML-DSA and SLH-DSA are, and which one your browser already runs, is covered in its own piece in this series. This piece is about the next question: a size is meaningless in isolation — it only means something against the byte budget of the protocol that has to carry it. Three budgets dominate in practice: the TLS handshake, the DNSSEC response, and the firmware image. The totals, with a source per row:

How many signatures travel in one TLS handshake, and what do they cost?

Six signatures and two public keys, in Cloudflare's count for a typical page load (November 8, 2021): two in the certificate chain, one handshake signature, one OCSP staple and two SCTs — Google's 2024 count is five and two (Chrome security blog, May 23, 2024). Swap them all to ML-DSA-44 and the cryptographic payload of one handshake goes from 1,248 bytes to 14,724 bytes; a Falcon-512 + ML-DSA-44 mix lands at 7,293 bytes (Valenta, January 15, 2025). On over half of connections, classical signatures and keys already account for about 25% of all bytes transferred (same talk).

The cost of those extra bytes is not a guess — it was measured. Cloudflare's 2021 experiment injected dummy bytes into 964,499 live TLS connections over 24 days (blog, November 8, 2021): at roughly +17 KB — the all-Dilithium2 scenario of the day — the median handshake ran about 20% slower, with the tail worse; the response curve showed bumps near 10 KB and 30 KB that the authors read as clients or middleboxes that cannot handle those handshake sizes; at +35 KB the median was 40% slower. And the one post-quantum migration that did ship at scale confirms the sensitivity from the other side: hybrid ML-KEM adds about 1 KB per peer and cost a measured +4% median TLS handshake latency on Chrome desktop — an impact Google judged acceptable there but delayed on Android (May 23, 2024). That ≈1 KB increment now covers about 70% of browser-originated human traffic on Cloudflare's network (Cloudflare, September 29, 2026; measured in this series).

The asymmetry explains the deployment gap. Chromium's design principles, as quoted in the January 2025 talk, call adding about 7 KB to the handshake implausible «unless a cryptographically relevant quantum computer is tangibly imminent»; Google formally recommends against standardizing ML-DSA for the public Web PKI before trust-anchor agility exists (May 23, 2024). Consistent with that, our scan of November 1, 2026 found 0 post-quantum certificates in the production Web PKI — key agreement migrated first precisely because it was 1 KB, not 14. The mechanics and byte costs of that hybrid handshake will get their own piece in this series.

Why is DNSSEC the tightest byte budget on the internet?

Because a DNS answer is expected to fit in about 1,232 bytes of UDP payload — a practical ceiling the DNS community standardized around in 2020 — and no lattice signature standardized today fits it comfortably. The University of Waterloo study that measured this end to end (Goertzen and Stebila, arXiv:2211.14196, November 25, 2022) counted total bytes for a full DNSSEC lookup: 504 bytes with ECDSA P-256 and 1,081 with RSA-2048, against 3,112 with Falcon-512, 8,623 with Dilithium2 (the ML-DSA predecessor) and 26,073 with SPHINCS+-128s. Oversized answers truncate and retry over TCP, which the paper calls fragile at DNS scale — it notes a non-trivial number of name servers do not support TCP at all — and even the best post-quantum case ran about twice as slow as RSA or ECDSA across its simulated network conditions. Its verdict: Falcon-512 is «the most suitable option currently available» for DNSSEC.

Four years later, the standardization scoreboard is still at zero: no post-quantum algorithm has a DNSSEC algorithm code point. The current strategy document — an IETF Internet-Draft by Verisign Labs, Virginia Tech and NLnet Labs, dated October 16, 2026 — sketches two future tracks: a conservative one (ML-DSA wrapped in Merkle Tree Ladder mode, Falcon, or the hash-based XMSS/LMS) and a low-impact drop-in one built on signature schemes still under NIST's additional-signatures evaluation, such as MAYO and SNOVA. All of it is written in the future tense, and so will we: those registrations may come, the measurements will have to come first, and the fate of SIKE and Rainbow is the reminder of why nobody wants to hard-wire a young scheme into the DNS root.

Why is firmware signing the first hard deadline?

Because the NSA made it the earliest «exclusively use» date in CNSA 2.0 — post-quantum-only software and firmware signing for US national security systems by 2030, with support preferred since 2025 — ahead of networking equipment and years ahead of the 2033 browser/OS dates (NSA, CNSA 2.0 and its FAQ; v2.1 details as read in PostQuantum.com's analysis, consulted November 7, 2026 — the primary PDF is in the sources). The approved tools are the stateful hash-based schemes LMS and XMSS in single-tree form, standardized in NIST SP 800-208 (October 2020), with ML-DSA admitted once validated implementations exist; SLH-DSA is explicitly not approved for national security systems in the v2.1 reading, and multi-tree variants are excluded.

The logic is budget logic again, with the hardest constraints of all. A boot ROM verifier has kilobytes of code space, cannot be patched, and must verify every boot for the life of the device — 10 to 20 years for vehicles, industrial controllers and satellites. Signatures that live that long face the mirror image of the harvest-now-decrypt-later arithmetic covered earlier in this series: it is not the data that outlives the transition, it is the verifier burned into silicon. Hash-based signatures fit that niche because their security rests on hash functions alone — but they are stateful: sign twice with the same one-time key and security collapses, which is why key management, not byte count, is their operational price. What the software supply chain actually signs with today will get its own piece in this series.

What should a CISO do with these numbers?

First, split «post-quantum migration» into two projects with different physics. Key agreement is the cheap half: +1 KB per peer, a measured +4% median handshake cost, already live on about 70% of browser traffic through Cloudflare (September 29, 2026). Signatures are the expensive half: 0 post-quantum certificates in the Web PKI, DNSSEC at 0 code points, and a 12x byte bill waiting for whoever goes first. Budgets, owners and timelines should not be shared between the two.

Second, inventory where signatures flow before buying anything. A cryptographic inventory (CBOM) that lists every TLS chain, DNSSEC zone, code-signing pipeline and firmware image — and flags each path that crosses a fixed byte ceiling — turns this article's table into your migration map.

Third, buy agility, not algorithms. The per-niche winner is genuinely unsettled: Falcon waits on FIPS 206, the DNSSEC tracks are drafts, and the CNSA list has already changed between FAQ versions. The case for crypto-agility over algorithm-picking is this article in one sentence.

Fourth, put dates on the work. The clocks that bind are regulatory, not quantum: NIST deprecates RSA/ECC in 2030 and disallows them in 2035 (IR 8547, final October 27, 2026); the US executive order sets 2030/2031 for federal high-value assets; CNSA 2.0 sets 2030 for firmware. Rosetta's own Q-Day position (RQ-PRED-QDAY-001: floor 2031, window 2033–2039) is a sealed, refutable judgment — not a measurement — and it sits later than every one of those deadlines. The zeros above are real and they are good news; the deadlines are also real, and they arrive first.

PQC Board — status as of 2026-11-07

What we don't know

Where this article's numbers stop: (1) No all-post-quantum certificate chain has been measured in production at internet scale — the slowdown curve comes from a 2021 controlled experiment with dummy bytes, and no browser validates post-quantum certificates by default today. (2) The breakage thresholds near 10 KB and 30 KB were measured in 2021 and have not, to our knowledge, been publicly re-measured; today's middlebox failure rate is unknown. (3) Which algorithm DNSSEC will eventually register is open — 0 code points exist, FIPS 206 had no draft at our November 1 scan, and the MTL/MAYO/SNOVA tracks are experimental. (4) Real firmware verification budgets (ROM bytes, RAM, boot-time) are not published per vendor; the kilobyte framing comes from the constraints the standards themselves cite. (5) We read the CNSA 2.0 FAQ v2.1 specifics through a secondary analysis; any discrepancy resolves in favor of the NSA's primary document, linked below. (6) Whether proposals like Merkle Tree Certificates or trust-anchor negotiation will mature fast enough to avoid the naive 14.7 KB chain — Google's position against early ML-DSA standardization for the Web PKI dates to May 23, 2024 and could change.

Rosetta Quantum publishes verdicts with raw, reproducible data and dated sources. This is educational content — not a product claim, not vendor advice, not investment advice.