Not how the math works — when each primitive applies, how keys are actually managed at scale (envelope encryption, KMS, rotation), and the design rules that keep crypto decisions out of incident reports and audit findings.
~2.5h study~1h exercise2 interactive toolsFast track ~65 min
Fast track — know your AES from your HMAC?
Compresses to ~65 min. Primitive definitions collapse; the selection tool, envelope encryption, and the design rules stay mandatory — key management is where architecture meets crypto, and where it fails.
§01 takeaway · 10 min
§02 advisor, a few rounds · 10 min · MANDATORY
§03 envelope encryption + KMS, in full · 25 min · MANDATORY
§04 design rules, in full · 15 min · MANDATORY
STEP 01
The primitives, by contract
SKIM
Fast-track takeawayFive contracts: hash (SHA-256) — fingerprint: integrity, content-addressing, dedupe keys; anyone can compute it, so it proves nothing about who · MAC (HMAC) — hash + shared secret: integrity AND authenticity between parties who share the key · symmetric encryption (AES-GCM) — confidentiality + built-in integrity (AEAD), fast, one shared key; the workhorse for data · asymmetric (RSA/EC) — keypairs: encryption-to-a-public-key (rare directly; used to move symmetric keys) and signatures (private signs, anyone verifies) — authenticity without shared secrets: JWTs, certs, artifact signing · password hashing (bcrypt/argon2) — deliberately slow, salted; never SHA-anything for passwords. And the meta-rule: AEAD modes only (GCM/ChaCha-Poly), never ECB, never hand-rolled composition — use a vetted library (Tink-style) that removes the choices.
credentials — with migration plan for cost-factor increases
STEP 02
Choosing under review conditions
MANDATORY
Primitive advisor
The second question is the one people miss: can every verifier be trusted with forging power? HMAC verifiers hold the signing key — fine between two backend services, wrong for a token validated by 200 services (any one of them compromised can mint tokens for all — the M22 argument for asymmetric JWTs). Signature verification distributes trust without distributing power.
STEP 03
Keys at scale: envelope encryption & KMS
MANDATORY
Fast trackFull read. Every cloud data-encryption feature you use is this pattern; understanding it is what lets you answer "how is it encrypted, exactly?" in an audit without hand-waving.
Encrypting a million objects with one key makes rotation impossible and blast radius total. Envelope encryption layers it:
Envelope encryption · encrypt one PII record
1
Service asks KMS: "generate a data key" → receives plaintext DEK + DEK encrypted under the KEK (which never leaves the KMS/HSM)
2
Encrypt the record locally with the plaintext DEK (AES-GCM) — fast, no KMS call per byte
3
Store ciphertext + encrypted DEK together; discard the plaintext DEK from memory
4
Decrypt path: send encrypted DEK to KMS → plaintext DEK → decrypt locally. Every decrypt is a KMS authorization decision + audit log line
One key encrypts one object (or one batch); the master key encrypts only keys. Rotation, revocation, and audit all become tractable.
What this buys: KEK rotation = re-encrypt the small DEKs, not the petabytes; per-tenant/per-user DEKs enable crypto-shredding (delete the DEK → the data is gone — M18's GDPR answer for event-sourced stores); access control and audit centralize at the KMS ("who decrypted what, when" is a query).
KMS operational reality: it's a dependency on your serving path — cache plaintext DEKs briefly (with the M13 bulkhead/fallback discipline), budget its rate limits, and know your stance when KMS is down (fail closed for decryption of PII is usually right — say it out loud in the design).
Rotation discipline: every key has an owner, a rotation period, and a key-id carried alongside every ciphertext/signature so old material remains decryptable/verifiable during overlap — the same expand-migrate-contract shape as M07's versioning, applied to keys. JWKS key rollover (M22) and cert rotation (M21) are instances.
STEP 04
Design rules
MANDATORY
Decide what each mechanism defends against — in writing. "Encrypted at rest" (disk encryption) defends against stolen disks, not against a compromised app with DB credentials. Field-level envelope encryption defends against DB dumps and curious DBAs. Naming the threat prevents the security theater of defending against nothing in particular.
Sign what you'll trust later. Anything that crosses a trust boundary and comes back — tokens, cached authorization decisions, client-stored state, webhook callbacks — carries a MAC/signature, verified on return. Unsigned client-held state is user input.
Compare secrets in constant time (MessageDigest.isEqual, not String.equals) — timing side-channels on token comparison are real and boring to fix.
Never build: your own token format (use JWT/PASETO semantics — M22), your own password scheme, your own protocol. The architecture skill is recognizing which standard maps to your problem, not inventing.
Secrets hygiene: secrets come from a manager (Vault/cloud SM) via short-lived, per-service identities — not env-vars baked into images, not in Git ever (with scanning enforcing it), rotated without deploys where possible. The M21 mTLS identity is what makes "per-service identity" real.
Staff expectationOwning the data classification → protection mapping: a table from data classes (payment data, PII, entitlements, telemetry, public catalog) to required protections (field-level envelope encryption / at-rest only / signed / nothing) with the threat each addresses. That one artifact turns every "should this be encrypted?" debate into a lookup, and it's what auditors actually ask for.
STEP 05
Exercise
MANDATORY
Fast trackStep 1 (~25 min): implementing envelope encryption once makes the KMS pattern permanent.
1
Build envelope encryption. Java: local "KMS" class holding a KEK, generateDataKey() returning plaintext+wrapped DEK, encrypt a record with AES-GCM (fresh IV per message, stored alongside), persist ciphertext+wrapped DEK+key-id, decrypt path. Then rotate the KEK and prove old records still decrypt via key-id lookup.
2
Sign a CDN URL. HMAC over path+expiry+userId as query params; verify in a filter; demonstrate tamper rejection and expiry. Note where this appears in your real CDN config (M10 token auth) and which key rotation story it has.
3
Paper. Write the data classification → protection table (§04) for your platform's ten most sensitive data classes, with the named threat per row and the gap list where current state falls short.
Self-check
Why is HMAC wrong for a token that 200 services validate?
Every validator holds the shared key, and HMAC verification power = minting power — one compromised service can forge tokens for the whole estate, and rotation means synchronized redistribution to 200 places. Asymmetric signatures give validators only the public key: verification without forging, rotation via published JWKS.
"Our database is encrypted" — what three questions expose whether that means anything?
(1) At what layer — disk/TDE (defends stolen media only) or field-level (defends DB dumps and over-privileged access)? (2) Who can decrypt — does the app's normal credential suffice, and is each decrypt authorized/audited (KMS) or ambient? (3) What's the rotation and shredding story — can you rotate keys without downtime and destroy a user's data by destroying a key? Answers locate the real security boundary.
Where does crypto-shredding beat deletion, and what makes it work?
Wherever data is immutable or smeared across systems you can't scrub: event-sourced logs (M18), backups, replicas, data lakes. Per-user DEKs encrypt all of a user's records; erasure = destroy that DEK — every copy everywhere becomes noise simultaneously. Requires the envelope discipline from day one; retrofitting is a migration project.