Chapter 45 — Independent design review

Chapter 45 — Independent design review

Lesson map

Lesson 45 published. Map, example, EX089.

flowchart TD
  N0["Learning outcomes"]
  N1["45.1 Review method"]
  N2["45.2 PQC review checklist"]
  N3["45.3 Severity"]
  N4["Engineering note"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX089"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["45.1 Review method"]
  N2["45.2 PQC review checklist"]
  N3["45.3 Severity"]
  N4["Engineering note"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX089"]

[Learning outcomes]
    |
    v
[45.1 Review method]
    |
    v
[45.2 PQC review checklist]
    |
    v
[45.3 Severity]
    |
    v
[Engineering note]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX089]

Learning outcomes

You will (1) conduct and receive an independent design review; (2) use a structured review checklist for PQC designs; (3) classify findings by severity; and (4) respond with changes or justified acceptance. It examines Capstone I before Capstone II.

45.1 Review method

Reviewers independent of the design team read the requirements, architecture, threat analysis and evidence, then interview the team. Findings are written, classified (critical, major, minor, observation) and answered.

Independence means the reviewers did not take part in the design and do not report to its leader. Interviews test whether the team understands its own documents; a design that only one member can explain is a risk in itself. Each finding receives a written response: a change, or a reasoned acceptance of the risk with an owner. Findings and responses together form part of the evidence dossier.

45.2 PQC review checklist

• Are all public-key uses inventoried, with unknowns reported?
• Are algorithms and parameter sets from current standards (FIPS 203/204/205, SP 800-208) and are draft-era implementations excluded?
• Are hybrid combiners standard and context-bound?
• Is negotiation authenticated and fallback logged and dated?
• Are stateful signature keys protected against reuse?
• Are long-lived trust anchors algorithm-diverse?
• Is agility demonstrated (time-to-replace), not just claimed?
• Are availability risks (size, middleboxes, devices) tested?
• Are residual risks stated honestly?

Each question maps to an earlier chapter, so a finding can point to the method that was skipped.

45.3 Severity

Critical: a design flaw that defeats the security goal (e.g. XOR combiner without binding, stateful keys in software with backups). Major: significant gap (no fallback monitoring). Minor: documentation or clarity. Observations: suggestions.

Severity guides what must be fixed before proceeding: critical findings block the next stage, major findings need a plan with dates, minor ones are fixed in the normal course. Clear definitions keep reviewers consistent, so two reviewers rating the same issue reach the same level. A finding rated critical must explain how it defeats the goal, which keeps the label from being used for emphasis alone.

45.4 Worked example

Review of the model Capstone I: one major finding — customs exports would use ML-KEM only, with no traditional component and no interoperability evidence from the agency; response: add parallel RSA-OAEP recipient during transition and schedule agency test. One minor — CBOM evidence source missing for 40 records; fixed.

The export finding is major rather than critical because ML-KEM alone is not insecure, but relying on it without a traditional component and without agency testing risks both cryptanalytic surprise and an unreadable export. The response restores the hybrid approach used elsewhere and adds a dated test.

45.5 Common errors and limits

• Reviews by the design team itself.
• Findings without severity or response.
• Defensive responses instead of changes or reasoned acceptance.

A design team reviewing itself shares its own blind spots, so independent reviewers are required. Findings without severity cannot be prioritized, and findings without responses tend to be forgotten. Defensive responses waste the review: either change the design or accept the risk with stated reasons and an owner, as the export finding showed with its dated agency test and named owner.

Engineering note

Reviewers should also check what the design team measured against what it claimed. Sample three metrics from the team's dashboard and recompute them from raw evidence; disagreements reveal definition drift or pipeline bugs. A review that only reads documents can miss that the "negotiated" metric is in fact computed from offered groups — exactly the kind of error that makes a programme look further ahead than it is.

Exercises

• EX089 — Review. Review a peer's (or the model) design with the checklist and write three findings with severity. Rubric: 3 = specific, actionable, correctly classified.
• EX090 — Response. Write a response to a major finding accepting risk with justification. Rubric: 3 = risk owner, rationale, review date.

Synthesis

Independent review with a PQC-specific checklist and severity classification catches design flaws before they become deployments.

Continue studying — chapter 45 of 50

← Chapter 44 (draft) · Course chapter index · Chapter 46 (draft) →