Carr Digital

Handshake budget

Post-quantum certificate chains are large enough to overrun TCP's initial congestion window, which costs a round trip on every full handshake. The usual advice is to keep the chain under about 10KB. That number is stated on the wrong quantity: the window constrains the whole server flight, and the certificate budget it leaves you moves by more than two kilobytes depending on which algorithm signs. This works out the real number.

Every figure below comes from measured handshakes, not estimates. Method and limits are at the bottom.

Calculator

This key signs the handshake, so it sets your CertificateVerify cost.

Signs the leaf and the intermediates. Affects certificate size only.

Roots are not transmitted, so they cost nothing on the wire.

Measured growth: about 19.33 bytes each.

Sets how many bytes fit in the initial window.

Byte breakdown of the server's first flight

How this is calculated

The server's first flight is everything it sends before it can hear back from the client: ServerHello, EncryptedExtensions, the Certificate message, CertificateVerify, and Finished. Measured across seven chain shapes, the non-certificate part is a constant 1256 bytes, so the only piece that moves with your algorithm choice is the handshake signature.

Certificate sizes are composed from three separately measured quantities: structural X.509 overhead, the public key, and the issuer's signature. That model reproduces every measured chain to within 9 bytes. Where your configuration matches a chain that was actually minted and captured, the calculator uses the measured figure directly and says so.

The congestion window check uses an initial window of 10 segments (RFC 6928). Segment counts are computed from measured byte totals, not read off a capture: the capture host has segmentation offload enabled, so a segment count taken from it would be an artifact rather than a property of the handshake.

What this does not tell you. It says nothing about latency. An extra round trip costs whatever your RTT is, and that was not measured here. It also assumes no TLS certificate compression, which is the right default: compression recovers a near-constant 240 bytes on this corpus regardless of chain size, so it does not change any verdict. SLH-DSA's CertificateVerify is computed from its signature size rather than measured, because the corpus only ever used it to sign a root.

Data: pqc-cert-matrix, DOI 10.5281/zenodo.21749600. Measured 2026-07-31 to 2026-08-01, OpenSSL 3.5.5, single host. Background: How much certificate can you afford? and Hybrid certificates, weighed.