Chapter 5 — Quantum and post-quantum security: design alternatives
Lesson map
Lesson 05 published. Map, example, EX021.
flowchart TD
N0["Learning outcomes"]
N1["5.1 Key-establishment alternatives"]
N2["5.2 Authentication alternatives"]
N3["5.3 Practical activity — Lab B"]
N4["5.4 Parameter policy"]
N5["5.5 Worked case"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX021"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["5.1 Key-establishment alternatives"]
N2["5.2 Authentication alternatives"]
N3["5.3 Practical activity — Lab B"]
N4["5.4 Parameter policy"]
N5["5.5 Worked case"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX021"]
[Learning outcomes]
|
v
[5.1 Key-establishment alternatives]
|
v
[5.2 Authentication alternatives]
|
v
[5.3 Practical activity — Lab B]
|
v
[5.4 Parameter policy]
|
v
[5.5 Worked case]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX021]
Learning outcomes
You will (1) enumerate design alternatives for key establishment, authentication and data protection; (2) compare pure post-quantum, hybrid, PSK-augmented and minimization designs; (3) quantify authentication byte costs; (4) choose parameter sets against policy; and (5) document alternatives so reviewers can challenge the choice.
5.1 Key-establishment alternatives
Hybrid PQ/T (in the sense of RFC 9794) combines ML-KEM with ECDH so that the session is secure if either holds; it is the default transition design in TLS (X25519MLKEM768) and IKEv2 (RFC 9370 additional key exchanges). Pure PQ uses ML-KEM alone; it reduces complexity and is attractive where policy requires it or where the traditional component adds no value, but it removes the hedge against an unexpected break or implementation flaw. PSK augmentation mixes a pre-shared symmetric key into the handshake (as in RFC 8784 for IKEv2); it is a quick interim protection against HNDL on a few fixed links but scales poorly. Minimization and re-architecture sends less long-lived data — a control independent of algorithms. SP 800-227 discusses KEM composition and the requirements on combiners.
5.2 Authentication alternatives
Options for certificates: keep classical certificates while monitoring ecosystem readiness (acceptable where forge-later risk is low and certificates are short-lived); issue ML-DSA certificates in closed ecosystems such as internal PKI and device fleets first; use dual or composite certificate approaches during transition where standards and products support them; and use hash-based signatures (SLH-DSA, LMS, XMSS) where conservatism or verification simplicity matters, notably for firmware.
Choose by ecosystem. NRHT's internal PKI and device fleets are closed, so ML-DSA can start there. Public web certificates stay classical until browsers and certificate authorities support post-quantum issuance at scale. For firmware, hash-based signatures fit the conservative case, provided state is managed correctly.
5.3 Practical activity — Lab B
# Lab B (ch 5): 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
For an internal service mesh on a data-centre network, 15 kB per handshake is acceptable. For clinic devices on constrained links, or protocols with small message limits, it may not be. The design response is to choose where post-quantum authentication goes first, trim chains, and measure — not to assume.
The lab's sizes come from the standards; the 400 bytes of other certificate fields and the two embedded signatures are rough assumptions. Change the chain depth or the number of embedded signatures to see how quickly the totals grow. Use the result to decide where to measure first, then measure on real handshakes in a lab.
5.4 Parameter policy
Parameter sets map to NIST categories: ML-KEM-512/768/1024 to categories 1/3/5; ML-DSA-44/65/87 to 2/3/5. A specialist sets policy explicitly (for example, category 3 by default, category 5 for national-security-adjacent partners) and records why. Uniform maximum parameters waste bytes and cycles; ad hoc choices make audits painful.
Write the policy into the cryptographic standard, with a short reason for each default and each exception. At NRHT the default for new key establishment is hybrid with ML-KEM-768. Review the policy when standards change, such as when FN-DSA is final.
5.5 Worked case
NRHT's inter-site EHR replication runs over IPsec. Alternatives: (a) hybrid IKEv2 with ML-KEM-768 on vendor A's appliances (supported now); (b) RFC 8784 PSKs for the two vendor-B sites until 2027; (c) re-architect replication to send only deltas, cutting volume by 70 %; (d) pure ML-KEM — rejected because vendor A's implementation is new and the hedge is valuable. Chosen: (a) + (b) + (c), with (b) expiring when vendor B ships hybrid support. Authentication stays classical for now; the internal PKI plan (Chapter 8) addresses it.
Record the rejected alternative and its reason in the design record, so that it can be reconsidered when vendor A's implementation matures.
5.6 Common errors and limits
- Choosing pure PQ to "be modern" without considering the hedge.
- PSK schemes without rotation and secure distribution.
- Ignoring minimization because it is not cryptography.
Each error has a guard. Keep the hybrid unless there is a reason to drop it and record that reason. For PSKs, write down how keys are generated, distributed and rotated, and when they expire. Count minimization as a security control alongside cryptographic ones. At NRHT the vendor-B PSKs were given an expiry tied to hybrid support, and replication was redesigned to send deltas, cutting volume by 70 %.
Exercises
- EX021 — Alternatives table. Compare hybrid, pure PQ, PSK augmentation and minimization on HNDL protection, complexity, scalability and residual risk. Rubric: 3 = four alternatives × four criteria, defensible.
- EX022 — Byte budget. From Lab B, by what factor does ML-DSA-65 exceed ECDSA P-256 in authentication bytes? Rubric: 3 = 21,249/1,290 ≈ 16.5.
- EX023 — Parameter policy. Write a two-line parameter policy for NRHT with justification. Rubric: 3 = categories by use, rationale.
- EX024 — PSK expiry. Specify conditions under which alternative (b) in 5.5 must end. Rubric: 3 = vendor support verified, migration tested, date bound.
- EX025 — Pure PQ case. Describe a context where pure ML-KEM is the better choice. Rubric: 3 = policy requirement or constrained context with argued hedge loss.
Synthesis
Design alternatives span hybrid, pure, PSK-augmented and minimization approaches for key establishment, and staged, closed-ecosystem-first approaches for authentication. Explicit parameter policy and byte budgets make the choice reviewable.
Continue studying — chapter 05 of 12
← Chapter 04 (draft) · Course chapter index · Chapter 06 (draft) →