POST-QUANTUM TRANSPORT

Why post-quantum authentication becomes a transport problem before it becomes a cryptanalytic one.

Most discussions of post-quantum migration begin with security levels. In a deployed protocol, another constraint can bind first: how many bytes the server can place on the wire before the transport makes it wait.

The number is not cryptographic. It comes from congestion control, address validation, packet size and loss recovery. Once public keys and signatures become much larger, those transport rules become part of the algorithm decision.

The budget exists below TLS

RFC 6928 defines a TCP initial congestion window of up to ten segments. With a 1,460-byte maximum segment size, the familiar reference value is 14,600 bytes. An implementation can send that first window before it needs an acknowledgement that opens more capacity.

QUIC imposes a separate limit before the client address is validated. A server may send no more than three times the number of bytes it has received. A client Initial datagram must carry at least 1,200 bytes, so a minimal first datagram can initially authorize only about 3,600 bytes of server traffic. A larger ClientHello or an address-validation token changes the exact budget, but not the principle.

Neither rule was written for cryptographic migration. Both can determine whether a handshake completes in one flight or pauses for another network event.

Authentication is an aggregate

A TLS 1.3 server flight does not contain one isolated signature. It carries a certificate chain, a CertificateVerify signature over the transcript and the surrounding handshake structures. Depending on the PKI and deployment, it may also carry Certificate Transparency data and a stapled status response.

An illustrative chain budget sometimes counts five signature-sized objects and two public keys. With ECDSA P-256, five DER-encoded signatures near 70 bytes and two uncompressed public points of 65 bytes total roughly 480 bytes of raw cryptographic material. Certificate names, extensions, ASN.1 structure and other signed objects bring the transmitted chain into the kilobyte range.

The precise count is local. The useful observation is that a certificate system multiplies the size of a primitive by the number of places where that primitive appears.

The same count with ML-DSA

FIPS 204 fixes the encoded sizes of ML-DSA public keys and signatures:

Parameter set	Public key	Signature
ML-DSA-44	1,312 bytes	2,420 bytes
ML-DSA-65	1,952 bytes	3,309 bytes
ML-DSA-87	2,592 bytes	4,627 bytes

Apply the same illustrative count to ML-DSA-44:

5 x 2,420  = 12,100 bytes
2 x 1,312  =  2,624 bytes
              -------------
               14,724 bytes

The raw keys and signatures alone exceed the 14,600-byte TCP reference window. No allowance has yet been made for certificate encoding, names, extensions, transcript authentication or other handshake messages.

With ML-DSA-65, the same arithmetic produces 20,449 bytes before those structures. This is not a prediction of every certificate chain. It is a warning that chain shape, which once looked like administrative detail, can become the dominant transport variable.

Key establishment is not the largest term

ML-KEM-768 uses a 1,184-byte encapsulation key and a 1,088-byte ciphertext. Hybrid key establishment therefore adds meaningful traffic, but it usually appears once in each direction.

Authentication material can be repeated across a leaf certificate, intermediates and transcript signatures. The migration problem is not just that a post-quantum object is larger. It is that the protocol may carry several of them before application data begins.

Crossing a boundary costs a network event

Handshake growth does not translate smoothly into latency. If a server flight fits inside the available window, the client receives it as one transport episode. If it crosses the boundary, the remainder may wait for an acknowledgement, address validation or loss recovery.

Measurements published by Kampanakis and Childs-Klein illustrate the effect. In their stable, low-bandwidth scenarios, post-quantum material increased handshake time by about 32 percent. The increase in time to last byte fell below 15 percent once the connection transferred 50 KiB or more, and below 10 percent around 200 KiB.

This creates a deployment result that is easy to miss: short exchanges can pay the largest relative cost. A telemetry report, status poll or compact API request may carry little application data over a comparatively heavy authenticated connection. A large transfer amortizes the same handshake over many more bytes.

