Chapter 32 — Quantum and post-quantum security: reliability
Lesson map
Lesson 32 published. Map, example, EX063.
flowchart TD
N0["Learning outcomes"]
N1["32.1 Reliability risks"]
N2["32.2 Secure fallback"]
N3["32.3 Capacity of stateful schemes"]
N4["32.4 Silent failures"]
N5["Engineering note"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX063"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["32.1 Reliability risks"]
N2["32.2 Secure fallback"]
N3["32.3 Capacity of stateful schemes"]
N4["32.4 Silent failures"]
N5["Engineering note"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX063"]
[Learning outcomes]
|
v
[32.1 Reliability risks]
|
v
[32.2 Secure fallback]
|
v
[32.3 Capacity of stateful schemes]
|
v
[32.4 Silent failures]
|
v
[Engineering note]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX063]
Learning outcomes
You will (1) identify reliability risks from larger messages and new code paths; (2) design fallback and retry behaviour that preserves security; (3) plan capacity for stateful signature schemes; and (4) monitor for silent failures. It builds on Chapters 23 and 30.
32.1 Reliability risks
New risks: fragmentation and middlebox drops; timeouts on slow constrained devices; certificate parsing failures; library bugs in new code; exhausted stateful signature keys; HSM performance limits. Each needs detection and response.
Each risk has a matching signal: drops show up as handshake failures by path, timeouts as latency tails on device classes, parsing failures as certificate errors in client logs, and exhausted stateful keys as a counter approaching its limit. BPA's monitoring plan lists the signal, threshold and responder for each risk, so an alert reaches someone who knows what to do rather than a general queue.
32.2 Secure fallback
Fallback can preserve availability but must not create silent downgrade. Design rules: fallback only to approved algorithms; log every fallback with reason; alert when fallback rates rise; set an expiry date on fallback permission; never fall back on authentication failures, only on demonstrable incompatibility.
The last rule is critical: an authentication failure may signal an attack, so retrying with weaker settings would hand the attacker what they want. BPA's portal therefore falls back only after a connection reset on a path listed as incompatible, never after a certificate or signature error.
32.3 Capacity of stateful schemes
An LMS key with tree height 20 supports about one million signatures; a height-10 tree about one thousand. Capacity must exceed expected signing volume over the key's life with margin; monitoring alerts at thresholds (e.g. 70% used) trigger planned rollover.
Tree height trades capacity against key generation time and signature size: each extra level doubles capacity and adds a little to every signature. Because rollover requires distributing a new public key to devices in advance, the alert threshold must leave enough remaining signatures to cover that distribution period.
32.4 Silent failures
The worst reliability failure is security silently disabled: a configuration that falls back to classical-only everywhere because of a typo. Monitoring negotiated groups (Chapter 29) detects this.
BPA guards against this with a daily check that compares the negotiated hybrid share with the previous week; a sudden drop to near zero raises an alert even if no connection failed. Configuration changes to cryptographic policy also require a second reviewer, which catches typos before deployment. A silent failure cannot be seen in error logs because nothing errors; it can only be detected by measuring what is negotiated.
32.5 Worked example
BPA signs about 2,000 firmware images a year across all device families. A height-15 LMS tree (32,768 signatures) per signing site lasts more than a decade at current volume; the team still sets alerts at 50% and 80% and documents rollover to a new key with distribution of its public key in advance.
At 2,000 signatures a year, a 32,768-signature tree lasts about sixteen years per site, which is why capacity is not the constraint. The alerts still matter because volume can change, for example if a new device family is added. Distributing the next public key early means rollover needs no emergency firmware update.
32.6 Common errors and limits
- Fallback without logging or expiry.
- Under-sized stateful keys.
- Monitoring configuration instead of negotiation.
Fallback without logging and expiry turns a transition tool into a permanent downgrade path. An LMS key sized too small runs out before devices can receive a new public key, leaving no way to sign updates. Monitoring configuration rather than negotiation misses the silent failures described above, where everything looks enabled but nothing is protected. Each of these was seen in other organizations' early rollouts, which is why BPA's plan names a control for each.
Engineering note
Reliability reviews should also cover clocks and expiry. Transitional certificates, PSKs with rotation dates and fallback permissions all expire by design; if renewal automation fails, the result is an outage that looks like a cryptographic fault. Calendar the expiries in the monitoring system with alerts at 30, 14 and 3 days, and test renewal paths in the replica environment, because the first renewal of a new algorithm's certificate is a classic place for parsing or policy mismatches to appear.
Exercises
- EX063 — Fallback policy. Write a fallback policy for edge TLS satisfying the rules in 32.2. Rubric: 3 = all five rules embodied.
- EX064 — Capacity. A site signs 15 documents per minute continuously with LMS. Is a height-20 tree enough for one year? Rubric: 3 = 7.9 million signatures/year > 1,048,576 — not enough; proposes HSS/multiple trees or ML-DSA.
Synthesis
Reliability engineering for PQC anticipates size and code-path failures, designs logged, expiring, authentication-safe fallback, sizes stateful keys with margin and monitors negotiated outcomes.
Continue studying — chapter 32 of 50
← Chapter 31 (draft) · Course chapter index · Chapter 33 (draft) →