Chapter 35 — Design studio II | Engineering Quantum and post-quantum security

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 35 — Design studio II

Lesson map

Lesson 35 published. Map, example, EX069.

flowchart TD
  N0["Learning outcomes"]
  N1["35.1 Brief"]
  N2["35.2 Reference solution outline"]
  N3["35.3 Panel critique"]
  N4["Engineering note"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX069"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["35.1 Brief"]
  N2["35.2 Reference solution outline"]
  N3["35.3 Panel critique"]
  N4["Engineering note"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX069"]

[Learning outcomes]
    |
    v
[35.1 Brief]
    |
    v
[35.2 Reference solution outline]
    |
    v
[35.3 Panel critique]
    |
    v
[Engineering note]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX069]

Learning outcomes

You will (1) design post-quantum authentication for a document and firmware ecosystem; (2) choose among ML-DSA, SLH-DSA and stateful hash signatures; (3) design long-term validation with timestamps; and (4) defend the design to a panel. It integrates Chapters 26–34.

35.1 Brief

Design post-quantum signatures for BPA's (a) electronic bills of lading verifiable for 12 years by partners and courts, and (b) firmware for 3,000 field devices with 10–20 year lifetimes and constrained bootloaders. Constraints: partner verification software varies; some devices cannot be updated beyond one more bootloader version.

The two parts differ in their main constraint. Bills of lading must be verifiable by courts and partners using software BPA does not control, so compatibility and long-term evidence matter most. Firmware devices may receive only one more bootloader update, so whatever is chosen now must last the device's remaining life. Teams that treat both as one problem usually pick a single algorithm that suits neither well.

35.2 Reference solution outline

(a) Bills of lading: sign with ML-DSA-65 alongside the existing ECDSA signature during transition (dual signatures in the document format), add trusted timestamps, and plan re-timestamping (archive timestamp renewal) so that evidence remains valid if an algorithm weakens. (b) Firmware: final bootloader version accepts two verification keys — LMS (SP 800-208, verify-only on device, signing in HSM with state control) and ML-DSA-44 — so that compromise or breakage of one leaves the other; sign every image with both.

Both parts use two algorithms for the same reason: long life with no second chance.

35.3 Panel critique

Legal asks whether dual signatures confuse courts — answer: document policy states either valid signature suffices during transition, both required after a date. Operations asks about signing throughput — LMS capacity sized per Chapter 32. Security asks why not SLH-DSA for firmware — its larger signatures (7.8 kB+ for the small variant) may exceed boot-time and storage budgets on the smallest devices, but it remains a candidate for others.

Each answer refers back to a decision already made, which is what the panel wants to see: evidence, not new opinions.

35.4 Common errors and limits

Single-algorithm trust anchors for devices that cannot be updated again.
Ignoring long-term validation and timestamp renewal.
Choosing stateful signatures without state management capability.

Devices that cannot receive another bootloader update need two trust anchors now, since there is no later chance to add one. Legal evidence must remain valid for twelve years, which requires timestamp renewal if an algorithm weakens. Stateful signatures without HSM-enforced state risk index reuse after a restore, so teams lacking that capability should prefer ML-DSA or SLH-DSA.

Engineering note

Long-term validation deserves its own test. Simulate verifying a bill of lading in a future year by setting the verifier's policy to reject ECDSA and accept only ML-DSA and renewed timestamps; documents signed early in the transition must still validate through their archive timestamp chain. Running this test now reveals whether the document format, timestamp authority and verifier software actually support the transition rules that the legal team approved on paper.

Exercises

EX069 — Document design. Specify the signature fields and validation policy for dual-signed bills of lading. Rubric: 3 = transition rules and timestamp renewal.
EX070 — Bootloader keys. Justify the two-algorithm bootloader design and its cost. Rubric: 3 = diversity benefit vs code size and signing cost.

Synthesis

Long-lived authentication needs algorithm diversity, timestamping with renewal and signature choices fitted to device constraints and state-management capability.

Continue studying — chapter 35 of 50

← Chapter 34 (draft) · Course chapter index · Chapter 36 (draft) →