Loss makes the boundary sharper. More packets create more opportunities for retransmission, and a missing fragment can delay processing of the entire authenticated flight.

Compression reduces structure, not random-looking bytes

RFC 8879 certificate compression is useful because classical certificate chains contain repeated names, identifiers and encoding patterns. Those parts compress well.

Cryptographic public keys and signatures are designed to look close to random. They offer a compressor little recurring structure. As post-quantum objects become a larger fraction of the chain, compression removes proportionally less of the total.

Compression remains worth measuring. It is not a substitute for counting the keys and signatures that the protocol requires.

Where bytes can be removed

The effective mitigations act on protocol structure as well as primitive size:

• Reduce unnecessary chain depth. Removing an intermediate removes both its public key and the signature that authenticates it.
• Avoid retransmitting material the peer already has. Cached-certificate and cached-intermediate designs can move repeated objects out of the critical flight, provided cache state and failure behavior are explicit.
• Choose algorithms by position and lifetime. A leaf, intermediate and trust anchor are used at different frequencies and replaced on different schedules. They do not automatically need the same performance profile.
• Question the certificate construction. Designs based on compact references, delegated credentials or authenticated data structures can reduce repeated signature material, but they also change deployment and trust assumptions.
• Consider smaller signatures where the implementation can support them safely. FN-DSA, derived from Falcon and still being developed as FIPS 206, offers substantially smaller signatures and keys than ML-DSA. Its signing implementation is correspondingly more delicate.

SLH-DSA makes the opposite trade. Its conservative hash-based construction avoids lattice assumptions, but FIPS 205 signatures range from roughly 7.8 KiB to almost 50 KiB. That may be acceptable for firmware signed once and verified during installation. It changes the shape of an interactive handshake.

Constrained links make the budget visible

Fourteen kilobytes looks generous beside lower-layer limits. The minimum IPv6 link MTU is 1,280 bytes. An IEEE 802.15.4 frame is at most 127 bytes before higher-layer overhead. A single ML-DSA signature can therefore require fragmentation even before a certificate or protocol envelope is added.

Memory can bind before bandwidth. The verifier may need input buffers, decoded certificate structures, hashing state and algorithm workspace at the same time. A device that can receive a signature in fragments may still be unable to verify it without redesigning its data path.

What to measure before choosing

Published object sizes are inputs, not deployment results. A useful measurement begins with the actual protocol:

1. Capture a production handshake and measure each flight in bytes.
2. Count every public key, signature, status object and transparency object that is actually transmitted.
3. Substitute the encoded sizes of each candidate parameter set.
4. Measure completion time across representative latency, bandwidth and loss conditions.
5. Record failures from fixed buffers, middleboxes and constrained protocol stacks, not only timing averages.
6. Measure peak RAM and flash use on the target device.
7. Relate handshake bytes to the application bytes normally transferred on one connection.

The final item often changes the decision. An algorithm that is tolerable for a long-lived connection may be expensive for a fleet that opens a new connection for every small message.

The parameter set is only one part of the choice

Post-quantum authentication is a cryptographic requirement implemented inside a transport system. Its real cost is expressed in bytes, flights, fragments, buffers and recovery behavior.

The algorithm fixes the size of each object. The protocol and PKI decide how many objects are carried, when they are carried and whether the peer already has them.

A migration plan that chooses the primitive but inherits the message shape has made only half of the decision.

---

References

1. RFC 6928: Increasing TCP’s Initial Window
2. RFC 9000: QUIC, A UDP-Based Multiplexed and Secure Transport
3. RFC 8446: The Transport Layer Security Protocol Version 1.3
4. FIPS 204: Module-Lattice-Based Digital Signature Standard
5. FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard
6. FIPS 205: Stateless Hash-Based Digital Signature Standard
7. Kampanakis and Childs-Klein: The impact of data-heavy, post-quantum TLS 1.3 on real-world connections
8. RFC 8879: TLS Certificate Compression
9. NIST: Post-Quantum Cryptography Standardization