Chapter 26 — Quantum and post-quantum security: architecture alternatives | 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 26 — Quantum and post-quantum security: architecture alternatives

Lesson map

Lesson 26 published. Map, example, EX051.

flowchart TD
  N0["Learning outcomes"]
  N1["26.1 Pure versus hybrid"]
  N2["26.2 Certificates"]
  N3["26.3 Interim mitigations"]
  N4["26.4 Decision table"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX051"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["26.1 Pure versus hybrid"]
  N2["26.2 Certificates"]
  N3["26.3 Interim mitigations"]
  N4["26.4 Decision table"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX051"]

[Learning outcomes]
    |
    v
[26.1 Pure versus hybrid]
    |
    v
[26.2 Certificates]
    |
    v
[26.3 Interim mitigations]
    |
    v
[26.4 Decision table]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX051]

Learning outcomes

You will (1) compare pure PQC, PQ/T hybrid and interim mitigations; (2) evaluate composite versus parallel certificates; (3) consider symmetric-key alternatives such as pre-shared keys; and (4) choose architecture per context. It builds on Chapters 18 and 25.

26.1 Pure versus hybrid

Pure PQC uses only post-quantum algorithms: simpler, smaller than hybrid, but stakes everything on newer assumptions. PQ/T hybrid combines both (RFC 9794): secure if either holds, at extra cost in bytes and complexity. During transition, many protocols and guidance documents favour hybrids for key exchange; some government guidance, such as CNSA 2.0, accepts pure PQC with the category-5 parameter sets. The choice depends on the risk appetite for cryptanalytic surprise versus complexity.

BPA chooses hybrids for external key exchange.

26.2 Certificates

Options for post-quantum authentication: (a) pure PQC certificates (ML-DSA keys and signatures); (b) composite certificates in which one certificate carries a traditional and a post-quantum key and both signatures must verify; (c) parallel chains — two certificates, one per algorithm, with negotiation choosing; (d) delayed migration with short-lived classical certificates, acceptable where active quantum attacks are not yet feasible. Each trades compatibility, size and complexity.

For BPA, option (d) is acceptable for public web certificates for now, because they last about a year and an active quantum attack needs a CRQC at the moment of connection.

26.3 Interim mitigations

Where PQC is not yet available — old VPN appliances, for example — mixing a pre-shared symmetric key into key derivation can protect recorded traffic, since PSKs are not vulnerable to Shor. RFC 8784 defines such a mechanism for IKEv2. PSKs bring key-distribution and rotation burdens, so they are a bridge, not a destination.

For BPA's two highest-value partners, the PSK is exchanged by an out-of-band channel and rotated every three months, with an owner and expiry recorded per partner. The tunnel's recorded traffic is then protected even while the appliance offers only classical key exchange.

26.4 Decision table

Context	Key exchange	Authentication
Public web portal	Hybrid X25519MLKEM768	Classical now, ML-DSA when clients support it
Partner VPN, old appliance	IKEv2 + PSK mixing (interim)	Classical, short-lived
Partner VPN, modern	IKEv2 with ML-KEM additional exchange (RFC 9370)	Per partner capability
Crane firmware	—	LMS/XMSS or ML-DSA
National-security partner	ML-KEM-1024 per CNSA 2.0	ML-DSA-87

The table makes the variation explicit: the same organization uses five different combinations depending on context. Each row traces to an earlier decision, for example the crane firmware row to the 32 KB constraint and the old-appliance row to the trade study that chose PSK mixing as an interim. When a partner upgrades, its row changes and the table shows the new target. Rows have review dates so interim choices do not become permanent.

26.5 Worked example

BPA debates composite certificates for its internal PKI. Pros: one chain, both algorithms verified. Cons: limited library support, larger certificates, complex policy. Decision: parallel chains internally where clients can be updated, delay public certificate migration until browser ecosystem support exists; review annually.

Parallel chains internally let BPA test ML-DSA certificates with clients it controls without waiting for wider support. The annual review checks browser and library releases; when the ecosystem supports ML-DSA certificates, the public portal moves, using the experience from internal deployment.

26.6 Common errors and limits

One architecture for all contexts.
PSKs without rotation plans.
Assuming composite certificates are universally supported.

A single architecture fails because contexts differ: a crane controller with 32 KB of flash and a public portal with millions of browsers cannot use the same design. PSKs without rotation eventually leak or expire unnoticed, leaving tunnels unprotected; each one needs an owner and a three-month rotation date. Composite certificates are still limited in library support, so parallel chains are often the practical choice for now, as BPA's internal PKI decision showed.

Exercises

EX051 — Hybrid argument. Argue for hybrid key exchange in BPA's portal in 150 words, citing the scheme breaks. Rubric: 3 = either-holds reasoning and cost acknowledged.
EX052 — PSK bridge. Design an interim PSK approach for one old VPN, including rotation. Rubric: 3 = distribution, rotation, retirement date.

Synthesis

Architecture alternatives differ by context: hybrids hedge surprise, pure PQC simplifies, PSKs bridge, and certificate strategies trade compatibility against assurance.

Continue studying — chapter 26 of 50

← Chapter 25 (draft) · Course chapter index · Chapter 27 (draft) →