Chapter 17 — Cryptography concepts
Lesson map
Lesson 17 published. Map, example, EX049.
flowchart TD
N0["Learning outcomes"]
N1["17.1 Building blocks"]
N2["17.2 Cryptography at Fernway"]
N3["17.3 Key management responsibilities"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX049"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["17.1 Building blocks"]
N2["17.2 Cryptography at Fernway"]
N3["17.3 Key management responsibilities"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX049"]
[Learning outcomes]
|
v
[17.1 Building blocks]
|
v
[17.2 Cryptography at Fernway]
|
v
[17.3 Key management responsibilities]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX049]
Learning outcomes
You will (1) explain the main cryptographic building blocks and their uses; (2) place cryptography in Fernway's architecture; (3) identify key management responsibilities.
17.1 Building blocks
Lucas studies symmetric encryption, hashing, message authentication codes, digital signatures and key exchange, using Katz and Lindell's textbook as background. He focuses on what each provides. Encryption gives confidentiality; authenticated encryption such as AES-GCM also gives integrity. Hashes give fingerprints; message authentication codes give integrity and authenticity between parties sharing a key; signatures let anyone verify origin with a public key. Key exchange lets two parties agree a key over an open network. Architects choose among these by need and never design new ones.
17.2 Cryptography at Fernway
Lucas maps where cryptography is used: TLS for the shop and email; the payment provider's tokenisation, so Fernway never stores card numbers; HMAC-signed webhooks from the delivery partner; disk encryption on laptops; encrypted backups; and the pseudonymisation from chapter 14. For each he notes the goal and the key holder. He finds that the delivery partner's webhook secret is the same in test and production, which means a leak from a test system would allow forged delivery updates in production. He recommends separate secrets per environment.
17.3 Key management responsibilities
Each use of cryptography creates key management duties: generation, secure storage, rotation, revocation and destruction, as NIST SP 800-57 Part 1 Rev. 5 describes. Lucas lists Fernway's keys and secrets with owners and rotation periods. Several had no owner or had never been rotated. He recommends a secrets manager for application secrets and a calendar for certificate renewals. He notes that most cryptographic failures in small organisations come from key handling, not from weak algorithms, so ownership and rotation deserve as much attention as algorithm choice.
Worked example
Lucas summarises five building blocks, maps six uses at Fernway, finds a shared test and production webhook secret and builds a key inventory with owners.
Synthetic case. Fernway's keys and secrets are synthetic; Katz and Lindell and SP 800-57 Part 1 Rev. 5 are real.
Errors and limits
Provider-managed keys reduce burden but add dependency. Rotation can break integrations if not coordinated.
Exercises
- EX049 — Signature versus MAC. What does a signature offer that a MAC does not? Rubric: 3 = public verification without the ability to sign;; 2 = public verification;; 1 = same;; 0 = none.
- EX050 — Shared webhook secret. Why is one webhook secret for test and production a problem? Rubric: 3 = a test leak would allow forged production updates;; 2 = forged;; 1 = vague;; 0 = none.
- EX051 — Main failure source. Where do most cryptographic failures in small organisations come from? Rubric: 3 = key handling rather than weak algorithms;; 2 = keys;; 1 = algorithms;; 0 = none.
Synthesis
Cryptography in architecture means choosing standard building blocks by need and owning every key they create.
Continue studying — chapter 17 of 40
← Chapter 16 (draft) · Course chapter index · Chapter 18 (draft) →