People regularly ask what's the cost of post-quantum packets. A classical TLS 1.3 handshake is four to six kilobytes on the wire. The same connection with hybrid ML-KEM key exchange and ML-DSA certificate signatures is fifteen to twenty. That difference affects TCP, QUIC, and IP fragmentation, and it changes how to plan capacity, timeouts, and middlebox tolerance before hybrid PQC reaches production.
The numbers have remained scattered across NIST specifications, engineering blogs, and academic papers. This post offers a single place to help move the discussion along for those who need the reference. It also comes with a calculator for anyone who wants to see what a specific stack changes on the wire.
Raw sizes, one table
Key exchange contributions. The on-wire total is the client key share plus the server key share, which is what gets added to the TLS 1.3 handshake when the KEM is selected.
| Key exchange | Client key share | Server key share | On-wire total |
|---|---|---|---|
| X25519 | 32 | 32 | 64 |
| P-256 ECDHE (uncompressed) | 65 | 65 | 130 |
| ML-KEM-512 | 800 | 768 | 1,568 |
| ML-KEM-768 | 1,184 | 1,088 | 2,272 |
| ML-KEM-1024 | 1,568 | 1,568 | 3,136 |
| X25519MLKEM768 (hybrid) | 1,216 | 1,120 | 2,336 |
| P256MLKEM768 (hybrid) | 1,249 | 1,153 | 2,402 |
Signature contributions. Each signature in a TLS certificate chain contributes one public key plus one signature. A typical chain has a leaf signature, an intermediate signature, and SCT signatures from Certificate Transparency logs. The root is anchored locally and does not travel on the wire. Classical public-key sizes below are given as SubjectPublicKeyInfo DER, which is what actually ships inside an X.509 certificate; PQC raw keys are already the on-wire form.
| Signature scheme | Public key | Signature | Per chain entry |
|---|---|---|---|
| Ed25519 | 44 | 64 | 108 |
| ECDSA-P256 | 91 | 72 | 163 |
| RSA-2048 | 294 | 256 | 550 |
| ML-DSA-44 | 1,312 | 2,420 | 3,732 |
| ML-DSA-65 | 1,952 | 3,309 | 5,261 |
| ML-DSA-87 | 2,592 | 4,627 | 7,219 |
| Falcon-512 (FN-DSA) | 897 | 666 avg | 1,563 avg |
| Falcon-1024 | 1,793 | 1,280 avg | 3,073 avg |
| SLH-DSA-128s | 32 | 7,856 | 7,888 |
| SLH-DSA-128f | 32 | 17,088 | 17,120 |
| SLH-DSA-192f | 48 | 35,664 | 35,712 |
All sizes in bytes. Sources: NIST FIPS 203, 204, 205, and draft FIPS 206 for FN-DSA; RFC 5280 for the X.509 SPKI framing of classical keys. Falcon signatures are variable-length per signature; the value shown is the published average. These values match the constants the handshake size calculator uses.
What a full handshake looks like
A classical TLS 1.3 handshake with X25519 for key exchange and an ECDSA-P256 leaf signed through an RSA-2048 intermediate runs about 4 to 6 KB on the wire. The largest single contributor is the certificate chain at 2 to 3 KB.
Switch to X25519MLKEM768 for key exchange and the handshake gains about 2.3 KB. The ClientHello key_share extension grows from 32 bytes to 1,216 bytes. The server key_share response grows from 32 bytes to 1,120 bytes. Key exchange overhead is real, but it is the smaller of the two PQC contributions.
Switch the certificate chain to ML-DSA-65 signatures and the numbers move differently. A two-signature chain (leaf plus intermediate) carries about 10 KB of authentication data where classical carried about 150 bytes. Add SCTs from Certificate Transparency, each carrying its own signature, and the total handshake size reaches 17 to 20 KB.
Hash-based signatures are larger still. One SLH-DSA-192f signature is 35,664 bytes on its own. A single SLH-DSA signature in a chain exceeds the entire pre-PQC handshake size.
The network boundaries the new sizes cross
TCP initial congestion window under RFC 6928 is 10 maximum segment sizes, or approximately 14.6 KB on a standard 1460-byte MSS. A classical handshake fits inside IW10 on the first flight. A hybrid-plus-ML-DSA handshake often does not, and the server waits a full round trip for the client acknowledgment before sending the remainder. That extra RTT is the performance cost most teams do not see until they deploy.
QUIC enforces a 3x amplification limit before client address validation. A server Initial flight larger than three times the client Initial (3,600 bytes minimum) is split across multiple sends, and the server cannot release the full flight until validation completes. ML-DSA-sized certificate chains cross this trivially.
Ethernet MTU remains 1,500 bytes. Every kilobyte added to the handshake adds packet count and raises fragmentation risk at middleboxes that re-segment TLS. Some middleboxes drop TLS records larger than 16 KB outright.
DNSSEC over UDP at the typical 1,232-byte EDNS buffer cannot carry PQC signature material. A zone signed with ML-DSA forces TCP fallback or IP fragmentation on every lookup.
Plan with your own config
The raw tables are a reference. The interaction that matters is what happens when you pick a KEM, a signature scheme, a chain depth, and an SCT count together.
The pqprobe handshake size calculator takes those inputs and returns the full server-to-client flight size, the IW10 and IW20 headroom or overflow, the QUIC amplification check, and an estimated packet count at standard MSS.
What endpoints actually look like today
The sizes in the tables are ceilings under the assumption that every layer is PQC. Real deployments are mid-transition. Many sites have enabled hybrid key exchange while keeping classical certificate chains, which adds about 2.3 KB to the handshake without approaching the ML-DSA cost. Others have added ML-DSA certificates in private PKI while continuing to serve classical chains on public endpoints. Which combination of layers any given endpoint runs is something you can measure.
Repeated measurement across a fleet is a useful input to migration planning. It shows which endpoints have moved which layers, and how “supports PQC” and “negotiates PQC” differ in bytes for your specific stack. tshark, Zeek, internal probes, or a scanner like pqprobe will all give you handshake-contents data; the choice depends on what your team already runs.
Planning suggestions
Network teams benefit from measuring IW10 headroom before a hybrid rollout. A fleet that fits classical flights comfortably in one RTT may not fit hybrid flights, and the extra RTT compounds on every new connection that does not reuse an existing session. Knowing the per-endpoint number lets you budget for it ahead of time, or choose a configuration that stays inside the window.
Developers picking signature schemes for PQC workloads have a real tradeoff to make across the size column and the algorithm column. ML-DSA-44 is the floor for NIST compliance. Falcon offers smaller signatures at the cost of side-channel implementation complexity. SLH-DSA is conservative against future cryptanalysis but heavy on the wire. The right choice depends on session reuse patterns, middlebox behavior, and connection volume on the endpoint in question.
Hybrid PQC is a staging point on the way to pure PQC, and the byte counts are expected to grow from here. Measuring handshake size per endpoint starts the discussion whether the next migration step is a config change or something closer to a network redesign, and both are easier to plan with numbers in hand.
PQC migration is a performance optimization event as well as a cryptographic one. Sizing the handshake on each endpoint, before and after a change, gives a concrete number to plan against and a way to verify that the change delivered what the design assumed.