Chapter 36 — Cryptography and trust services: performance and scale
Lesson map
Lesson 36 published. Map, example, EX106.
flowchart TD
N0["Learning outcomes"]
N1["36.1 Fleet workload"]
N2["36.2 Password hashing costs"]
N3["36.3 Planning for peaks"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX106"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["36.1 Fleet workload"]
N2["36.2 Password hashing costs"]
N3["36.3 Planning for peaks"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX106"]
[Learning outcomes]
|
v
[36.1 Fleet workload]
|
v
[36.2 Password hashing costs]
|
v
[36.3 Planning for peaks]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX106]
Learning outcomes
You will (1) estimate cryptographic workload at fleet scale; (2) tune password hashing and verification costs; (3) plan capacity for peaks.
36.1 Fleet workload
Aiyana estimates load: 50,000 meters reporting hourly produce about 1.2 million readings per day, each needing an HMAC verification. HMAC-SHA256 on short messages takes microseconds on modern servers, so verification is cheap; the bottleneck is database writes and key lookups. She designs a cache of derived keys in the verifier's protected memory, refreshed when keys rotate. Estimating first prevents wasted optimisation of the cryptography when the real cost lies elsewhere. She confirms the estimate with a load test in staging, which shows HMAC using under one percent of processor time while the database queue grows during bursts.
36.2 Password hashing costs
The customer portal uses Argon2id from RFC 9106, which is deliberately slow. Aiyana tunes parameters so each login takes about half a second on the server and uses enough memory to slow attackers with specialised hardware. At peak, when bills are issued, thousands of customers log in within an hour. She calculates required server capacity and adds rate limiting per account and per network address, so attackers cannot use logins to exhaust resources. Tuning balances user experience, capacity and resistance to offline guessing.
36.3 Planning for peaks
Firmware rollouts create peaks: if all 50,000 meters downloaded and verified at once, collectors would saturate. Aiyana staggers updates in waves of five percent, monitors verification outcomes, and pauses automatically if failures exceed a threshold. Certificate renewals are also spread by adding random jitter to renewal times, avoiding the situation where all collectors renew within the same minute. Capacity planning for cryptography is often about scheduling, not raw speed. She also rehearses a rollout pause so that operators know how to stop a wave quickly if verification failures rise during an update.
Worked example
Aiyana estimates 1.2 million daily verifications, caches derived keys, tunes Argon2id to about half a second with rate limits, and staggers firmware and renewals.
Synthetic case. Workload figures are invented; RFC 9106 is real.
Errors and limits
Lowering password-hash cost to save capacity weakens protection. Caches of keys must be protected like the key service.
Exercises
- EX106 — Daily readings. How many readings per day does the fleet produce? Rubric: 3 = about 1.2 million;; 2 = order right;; 1 = wrong;; 0 = none.
- EX107 — Real bottleneck. Where is the bottleneck for reading verification? Rubric: 3 = database writes and key lookups, not HMAC;; 2 = database;; 1 = HMAC;; 0 = none.
- EX108 — Renewal jitter. Why add jitter to certificate renewals? Rubric: 3 = to avoid all collectors renewing simultaneously and overloading services;; 2 = spread load;; 1 = security;; 0 = none.
Synthesis
At scale, cryptographic performance depends on estimating load, tuning deliberate costs and scheduling peaks rather than on raw algorithm speed.
Continue studying — chapter 36 of 50
← Chapter 35 (draft) · Course chapter index · Chapter 37 (draft) →