TLS 1.3 Handshake Size Calculator
Pick a KEM and signature scheme, or load a preset. The page computes two first flights: the client's ClientHello, which carries the KEM public key, and the server's reply (ServerHello, certificate chain, CertificateVerify, Finished). Each flight is compared to the thresholds that decide whether it clears in one round trip.
The status chips read the same way for both flights. IW10 (14,600 B) is the default TCP initial congestion window from RFC 6928: a flight that fits inside it arrives in one round trip. IW20 (29,200 B) is the larger initial window that modern stacks and CDNs commonly use. QUIC 3x (3,600 B) is the anti-amplification limit in RFC 9000 section 8.1: it caps the server at three times the bytes received from an unvalidated client, so it applies to the server flight only. The client flight shows a packet-span count instead. Each chip shows whether the configuration fits and by how many bytes.
All math runs in your browser from published FIPS 203, 204, 205, and draft 206 primitive sizes, plus Classic McEliece round-4 sizes. No network calls.
Parameters
Client-to-server first flight
The ClientHello carries the KEM public key. With an ephemeral key exchange the client generates a fresh key pair per connection and sends this key in full every time, with no caching. QUIC's 3x limit constrains the server, not the client, so it does not apply here.
| ClientHello key share | - |
|---|---|
| ClientHello flight total | - |
Server-to-client first flight
| ServerHello key share | - |
|---|---|
| Certificate chain | - |
| CertificateVerify signature | - |
| OCSP staple | - |
| Server flight total | - |
| Packets at 1,460 B MSS | - |
Per-certificate breakdown
What the thresholds mean
IW10 and IW20
TCP starts every connection with an initial congestion window. RFC 6928 fixed this at 10 segments (IW10 = 14,600 B at a 1,460 B MSS). Many modern stacks use an initial window of 20 segments (IW20 = 29,200 B). This limit applies to whichever side is sending a flight, so the calculator checks it against both the client's ClientHello and the server's reply. A flight that fits inside IW10 reaches the far side in one round trip. A flight that exceeds IW10 but fits IW20 depends on the stack. Exceeding IW20 guarantees at least one extra RTT before the ACK allows the window to grow.
QUIC 3x amplification limit
RFC 9000 section 8.1 caps the server at sending no more than three times the bytes it has received from an unverified client address. A typical client Initial packet is ~1,200 B, so the server can send about 3,600 B before it has to pause for address validation. A PQC certificate chain that blows past that limit stalls the handshake waiting for a client ACK. This limit constrains the server only, so it appears on the server flight and not the client flight. A large ClientHello actually raises the server's budget, since the cap is three times what the client already sent.
Client flight and Classic McEliece
For ML-KEM and elliptic-curve groups the ClientHello key share is about 1 KB or less, so the client flight clears in one or two packets and never approaches these limits. Classic McEliece inverts the usual KEM shape: the public key is 261 KB to 1.36 MB while the ciphertext is under 250 B. The public key rides in the ClientHello, so the client flight, not the server flight, is what overflows.
The Classic McEliece design argues that a public-key byte is cheaper than a ciphertext byte because a public key can be cached and broadcast, the way DNS records are. That argument assumes a reused key. TLS 1.3 ephemeral key exchange does the opposite: the client generates a fresh key pair for every connection and sends the whole public key in each ClientHello, with no caching. So a browser opening a McEliece connection pays the full 261 KB to 1.36 MB every time, which is why McEliece is rarely proposed for ephemeral TLS and why the client flight above dominates the result.
Chain depth and the root
TLS 1.3 servers send the leaf and intermediates. The root stays in the client trust store and is not on the wire. Even so, the root's signature scheme sets the sig field size of the deepest intermediate that is transmitted, which is why this calculator asks for a CA signature scheme.
Sources
- NIST FIPS 203 (ML-KEM), August 2024, Table 2 for public key and ciphertext sizes.
- NIST FIPS 204 (ML-DSA), August 2024, Table 1 for signature and public key sizes.
- NIST FIPS 205 (SLH-DSA), August 2024, Table 1 for each parameter set.
- NIST draft FIPS 206 (FN-DSA / Falcon). Signature size is variable. Published averages are used; real deployments see ±10% per signature.
- Classic McEliece: guide for implementors (23 October 2022), Table 1, for public key and ciphertext sizes.
- BSI TR-02102-1 for the recommended Classic McEliece parameter sets (mceliece460896, 6688128, 8192128).
- RFC 5280 for X.509 / SubjectPublicKeyInfo DER framing of classical keys.
- RFC 6928 (IW10), RFC 9000 section 8.1 (QUIC amplification), RFC 6962 (SCT sizes).
- IETF
draft-ietf-tls-hybrid-designfor hybrid KEM share concatenation.
Numbers are estimates of the TLS record-layer bytes before encryption framing overhead. Real captures vary by a few hundred bytes depending on extension choice, OCSP response contents, cert subject length, and whether SCTs are stapled vs. embedded. Use this as a sizing tool, not a packet-level simulator.