Chapter 30 — Laboratory II
Lesson map
Lesson 30 published. Map, example, EX059.
flowchart TD
N0["Learning outcomes"]
N1["30.1 Why bytes matter for authentication"]
N2["30.2 Practical activity — Lab B"]
N3["30.3 Network effects"]
N4["30.4 Reporting"]
N5["30.7 Trimming the chain"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX059"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["30.1 Why bytes matter for authentication"]
N2["30.2 Practical activity — Lab B"]
N3["30.3 Network effects"]
N4["30.4 Reporting"]
N5["30.7 Trimming the chain"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX059"]
[Learning outcomes]
|
v
[30.1 Why bytes matter for authentication]
|
v
[30.2 Practical activity — Lab B]
|
v
[30.3 Network effects]
|
v
[30.4 Reporting]
|
v
[30.7 Trimming the chain]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX059]
Learning outcomes
You will (1) estimate handshake bytes for post-quantum certificate chains; (2) compare signature options quantitatively; (3) relate byte counts to network behaviour; and (4) report results with assumptions.
30.1 Why bytes matter for authentication
Hybrid key exchange adds about 2.3 kB per TLS handshake. Post-quantum authentication adds more: each certificate contains a public key and a signature, and the handshake includes a CertificateVerify signature and often signed certificate timestamps (SCTs). With ML-DSA every one of these grows.
Because a chain carries several of these elements, the growth multiplies rather than adds. A server might send two certificates, each with an ML-DSA key and signature, plus the CertificateVerify and two SCT signatures, so the authentication bytes can exceed the key-exchange bytes several times over. That is why HCU treats certificates as a separate migration decision from key exchange.
30.2 Practical activity — Lab B
# Lab B (ch 30): 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 model assumes a two-certificate chain, ~400 bytes of other fields per certificate and two SCTs; real chains vary. ML-DSA-44 raises authentication bytes roughly twelve-fold over ECDSA; SLH-DSA-128s more than thirty-fold.
The counting is deliberately simple: each certificate carries its own public key and a signature from the issuer, and the handshake adds one CertificateVerify signature plus one signature per SCT. SLH-DSA has a tiny public key but very large signatures, so it is hit hardest by the number of signatures in the chain. Changing the depth or SCT count in the lab shows which lever matters most for each scheme.
30.3 Network effects
TCP's initial congestion window commonly allows about ten segments (~14 kB) before waiting for acknowledgement. A server flight exceeding it costs an extra round trip — small on a data-centre link, noticeable on a 150-ms mobile or satellite path. Certificate compression (RFC 8879) helps little with high-entropy keys and signatures. Engineering responses include shorter chains, fewer SCTs and careful choice of parameter sets.
For HCU's mobile users, that extra round trip on cellular links is the main concern.
30.4 Reporting
Report results with assumptions: chain depth, field sizes, number of SCTs, initial window. State that the model estimates bytes, not latency, and that latency needs measurement.
Comparisons are valid only when every scheme is run with the same assumptions. HCU attaches the Lab B parameters to its report on certificate options, so a reviewer can change one assumption, such as the number of SCTs, and see the effect. Measured latency from the emulated links is reported separately from the byte estimate.
30.5 Worked example
HCU's mobile app talks to the gateway over cellular links with 80-ms round trips. Lab B suggests ~15.5 kB of authentication with ML-DSA-44, slightly above a typical initial window. HCU's plan: keep ECDSA certificates while monitoring ecosystem support, test ML-DSA-44 chains in the lab with one SCT, and measure latency on emulated cellular links before any change.
The decision is to be revisited when browsers and client libraries support ML-DSA certificates widely. Members on slow links would notice the delay first, so the emulated tests use the worst branch and mobile conditions HCU has recorded rather than the average.
30.6 Common errors and limits
- Equating bytes with latency.
- Ignoring SCTs and intermediate certificates.
- Comparing signature schemes only by signature size, not public key plus signature.
- Assuming certificate compression will make up the difference.
- Testing only on fast lab networks, where an extra round trip is invisible.
- Choosing a larger parameter set than policy needs, adding bytes with no benefit.
- Reporting a single byte figure without the chain depth and SCT count behind it.
Each makes the cost of post-quantum authentication look different from what users actually experience.
30.7 Trimming the chain
When bytes matter, engineers have several levers before choosing a different algorithm: remove unnecessary intermediates, reduce the number of embedded SCTs where policy permits, avoid sending a root certificate the client already trusts, and prefer ML-DSA-44 over larger parameter sets where category 2 meets policy. Each lever has a cost in policy or compatibility, so record which were used and why. Re-run Lab B with the trimmed configuration and keep both results in the lab record.
Note any client that fails with the trimmed chain.
Exercises
- EX059 — Recompute. Using Lab B's formula, compute ML-DSA-65 bytes with one SCT instead of two. Rubric: 3 = 21,249 − 3,309 = 17,940 bytes.
- EX060 — Assumption list. List four assumptions behind Lab B and how each could change the result. Rubric: 3 = four assumptions with direction of effect.
Synthesis
Post-quantum authentication multiplies handshake bytes; simple models with stated assumptions guide where to measure latency and how to trim chains.
Continue studying — chapter 30 of 40
← Chapter 29 (draft) · Course chapter index · Chapter 31 (draft) →