Chapter 36 — Quantum and post-quantum security: performance and scale
Lesson map
Lesson 36 published. Map, example, EX071.
flowchart TD
N0["Learning outcomes"]
N1["36.1 Byte budgets"]
N2["36.2 Practical activity — Lab B"]
N3["36.3 Computation"]
N4["36.4 Measurement"]
N5["Engineering note"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX071"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["36.1 Byte budgets"]
N2["36.2 Practical activity — Lab B"]
N3["36.3 Computation"]
N4["36.4 Measurement"]
N5["Engineering note"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX071"]
[Learning outcomes]
|
v
[36.1 Byte budgets]
|
v
[36.2 Practical activity — Lab B]
|
v
[36.3 Computation]
|
v
[36.4 Measurement]
|
v
[Engineering note]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX071]
Learning outcomes
You will (1) budget bytes and computation for post-quantum handshakes; (2) measure latency and throughput; (3) assess certificate-chain size effects; and (4) scale signing and verification services. It builds on Chapters 8, 11 and 29.
36.1 Byte budgets
ML-KEM adds about 2.3 kB to a hybrid TLS handshake (1,216-byte client share plus 1,120-byte server share). Post-quantum certificates add far more: each ML-DSA-44 certificate carries a 1,312-byte key and a 2,420-byte signature; a chain plus CertificateVerify and Certificate Transparency signatures can exceed 15 kB — beyond TCP's initial congestion window in many configurations, costing an extra round trip.
Key exchange fits in two TCP segments, while a post-quantum certificate chain may need an extra round trip on its own. That is why BPA migrates key exchange first and treats certificates as a separate project.
36.2 Practical activity — Lab B
# Lab B (ch 36): bytes of authentication in a TLS handshake for different signature choices.
# Sizes in bytes: (public key, signature). ML-DSA from FIPS 204; SLH-DSA-128s from FIPS 205.
algs = {"ECDSA P-256": (65, 72), "RSA-2048": (270, 256), "ML-DSA-44": (1312, 2420),
"ML-DSA-65": (1952, 3309), "SLH-DSA-SHA2-128s": (32, 7856)}
def chain_bytes(alg, depth=2, scts=2):
pk, sig = algs[alg]
certs = depth * (pk + sig + 400) # leaf + intermediate: key + CA signature + ~400 B fields
return certs + sig + scts * sig # + CertificateVerify + embedded SCT signatures
for a in algs:
print(f"{a:20s} ~{chain_bytes(a):6d} bytes of certificates and signatures")
Expected output:
ECDSA P-256 ~ 1290 bytes of certificates and signatures
RSA-2048 ~ 2620 bytes of certificates and signatures
ML-DSA-44 ~ 15524 bytes of certificates and signatures
ML-DSA-65 ~ 21249 bytes of certificates and signatures
SLH-DSA-SHA2-128s ~ 40144 bytes of certificates and signatures
The ~400-byte per-certificate overhead and the two embedded SCT signatures are simplifying assumptions; real sizes vary. The result explains why authentication migration on the public web is harder than key exchange and why proposals to reduce chain size (such as abridged or merkle-tree certificates) are active research topics.
Reading the output, an ML-DSA-44 chain is about twelve times the size of the ECDSA one, and the SLH-DSA small variant is about thirty times larger. Rerun with scts=0 to see how much the transparency signatures contribute.
36.3 Computation
ML-KEM operations are fast — often faster than X25519 on servers with vector instructions. ML-DSA signing and verification are fast; SLH-DSA signing is slow (milliseconds to seconds depending on variant). Server capacity planning therefore focuses on bandwidth and signing services rather than KEM CPU.
For BPA, this shifts planning toward bandwidth on vessel satellite links and toward the throughput of the central signing service. SLH-DSA's slow signing is acceptable for an offline root that signs rarely, but not for signing thousands of documents an hour.
36.4 Measurement
Measure handshake latency percentiles (p50, p95, p99) by client type and network path before and after; throughput of signing services; HSM operations per second for new algorithms. Report distributions, not averages.
Averages hide the tail, where the users with poor links sit; a p99 increase of a few milliseconds may hide a few connections that time out entirely. BPA records latency by client type and path because vessels on satellite links behave very differently from office browsers. Measurements are taken for a week before and after each change so that normal daily variation does not mislead the comparison.
36.5 Worked example
BPA measures edge handshakes: p50 latency +0.4 ms, p99 +3 ms after enabling X25519MLKEM768 (synthetic); within budget. A test of an ML-DSA-65 chain on a satellite link to a vessel shows an extra round trip (+600 ms) — so vessel connections keep classical certificates longer and get session resumption tuned.
The edge result shows ML-KEM's cost is small on terrestrial links. The vessel result shows that the large chain, not the key exchange, causes the extra round trip, as Lab B predicted: over 15 kB of authentication data exceeds the initial congestion window. Session resumption avoids sending the chain again on repeat connections.
36.6 Common errors and limits
- Benchmarking only CPU.
- Averages instead of tail latency.
- Ignoring congestion-window effects of large chains.
CPU benchmarks show ML-KEM as faster than X25519 yet miss the bandwidth costs that dominate on slow links. Averages hide the vessels' slow connections in the p99 tail. Large chains that exceed the congestion window add a full round trip, which on a 600-millisecond satellite link costs more than all the computation combined. BPA's plan measures each device class and network path separately for exactly this reason.
Engineering note
Capacity planning should include the people who will read the numbers. Express results as changes in user-visible latency at the 99th percentile per path and as bytes per connection for the network team, not only as operations per second. A two-millisecond median change is usually invisible, while a whole extra round trip on a high-latency vessel link is not; presenting both side by side lets stakeholders accept the cheap change and plan around the expensive one.
Exercises
- EX071 — Chain budget. Using Lab B, find the depth-1 (leaf only) size for ML-DSA-44 with no SCTs. Rubric: 3 = correct value and method.
- EX072 — Measurement plan. Write a latency measurement plan for the vessel link. Rubric: 3 = percentiles, paths, before/after, sample size.
Synthesis
PQC performance is mostly about bytes: key exchange adds kilobytes, certificates add many more; measure tails and paths, and plan signing capacity.
Continue studying — chapter 36 of 50
← Chapter 35 (draft) · Course chapter index · Chapter 37 (draft) →