Chapter 5 — Engineering communication
Lesson map
Lesson 05 published. Map, example, EX013.
flowchart TD
N0["Learning outcomes"]
N1["5.1 Writing for the board"]
N2["5.2 Honest security language"]
N3["5.3 Decision records"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX013"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["5.1 Writing for the board"]
N2["5.2 Honest security language"]
N3["5.3 Decision records"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX013"]
[Learning outcomes]
|
v
[5.1 Writing for the board]
|
v
[5.2 Honest security language]
|
v
[5.3 Decision records]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX013]
Learning outcomes
You will (1) explain cryptographic decisions to non-specialists; (2) write a decision record for a key-management choice; (3) avoid misleading security language.
5.1 Writing for the board
Ridgeway's board includes a farmer, a retired nurse and an accountant. Aiyana must explain why meters need authenticated readings. She starts with the decision needed, approve a budget for meter keys, then states the risk in plain words: without authentication, someone could alter readings and bills. She defines jargon once: a message authentication code is a short tag that proves a reading came from the meter and was not changed. Marcus Webb tells her the board does not need the mathematics, but it does need to know what could go wrong and what it costs to prevent.
5.2 Honest security language
Aiyana avoids words such as "unbreakable" or "military-grade", which promise more than any engineer can deliver. She writes instead that HMAC-SHA256, specified in RFC 2104 and FIPS 198-1, is widely reviewed and has no known practical attacks when keys are protected, and that the main risk is key handling rather than the algorithm. She lists what the control does not do: it does not hide readings from eavesdroppers, which would need encryption. Precise claims protect the utility when auditors or journalists later ask what was promised and why.
5.3 Decision records
Aiyana writes a decision record for the first major choice: one unique authentication key per meter, derived from a master key in the utility's key service, rather than one shared key for all meters. The record states context, options, decision, consequences, date and approver. Its key consequence is explicit: stealing one meter's key lets an attacker forge only that meter's readings, not the whole fleet's. Years later, when a contractor proposes a shared key to simplify provisioning, the record explains in two minutes why that was rejected.
Worked example
Aiyana's one-page board note requests a key-service budget, explains forged readings in plain words, avoids "unbreakable", and links to a decision record choosing per-meter keys.
Synthetic case. The board and decision are invented; RFC 2104 and FIPS 198-1 are real.
Errors and limits
Oversimplifying can mislead: saying "encrypted" when data is only authenticated is a factual error. Records without the rejected options lose half their value.
Exercises
- EX013 — Board note opening. How does Aiyana open her note to the board? Rubric: 3 = with the decision needed (budget for meter keys) then plain-language risk;; 2 = risk first;; 1 = jargon;; 0 = none.
- EX014 — What HMAC does not do. What does the note say HMAC does not provide? Rubric: 3 = confidentiality; readings are not hidden, encryption would be needed;; 2 = secrecy;; 1 = everything;; 0 = none.
- EX015 — Per-meter keys. What consequence of per-meter keys does the record highlight? Rubric: 3 = stealing one meter's key forges only that meter, not the fleet;; 2 = limits damage;; 1 = cheaper;; 0 = none.
Synthesis
Clear, honest communication and decision records make cryptographic choices understandable to decision-makers and durable across staff changes.
Continue studying — chapter 05 of 50
← Chapter 04 (draft) · Course chapter index · Chapter 06 (draft) →