The goal
The previous four lessons covered choosing primitives, holding secrets, encryption at rest and TLS. This one tests the hardest thing in applied cryptography and the least taught: rotating a key on a live system, with no downtime and no data loss.
Why it is hard: rotation is not an operation but a process with an intermediate state, and in that state the system must read both old and new data. Get the ordering wrong and you either lose data, take downtime, or believe you finished when you did not.
The situation — 07:40 on a Tuesday. A teammate has just realised that three months ago a commit added appsettings.Production.json to the repo. That file contains:
| Secret | Used for | How much data depends on it |
|---|---|---|
Crypto:CardKey | Encrypting payments.card_number_encrypted | 2.4 million records |
Jwt:SigningKey (HS256) | Signing our own access tokens | Every token in circulation, 15-minute life |
Db:ConnectionString | Postgres, the app_api account | — |
Partner:ApiKey | Calling a partner API | — |
The repo is private, but it has four internal forks and full CI caches.
What to produce. A rotation plan for all four, answering for each:
- Ordering — which first, and why?
- Can it be rotated without downtime? If not, how long is needed?
- Where is the point of no return — after which step can you no longer roll back?
- How do you know it is finished?
Question 3 is what counts, and it is the one nobody asks until a rollback fails.
Comments
Commenting needs an account with at least one completed lesson. That condition is what keeps this thread worth reading: every point belongs to someone who can be asked back, and reputation accrues over time.
You can still read every comment below without an account. Signing in brings you back to this exact spot, not to the top of the page.
Loading comments…