PQC Size Impact Calculator
The maths of post-quantum cryptography works. What breaks is the size. Pick a key exchange and a signature algorithm and this gives you the bytes — per handshake, per certificate, per chain — and tells you whether the result still fits your path MTU and the TCP initial congestion window. Everything runs in your browser; nothing is sent anywhere.
This is what harvest-now-decrypt-later attacks. It migrates first.
A separate decision: a signature is verified at the moment it is used, so this is not urgent — it is only expensive.
Leaf plus intermediates. The root is normally in the trust store and not on the wire. 1–10.
The real one on the path, not the interface setting. 576–9216.
Everything that is not the key or the signature: names, validity, serial, extensions, SCTs, DER framing. This is an estimate, and the one number here that does not come from a FIPS table — measure yours with openssl x509 -in cert.pem -outform der | wc -c and put it in.
Key exchange — on the wire
Key exchange is the survivable half. Even the hybrid stays inside one packet on a normal Ethernet path and costs no extra round trip in TLS 1.3.
Authentication — per certificate, then per chain
This is the part people underestimate: the cost is paid per link of the chain, not once. Add one intermediate and you add the whole per-certificate figure again.
Server first flight
Exceeds · TCP initial window at MTU 1500
RFC 6928 allows 10 segments before the first ACK — 14,600 B at this MSS. The flight is 7,042 B over, so the server stalls mid-handshake and every new connection pays an extra round trip — 100 ms on a 100 ms path, and no profiler will attribute it to cryptography.
Exceeds · The canonical ~14.6 KB figure
The number usually quoted for IW10 assumes a 1500 B MTU: about 14,600 B. This flight is 21,642 B. It is shown apart from the box on the left because that one uses YOUR MTU, and a 1400 B path has a smaller window than the figure everyone repeats.
Exceeds · Single datagram at MTU 1500
For anything UDP-borne — IKEv2, DTLS, QUIC, DNSSEC — one datagram carries 1,472 B after the IPv4 and UDP headers. This does not fit. IKEv2 needs RFC 7383 fragmentation to carry it at all, and a path with a PMTU discovery black hole fails in a way that looks like anything except a cryptography change.
Exceeds · QUIC anti-amplification
A QUIC server may not send more than 3x what it received from an unvalidated client address. With a minimum 1,200 B client Initial that is 3,600 B. This flight does not, so the server must wait for the client to send more before it can finish — extra round trips on every new connection.
Everything above is computed in your browser from the FIPS 203 / 204 / 205 parameter tables. No request is made and nothing you type is sent anywhere.
Why the chain is the problem, not the handshake
Key exchange is the half everybody talks about, and it is the half that is fine. An X25519MLKEM768 client key share is about 1,216 bytes against 32 — a 38-fold increase that still fits in one packet on an ordinary Ethernet path and costs no extra round trip in TLS 1.3. That is why it is what Chrome and Cloudflare actually ship today, and why enabling it is a configuration change rather than a project.
Authentication is where the bytes land. A certificate carries a public key and a signature, and a chain carries several certificates — so moving to ML-DSA-65 costs roughly 5.3 KB for every link in the chain, not once. A three-certificate chain that sat comfortably under 2 KB lands at 15–16 KB. That is the number people do not see coming, which is why the calculator above prints the per-certificate figure next to the total.
The two thresholds the bytes run into
RFC 6928 lets a server send ten segments before it must wait for an ACK — about 14,600 bytes on a 1500-byte path, and visibly less on a 1400-byte one, which is why the calculator computes the window from your MTU rather than quoting the familiar figure. Cross it and every new connection pays an extra round trip in the middle of the handshake: 100 ms on a 100 ms path, attributed to nothing that a profiler will ever point at cryptography.
The MTU itself bites anything that is not inside a TCP stream. IKEv2 needs RFC 7383 fragmentation to carry post-quantum payloads at all; DTLS, QUIC and DNSSEC meet the same wall. QUIC adds its own: a server may not send more than three times what an unvalidated client sent it, so a large certificate flight simply cannot go out in the first exchange. Before enabling post-quantum certificates on a VPN or any UDP-borne protocol, measure the real path MTU — assuming 1500 is how this becomes an outage instead of a capacity note.
The SLH-DSA trap
SLH-DSA has s and f variants — small signature and fast signing — and the gap between them is wider than the gap between some entire schemes. SHA2-128s is 7,856 bytes; SHA2-256f is 49,856. The “SLH-DSA is 7 to 30 KB” range that circulates describes the s variants only, so quoting it without naming the variant understates the worst case by a factor of six. Every figure in this tool is the standardised FIPS 203 / 204 / 205 parameter value, not the round-3 submission value — those differ, and are the usual source of a stale number in a capacity plan.
What this does not prove
- It gives you a size, not a verdict on your network. A calculator cannot tell you whether a middlebox, a load balancer or an old TLS stack on the path will accept the larger ClientHello or the larger certificate message. Several reject them, and they fail in ways that look like anything except a cryptography change. Test the real path.
- The X.509 overhead is an estimate, and it is yours to measure. It is the only number here that does not come from a FIPS table. A certificate with three SCTs and a long SAN list is considerably bigger than the default. Measure with
openssl x509 -in cert.pem -outform der | wc -cand subtract your key and signature. - The MTU is whatever you typed. It is not probed and it cannot be: a browser cannot measure a path MTU. If you entered the interface setting rather than the real path value, the verdicts above are confident and wrong.
- Fitting the window is not the same as being fast. Signing and verification cost CPU too, and SLH-DSA in particular is slow to sign. Size is the constraint that surprises people; it is not the only one.
- It says nothing about whether you should migrate. Key exchange is urgent because recorded traffic can be decrypted later; signatures are not, because a signature is verified at the moment it is used. The calculator prices both and recommends neither.
Where to go next
The numbers in this tool, and the reasoning behind which of them matter, come from the PQC Fundamentals skill — FIPS 203, 204 and 205, why hybrids are what actually deploy, and the CNSA 2.0 dates that force the question for US public sector. To turn a size into a plan for a specific estate, the PQC Readiness Assessor agent inventories where the cryptography actually lives and sequences the migration. And because every verdict above depends on an MTU you supplied rather than one that was measured, run path-mtu-analyzer on the paths that matter first — that is the cross-check that turns this from an interesting number into an operational one.