The hard part of migrating TLS to post-quantum signatures is not swapping an algorithm. It is that the new signatures and keys are large, and a great deal of networking software was quietly built on the assumption that they would stay small. A full certificate chain that fit comfortably in a single network packet with RSA can balloon past buffer limits, trip fragmentation, and break clients that never anticipated a handshake of that size. The cryptography is sound. The byte counts are the problem.
ML-DSA, the lattice signature scheme standardized as FIPS 204, is the practical default for post-quantum signing. Its security is well regarded and its performance is good. But its public keys and signatures are an order of magnitude larger than the classical signatures they replace, and in a TLS handshake those bytes multiply. A chain carries several signatures and several public keys, and every one of them grows at once.
This post works through the actual byte sizes, shows where they land you against real network limits, and covers the mitigations that keep post-quantum TLS from becoming slower and more fragile than the connections it replaces.
Apple SC-081: Renewal Multiplier by Phase
Per-certificate annual renewals as maximum lifespan decreases
Manual feasible
1-2 renewals/year per cert
Automation required
4-8 renewals/year per cert
The Raw Numbers
Start with the sizes, because every downstream problem follows from them. The classical algorithms produce small public keys and signatures. ML-DSA does not.
| Algorithm | Public Key | Signature |
|---|---|---|
| RSA-2048 | 272 bytes | 256 bytes |
| RSA-3072 | 398 bytes | 384 bytes |
| ECDSA P-256 | 64 bytes | 64-72 bytes |
| ECDSA P-384 | 96 bytes | 96-104 bytes |
| 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 |
An ECDSA P-256 signature is 72 bytes. The equivalent-tier ML-DSA-65 signature is 3,309 bytes, roughly forty-six times larger. The public key grows from 64 bytes to 1,952 bytes, roughly thirty times larger. These are not rounding differences. They change which network assumptions still hold.
The number that actually matters is not one signature but the whole chain, because a TLS handshake transmits the end-entity certificate, one or more intermediate certificates, and the signatures binding them together.
How the Chain Multiplies the Problem
A TLS server does not send one signature. It sends a certificate chain, and in the handshake the server also produces a signature proving possession of its private key. Count the post-quantum-sized objects that travel in a single handshake:
- The end-entity certificate, which contains the server’s public key and is itself signed by an intermediate.
- One or two intermediate certificates, each containing a public key and each signed by the authority above it.
- The handshake signature, where the server signs the transcript to authenticate itself.
Each certificate contributes both a public key and the signature over it, and the handshake adds one more signature. With classical algorithms the whole bundle is a few kilobytes at most. Replace every key and signature with ML-DSA-65 and the arithmetic changes sharply.
| Chain Component | Classical (ECDSA P-256) | Post-Quantum (ML-DSA-65) |
|---|---|---|
| End-entity: key + signature over it | ~136 bytes | ~5,261 bytes |
| Intermediate 1: key + signature over it | ~136 bytes | ~5,261 bytes |
| Intermediate 2: key + signature over it | ~136 bytes | ~5,261 bytes |
| Handshake signature (CertificateVerify) | ~72 bytes | ~3,309 bytes |
| Approximate authentication bytes | ~480 bytes | ~19,000 bytes |
The authentication material in the handshake grows from under half a kilobyte to roughly nineteen kilobytes. Certificate framing and other fields add more. That jump from hundreds of bytes to tens of kilobytes is the whole problem in one line, and it lands directly on the packet-level limits that networks were tuned around.
Where the Bytes Hit the Wire
Large handshakes are not merely slower to transmit. They collide with fixed limits that were never meant to flex, and each collision breaks something different.
MTU and Fragmentation
A typical Ethernet path carries a maximum transmission unit of 1,500 bytes, leaving roughly 1,460 bytes of payload per TCP segment after headers. A classical handshake fits in one or two segments. A nineteen-kilobyte authentication bundle needs well over a dozen segments, and every one of them must arrive for the handshake to complete. On a clean network this is extra latency. On a lossy or high-latency path it is amplified latency, because a single lost segment stalls the whole handshake until it is retransmitted. The handshake that used to complete in one round trip now depends on many packets surviving the trip.
Buffer Assumptions
A surprising amount of software hardcoded the belief that a certificate message would be small. Load balancers, embedded TLS stacks, older middleboxes, and custom protocol parsers sometimes allocate a fixed buffer for the certificate or handshake message. A buffer sized generously for RSA at a few kilobytes can be overrun by a post-quantum chain, and the failure mode is not a clean error. It is a dropped connection, a truncated read, or a parser that rejects the handshake as malformed. These bugs do not appear in testing against classical certificates; they appear the first time a real post-quantum chain arrives.
QUIC Amplification Limits
QUIC includes an anti-amplification rule to stop the protocol from being used as a reflection weapon: before a client’s address is validated, a server may send no more than three times the bytes it has received. A client’s initial packet is small, so the server’s early allowance is only a few kilobytes. A post-quantum certificate chain does not fit in that budget. The server cannot send the full chain until the client’s address is validated, which costs an extra round trip precisely during connection setup, the moment latency is most visible to the user. The larger the chain, the more certain the extra trip.
Embedded and Constrained Devices
The devices least able to absorb the growth are the ones that most need long-lived trust. A microcontroller with tens of kilobytes of RAM may not have room to buffer a full post-quantum chain, let alone verify it within its memory budget. Constrained devices often cannot simply be upgraded, which means the size problem becomes a hardware problem for exactly the long-lived field equipment where post-quantum trust matters most.
Mitigations That Make Post-Quantum TLS Practical
The size problem is real but not unsolved. Several mitigations reduce the bytes on the wire or the number of them that must be transmitted, and they are strongest in combination.
Certificate Compression (RFC 8879)
TLS certificate compression lets client and server negotiate a compression algorithm and send the certificate chain compressed. Certificates contain structured, repetitive data, so compression helps, though lattice signatures are closer to random bytes than classical ones and compress less well than certificate metadata does. Compression is the lowest-effort mitigation because it is already a standardized TLS extension; the main action is ensuring both ends support it and have it enabled. It does not eliminate the problem, but it meaningfully reduces the transmitted size of the chain.
Intermediate Suppression
Many TLS clients already hold the intermediate certificates they need, either cached from prior connections or distributed out of band. If the client can indicate which intermediates it already has, the server can omit them from the handshake and send only the end-entity certificate. Removing even one post-quantum intermediate from the wire saves roughly five kilobytes in the ML-DSA-65 example. Suppressing the intermediates is one of the highest-leverage reductions available, because the intermediates are pure overhead to a client that already trusts them.
Merkle Tree Certificates
A more structural approach replaces per-certificate signatures with membership proofs in a Merkle tree. Instead of each certificate carrying its own large signature, certificates are leaves in a tree whose root is published and trusted, and a certificate proves its validity with a compact inclusion path rather than a full signature. This amortizes the signature cost across many certificates and shrinks what each connection must carry. It is a larger ecosystem change than compression or suppression, but it attacks the root cause: the per-certificate signature is what balloons, and a membership proof is far smaller than a lattice signature.
Algorithm and Deployment Choices
Not every certificate needs the largest parameter set, and not every connection needs post-quantum authentication today. Hybrid and transitional deployments can confine the largest signatures to the chains that truly require long-lived post-quantum trust, while shorter-lived or lower-risk connections use smaller options during the transition. Matching the parameter set and the migration timing to the actual trust lifetime keeps the biggest signatures out of the handshakes that cannot absorb them.
Designing for the Size Instead of Being Surprised by It
The organizations that struggle with post-quantum TLS are the ones that treat it as a drop-in algorithm change and discover the size problem in production, when a load balancer truncates a chain or a QUIC connection quietly pays an extra round trip. The organizations that migrate cleanly treat the byte sizes as a design input from the start.
The practical sequence is to measure your real chains at the target parameter set, test them against your actual load balancers, middleboxes, and constrained clients before production, enable certificate compression and intermediate suppression wherever both ends support them, and reserve the largest signatures for the chains whose trust lifetime genuinely demands them. The algorithm is the easy decision. The handshake that still fits on the wire is the engineering.
FAQ
Q: How much larger are ML-DSA signatures than classical ones? Roughly ten to fifty times, depending on the parameter set and the classical algorithm you compare against. An ECDSA P-256 signature is about 72 bytes, while an ML-DSA-65 signature is 3,309 bytes and its public key is 1,952 bytes versus 64 bytes for P-256. The growth applies to both the key and the signature, so a full chain grows on every component at once.
Q: Why does the certificate chain make this worse than a single signature? A TLS handshake sends the end-entity certificate, one or more intermediates, and a handshake signature, and each certificate carries both a public key and the signature over it. Every one of those objects grows with ML-DSA, so a chain that was a few hundred bytes of authentication material classically becomes roughly nineteen kilobytes, which is what collides with packet and buffer limits.
Q: What actually breaks when the handshake gets large? Several things. Chains exceed the MTU and require many packets, so a single lost segment stalls the handshake. Fixed-size buffers in load balancers, middleboxes, and embedded stacks can overrun and drop or reject the connection. QUIC’s anti-amplification limit forces an extra round trip during setup. Constrained devices may lack the memory to buffer or verify the chain at all.
Q: Does certificate compression solve the problem? It helps but does not solve it. Certificate compression (RFC 8879) is a standardized TLS extension that reduces the transmitted size of the chain, but lattice signatures resemble random data and compress less well than certificate metadata. Compression is best combined with intermediate suppression and, longer term, structural approaches like Merkle tree certificates.
Q: What is a Merkle tree certificate and why does it help? It replaces each certificate’s large individual signature with a compact membership proof in a Merkle tree whose root is trusted. Instead of carrying a full lattice signature, a certificate proves it belongs to the published tree with a short inclusion path. This attacks the root cause, since the per-certificate signature is the component that balloons, and a membership proof is much smaller.
About QCecuring
QCecuring helps enterprises migrate TLS to post-quantum signatures without discovering the size problem in production. Our platform measures your real certificate chains at target parameter sets, flags load balancers, middleboxes, and constrained clients that will break on larger handshakes, and guides compression, intermediate suppression, and parameter choices so your post-quantum handshakes still fit on the wire.
Test your certificate chains for post-quantum size impact
Tags: Post-Quantum Cryptography, PQC, SSL/TLS, ML-DSA, FIPS 204, Certificate Chain, Handshake Size, MTU, Fragmentation, QUIC, Certificate Compression, RFC 8879, Merkle Tree Certificates, Embedded Devices, Crypto-Agility