Locks and Keys

Pick any large breach of the last decade and trace the root cause. You will find stolen credentials, a key committed to a repository, a misconfigured storage bucket, an injection flaw that let the attacker query data through the application's own decryption path, a token that turned out to be predictable. What you will not find is somebody factoring a 2048-bit modulus or recovering an AES key from ciphertext. Brute-forcing a 128-bit key is not an engineering problem awaiting better hardware; it is a thermodynamics problem, and the energy budget is not on anyone's roadmap.

This is not a comforting fact — it is a redirecting one. If the primitives hold, then every real failure is a failure of composition and custody: which guarantee you bought, how you wired it up, and where the keys were sitting when the attacker arrived. That is why this course spends one module each on the primitives and two on keys, randomness, and honest claims. The math is the short part.

Cryptography sells four properties, and they are separately purchasable. Conflating them is the single most expensive mistake in architecture reviews, because it produces controls that satisfy a requirement nobody had.

Confidentiality is the guarantee that only authorized parties can read the data. Integrity is the guarantee that alteration is detectable — note that cryptography never prevents someone from changing bytes, it only makes the change visible to a verifier. Authenticity is the guarantee that the data came from the claimed source. Non-repudiation is authenticity plus provability to a third party who trusts neither participant: the author cannot later plausibly deny authorship.

The legal analogies are close enough to be useful. Confidentiality is the sealed envelope. Integrity is the tamper-evident seal — it does not stop opening, it makes opening evident. Authenticity is authentication of evidence under Rule 901: this is what its proponent claims it is. Non-repudiation is the notarized signature — the thing you can put in front of a tribunal when the counterparty says I never sent that.

Two more distinctions worth internalizing now. Authenticity and integrity travel together in practice — knowing who sent it is worthless if the message could have been edited in flight, and detecting edits is worthless if you never knew who wrote the original. And confidentiality is the only one of the four that hiding the data provides; the other three require some form of verifiable computation over the data, which is why encryption alone is such a poor answer to so many requirements.

Here is the reference the rest of the course hangs on. Five primitive families as rows, four guarantees as columns. Every later module teaches one row; when a claim in an architecture document confuses you, come back and find the cell.

Read it as a row and you learn what a primitive buys. Read it as a column and you learn your options: need non-repudiation, and only the bottom row will do — no amount of encryption or HMAC gets you there, because in both cases more than one party can produce the artifact. That single observation resolves an astonishing share of design arguments.

The discipline that makes the map usable is refusing to name an algorithm until you have named an adversary and their position. Positions are concrete: on the network path between app and API; holding a stolen backup file; holding a stolen laptop or disk; running code on the application server; a database administrator with read access; the cloud provider under legal compulsion; a former employee whose credential was never revoked. Each position defeats a different set of controls, and "we use AES-256" tells you nothing about which.

Here is the sentence pattern this course uses for every control claim, and which you should adopt in review documents. Call it the honesty test:

<Control> addresses <threat, stated as an attacker in a position>.
It deliberately does not address <a threat someone might assume it covers>.

The second line is the load-bearing one. Any control can be made to sound comprehensive by omitting it; naming a residual risk on purpose is what distinguishes a threat model from a marketing claim. It also protects you politically — a documented, deliberate gap is an engineering decision, while an undocumented one is negligence in hindsight.

A cryptographic hash is a deterministic function that maps an input of any length to a fixed-size output — the digest — such that computing the digest is fast and reversing it is not feasible. SHA-256 takes a byte, a novel, or a 4 GB disk image and returns 256 bits. Determinism matters: same input, same digest, forever, on every machine. Fixed size matters: the function is compressive, so infinitely many inputs share each possible output. Collisions exist, necessarily; the security claim is only that you cannot find one.

Three promises, and they fail separately:

Collision resistance is the strongest and always breaks first, because the attacker gets to choose both inputs and birthday-bound mathematics halves the effective security. That ordering is why MD5 and SHA-1 died as signature hashes years before anyone could reverse a digest of your password.

Change one bit of the input and roughly half the output bits change, unpredictably. This is the avalanche effect, and it is what separates a cryptographic hash from a checksum. A CRC also detects accidental corruption, but its structure is linear: an attacker can compute what edit to make elsewhere in the file to restore the original checksum. With SHA-256, there is no such steering — the relationship between input change and output change is designed to be structureless.

Every legitimate use of a hash leans on a specific property. Naming that property is how you evaluate whether a deprecation announcement is your emergency or someone else's.

Integrity verification. You download a 6 GB installer and compare its digest to one published on the vendor's site. The property is second-preimage resistance: nobody should be able to produce a different file matching the published digest. Note the guarantee map's asterisk — this works only because the digest arrived through a channel you trust more than the file. A digest published next to the file it describes protects against a corrupted disk, not an attacker who serves you both.

Content addressing. Git names every object by the digest of its contents. Two identical files are automatically one object; a commit's identity depends on its tree, which depends on its blobs, so the whole history is chained and any retroactive edit changes every subsequent identifier. The property is collision resistance — which is precisely why git's migration off SHA-1 is a real, if unhurried, project.

Deduplication. The wine-cellar stores label photographs; hashing each upload and storing one copy per distinct digest saves a large fraction of the bucket. Collision resistance again: a collision means one customer's photo silently replaces another's.

Signature input. Signatures are computed over a digest rather than a message, because the message can be a gigabyte and the signing operation cannot. This is why a collision attack is fatal to a signature scheme — module 6 walks it.

Credential storage. Storing a digest instead of the secret means a database leak yields no directly usable credential. The property is preimage resistance, and for low-entropy secrets that promise is much weaker than it sounds — which is the entirety of module 3.

Here is the distinction that ends the most common confusion in the industry. Three operations, grouped in people's heads because all three turn readable text into something unreadable, and otherwise unrelated.

Base64's ubiquity in security-adjacent places is exactly why it gets mistaken for protection. JWTs are base64url; TLS certificates are base64 in PEM form; API payloads carry base64 blobs. In every one of those cases the base64 is doing transport work, and the security — if any — comes from a signature or an encryption layer inside the encoded bytes. A JWT's payload is readable by anyone holding the token. What the signature buys is that they cannot change it and have it still verify.

When a hash function is declared broken, the correct next question is which property fell. MD5 has practical collision attacks — two different inputs producing the same digest can be constructed in seconds on a laptop. It does not have a practical preimage attack: given a digest, nobody can produce a matching input. SHA-1 followed the same path; the 2017 SHAttered result produced two PDFs with identical SHA-1 digests, at substantial but affordable compute cost, and the cost has fallen since.

That distinction decides your remediation urgency. A collision attack is fatal wherever an attacker supplies content that gets signed, addressed, or deduplicated: certificate signing (a colliding pair means a CA signs the benign document and the attacker holds a valid signature over the malicious one), software update manifests, content-addressed storage. It is largely irrelevant where you hash your own data for a non-adversarial purpose — an MD5 cache key over an internally generated query string is ugly and worth replacing on the next pass through that code, but it is not an incident.

The working default: SHA-256 unless a standard or a library says otherwise. SHA-3 and BLAKE3 are fine and sometimes faster; the choice among modern hashes is rarely where your risk lives. Where a standard specifies a hash — the certificate ecosystem, JWS algorithm names — follow the standard rather than optimizing.

Your login endpoint is a fortress. Five attempts per minute per account, exponential backoff, lockout, device fingerprinting, a second factor for anything sensitive, and an alert if one IP address tries a thousand accounts. Against an online attacker guessing passwords, those controls are worth more than any hashing decision you will ever make.

Then the users table leaks — through a SQL injection flaw, a stolen backup, an over-permissive object storage bucket, a contractor's credential. Now every one of those controls is irrelevant. The attacker has the hashes on their own hardware and can test candidates as fast as silicon allows, with no network, no logging, and no limit. There is no lockout in a GPU.

The number that matters is guesses per second. Against a fast general-purpose hash like unadorned SHA-256, a single commodity GPU tests on the order of 10¹⁰ candidates per second; a modest rented rig with eight of them is closer to 10¹¹. Against a properly parameterized argon2id, the same hardware manages something like 10¹ to 10² per second, because each guess must allocate and traverse a large block of memory that cannot be parallelized away. Both figures are illustrative and vary by hardware generation and parameters, but the ratio — roughly eight to nine orders of magnitude — is the entire subject of this module.

Without salt, a password hash is a pure function of the password, which hands the attacker an enormous economy of scale. Hash the top billion passwords once and you have a table that inverts every unsalted database in the world, forever — that is a rainbow table, or in its simpler modern form, a sorted lookup file. Worse, within a single leaked table, identical hashes reveal identical passwords: you learn which accounts share a password and which password is most popular, and you crack thousands of accounts with one success.

A salt is a per-user random value, stored in the clear alongside the hash and mixed into the computation. It makes each user's hash a function of password and salt, so the precomputed table is worthless — the attacker would need one table per salt value, which is the whole point.

Three consequences follow, and the third is where people go wrong. First, salts must be unique per user — a single application-wide salt restores most of the amortization within your database. Second, salts must be random, from a CSPRNG, not a username or an email address, because those are predictable enough for an attacker to precompute against a known target. Third, salts are not secrets. They live in the same row as the hash, they leak with it by design, and a scheme whose security depends on the salt staying hidden is misdesigned. If you want a secret in the calculation, that is a pepper, and it comes later in this module.

Salt removes the discount. The work factor raises the price. A password-hashing function such as Argon2, scrypt, or bcrypt is built to be deliberately, tunably expensive: a cost parameter controls how much computation each single hash requires, and in the memory-hard families a second parameter controls how much memory it must touch.

The asymmetry is the whole design. Your legitimate user pays the cost once, at login, where a quarter of a second is invisible. The attacker pays it per candidate, per user. If a guess costs 250 ms of one CPU core plus 64 MB of memory, a rig that could have run 10¹⁰ SHA-256 guesses per second runs perhaps a few hundred argon2id guesses per second, because the memory requirement is what defeats GPU and ASIC parallelism — you can put thousands of hashing cores on a die, but you cannot give each of them 64 MB of fast memory.

Choose parameters by measuring, not by copying. Pick the latency you can afford at your login volume — 200 to 500 ms of server time is a common landing zone — and raise memory and iterations until you hit it on production-class hardware. Then write the parameters into the stored hash string, as argon2 and bcrypt both do by design, so that raising them later does not invalidate existing rows: on the next successful login you verify with the stored parameters and immediately re-hash with the new ones.

Salt and work factor both assume the attacker has your hashes. A pepper attacks that assumption. It is a single server-side secret — a random key, not per-user — mixed into the password hashing, most cleanly by computing an HMAC of the password under the pepper before it goes into argon2, or by encrypting the finished hash under a key held outside the database.

What it buys is a change in the attacker's requirements. Without pepper, "they stole the database" is sufficient for offline cracking. With pepper, they need the database and the application secret, which are different systems with different access paths and, usually, different backup regimes. For an attacker whose foothold was a leaked read-only replica credential or a misplaced backup file, that difference is total: no pepper, no guessing, no matter how weak the passwords.

The cost is operational and worth stating honestly. Rotating a pepper is awkward: you cannot recompute hashes without the plaintext passwords, so rotation means versioning — tag each row with the pepper version used, verify with the old one, re-hash with the new one on next successful login, and carry both until the population has turned over. That is a real burden, which is why pepper is a sensible addition for a system holding consumer credentials and an over-engineering flag for a two-person internal tool. Choose it knowingly.

The wine-cellar's API keys are stored as bare SHA-256 digests, no salt and no work factor, and that is the correct design. Understanding why is the test of whether the previous four sections landed as mechanics or as ritual.

The defense budget tracks the entropy of the input, not the sensitivity of the data it protects. A password is a human-chosen string with perhaps 20 to 40 bits of real entropy, drawn from a distribution an attacker knows better than the user does; the whole apparatus of salting and slow hashing exists to compensate for that weakness. An API key is 32 bytes from a CSPRNG, rendered as wc_live_ plus 43 base64url characters — 256 bits of entropy with no distribution to exploit. There is no candidate list. At 10¹⁰ guesses per second, exhausting even a 128-bit space takes longer than the age of the universe by an enormous margin. Slowing each guess by a factor of 10⁸ changes nothing that matters, because the attacker was never going to make the guesses.

What the slow hash would cost is concrete: API keys are verified on every request, not once per session. Adding 250 ms and 64 MB per verification to a service handling a few hundred requests per second is not a security improvement, it is a capacity incident. And the salt would break the lookup: with a per-row random salt you cannot find the row by hashing the presented key, so you would need an unsalted index anyway or a linear scan of every key in the table.

AES is a block cipher: a keyed, reversible transformation on 128-bit blocks, standardized in 2001 after an open international competition, implemented in hardware on every server and phone you will deploy to. With a 128- or 256-bit key it is the default for essentially all bulk symmetric encryption, and ChaCha20 is its equally respectable stream-cipher counterpart, generally preferred where hardware AES acceleration is absent.

Brute force is not a threat model here. Exhausting a 128-bit keyspace is not slow engineering — it is a thermodynamic impossibility: the energy required to merely count to 2¹²⁸ in ideal irreversible computation exceeds anything a civilization-scale power budget makes available. AES-256 is chosen over AES-128 for long-lived data and standards compliance, not because 128 is close to falling.

What AES alone does not give you is any structure for messages longer than 16 bytes. That is the mode of operation's job — CBC, CTR, GCM — and the mode is where the guarantees are decided. The next two sections are entirely about that choice.

Here is the module's central misconception, stated the way it is usually said aloud: "the field is encrypted, so it can't be tampered with." It is false, and the reason is a property called malleability.

Take AES-CTR, or any stream construction. The cipher generates a keystream, and the ciphertext is plaintext XOR keystream. Flip bit 47 of the ciphertext and bit 47 of the decrypted plaintext flips too — no key required, no detection. If the attacker knows the record layout, and record layouts are rarely secret, they can turn "role":"user" into something else, or subtract a digit from a quantity. CBC is malleable differently and no better: an attacker who alters a ciphertext block garbles that block on decryption and makes a controlled, bit-precise edit to the next block. Either way, the ability to make targeted plaintext edits without the key is fully available.

Worse, the receiver's error behavior can leak the plaintext itself. In a padding oracle attack, the attacker submits modified ciphertexts and observes only whether decryption reported a padding error, a parse error, or success — a single bit of feedback per attempt. That bit, applied byte by byte, recovers the entire plaintext without ever recovering the key. This is not exotic: it broke real frameworks, real payment systems, and real VPN products, and it works through nothing more than a difference in response codes or timings.

Authenticated encryption (AEAD) — AES-GCM, ChaCha20-Poly1305, AES-SIV — collapses the two operations into one primitive that cannot be assembled wrongly. Sealing takes a key, a nonce, the plaintext, and optional associated data, and produces ciphertext plus an authentication tag. Opening takes the same key, nonce, associated data, and the ciphertext-plus-tag, and either returns the plaintext or fails. There is no third outcome, and critically, no plaintext is released before the tag verifies.

The associated-data parameter is the underused half of AEAD and worth designing deliberately. It is data that is authenticated but not encrypted, bound into the tag. Encrypt a wine-cellar record's contents with the record's id and tenant id as associated data, and a ciphertext lifted from row 5001 will not open in row 5002 — the tag check fails. Without that binding, an attacker with database write access can move valid ciphertexts around and produce well-formed lies out of authentic components. Use it for the record identity, the tenant, and any context that must not be interchangeable.

A nonce is a number used once — per key, without exception. AES-GCM's nonce does not need to be secret or unpredictable; it needs to be unique. Repeat one under the same key and the failure is not a gradual weakening. It is total, and it is total in two directions at once.

Two safe strategies, and you should be able to say which one your system uses. A counter: maintain a monotonic sequence per key, which is exact and cheap but requires state that must survive restarts, and must never be shared across two processes encrypting under the same key — the classic failure is a container image with a snapshot counter that restarts at zero. Or random: draw 96 bits from a CSPRNG each time, which needs no state but relies on collision probability staying negligible, which it does for GCM's 96-bit nonce until you approach roughly 2³² messages under one key — after which you rotate the key. AES-SIV and XChaCha20-Poly1305 exist precisely to blunt this edge: SIV degrades gracefully on reuse and XChaCha's 192-bit nonce makes random collision a non-issue. If your system generates many messages per key from distributed workers, choose one of those.

Sometimes you do not need confidentiality at all. A webhook payload going to a customer's endpoint is not secret from that customer — they are the intended reader. What they need is a way to know it came from you and was not altered or replayed. That is authenticity and integrity without confidentiality, and the primitive is a HMAC: a keyed hash producing a tag that anyone holding the shared secret can compute and verify, and nobody else can produce.

Three implementation details carry most of the failures. Sign the exact bytes: if the receiver parses JSON and re-serializes before verifying, key ordering and whitespace will change the digest and verification will fail intermittently in ways that lead teams to disable it. Compare in constant time: a normal string comparison returns early on the first differing byte, and that timing difference is enough to let an attacker discover a valid tag byte by byte; use the library's compare_digest-equivalent. Include a timestamp inside the signed material and enforce a window: the MAC proves authorship, not freshness, so without it a captured request is replayable forever.

Symmetric cryptography assumes the hard part is already done. Two parties who share a secret can protect everything between them; two parties who do not share a secret cannot establish one over a channel an attacker is watching — anything you send to agree on a key, the attacker also receives.

The deadlock has a second face at scale. If every pair of participants needs its own shared secret, a network of n participants requires n(n−1)/2 secrets: 10 services means 45 secrets; 100 means 4,950; the public internet means a number with no meaning. Every one of those has to be generated, delivered securely, stored, rotated, and revoked. Before 1976 the honest answer to "how do we get the key to them?" was couriers and sealed pouches, which worked for governments and banks and for nobody else.

An asymmetric keypair is two mathematically linked values with an intentional asymmetry: what one key does, only the other can undo, and deriving the private key from the public one is infeasible. One half is published to anyone who wants it; the other never leaves its holder. That single structural fact yields two distinct capabilities, and keeping them separate in your head prevents most confusion in this area.

Two clarifications that prevent later errors. First, the folk phrase "encrypt with the private key to sign" describes a historical RSA implementation detail, is not how modern signature schemes are constructed, and is meaningless for elliptic-curve signatures where no encryption operation exists to repurpose. Signing is its own operation; module 6 says this again at greater volume because it matters. Second, a public key on its own is an anonymous mathematical object. Nothing about it says whose it is — and that gap between key and identity is the entire subject of module 6.

The most elegant use of the asymmetry is not encryption at all. In a Diffie-Hellman key exchange, each party generates a keypair, sends the public half in the clear, and combines its own private half with the other's public half. The mathematics is arranged so that both computations produce the same value, while an observer who saw only the two public halves cannot compute it. Neither party ever transmits the secret; both derive it. Two strangers, one public channel, one shared secret — the deadlock broken.

Now the crucial operational question: which keys are used for that exchange? If the server always uses the same long-term keypair, then an attacker who records years of traffic and later steals that key can go back and derive every session's secret. If instead each connection uses a freshly generated, immediately discarded keypair — an ephemeral exchange — then the session secret cannot be reconstructed after the fact, because the private values that produced it no longer exist anywhere. That property is forward secrecy, and it is why TLS 1.3 removed non-ephemeral key exchange from the protocol entirely.

State the consequence precisely, because this is a question you will be asked in an incident. A stolen long-term server key lets the attacker impersonate the server going forward — they can complete handshakes as you until the certificate is revoked and the revocation is honored. With forward secrecy, it does not let them decrypt any recorded past session. Without it, everything they recorded opens at once.

Asymmetric operations are expensive — orders of magnitude slower than AES per byte — and structurally limited: RSA encryption cannot handle a message longer than its modulus, and no asymmetric primitive is designed for streaming gigabytes. So no serious protocol uses them for bulk data. Instead: use asymmetric cryptography once, to establish a symmetric session key; then encrypt everything with AEAD under that key. That is hybrid encryption, and it is the shape of TLS, SSH, Signal, PGP, S/MIME, and every envelope-encryption scheme in module 7.

Read the figure once more and notice the honest gap. After the second flight, the client has a session key and no idea who holds the other copy. An attacker who intercepted both messages and substituted their own key-exchange values would have completed a perfectly confidential channel — to themselves. Key exchange gives you a secret with whoever you talked to; it never tells you who that was. Everything that closes this gap is a signature, and module 6 is where it closes.

A digital signature is a value computed from a message and a private key, such that anyone holding the corresponding public key can verify the pair (message, signature) and nobody without the private key can produce a value that verifies. Signing operates on the message's digest for practical reasons — the message may be gigabytes and the signing operation works on a fixed-size input — which is why a collision attack against the hash is fatal to the whole scheme: two messages sharing a digest share every signature.

With both MACs (module 4) and signatures on the table, the choice between them becomes a decision with criteria:

The rule of thumb: if the verifier and the producer are the same trust domain and no outsider will ever adjudicate, a MAC is simpler, faster, and sufficient. The moment a third party must be convinced — a court, an auditor, a user's device that never met you — you need a signature.

A certificate is a document containing a public key, a name, a validity period, and some constraints, signed by somebody else. That is the whole idea. It is the mechanism from the previous section applied to a specific kind of message: an assertion that this public key belongs to this name. Everything mystical about the certificate ecosystem is organizational, not cryptographic.

The fields that carry meaning in a modern web certificate:

Note which fields are absent from that list: the organization's honesty, its security posture, the content of the site. A certificate authority (CA) issuing a domain-validated certificate has verified exactly one thing — that the requester controlled the domain at issuance time, typically by answering a challenge on it. That is a meaningful check and a narrow one.

A CA cannot sign every certificate with a key that sits online in an issuance service — that key would be the single most attractive target on the internet, and its compromise would be unrecoverable. So the ecosystem uses a chain: a root whose key stays offline, intermediates that do the daily work, and leaves for actual servers.

The root's special status is worth stating plainly, because it is where the recursion stops. Its certificate is self-signed, which proves nothing — anyone can self-sign anything. It is trusted because it is already in your device's trust store, put there by your operating system or browser vendor under a root program with audit requirements. That is an out-of-band trust decision made on your behalf, and the entire chain is a way of extending that one decision to millions of servers you have never heard of.

When your app connects to api.cellar.example, the server presents its leaf certificate and usually the intermediate. The client then performs a sequence of checks, and knowing them in order lets you diagnose certificate errors precisely instead of by ritual.

One: does the requested hostname match a SAN entry on the leaf? Two: is the current time inside the leaf's validity window? Three: does the leaf's signature verify under the intermediate's public key, and does the intermediate permit issuance (CA:TRUE, appropriate key usage)? Four: does the intermediate's signature verify under a key in the trust store — is a root reached? Five: has anything in the chain been revoked, checked by OCSP stapling or a browser's CRL-set equivalent? And finally, the handshake itself: the server signs the transcript with the private key corresponding to the leaf's public key, proving it actually holds that key rather than merely possessing a copy of somebody's certificate.

Now the useful reframing for incidents. A certificate error is not a statement that an attack is happening. It is a statement that the identity claim could not be verified, and the causes are ranked by frequency: an expired certificate, a missing intermediate in the server's chain, a hostname that does not match the SAN, a client clock that is wrong, a corporate middlebox intercepting traffic, or — least often, but the reason all the machinery exists — an actual impersonation attempt. Diagnose which, and fix that.

A short catalogue, all of them recurring rather than exotic:

Keys in source control. A cloud access key committed during a late-night debugging session, removed in the next commit, and permanently present in the repository history. Automated scanners find these within minutes of a push to a public host, and "the repository is private" is a weak defense: it is cloned onto laptops, mirrored by CI, granted to contractors, and occasionally made public by accident.

Keys baked into images. A Docker image with an environment variable set at build time, or a mobile app binary with an API key in its constants. Both are distributed artifacts; anyone with the image or the app has the key, and mobile app decompilation is a routine exercise.

Keys readable by the compromised process. A secrets manager is a real improvement and it has a limit: once the application fetches a secret, that secret is in the memory and often the environment of the process an attacker has just taken over. This is not an argument against secrets managers; it is the boundary of what they buy.

Keys that never rotate. A signing secret shared with a partner in 2019, still in use, known to four people who have left the company since. Nothing detects this. There is no alarm for a secret whose blast radius has quietly grown for six years.

Keys in the wrong blast radius. One API key shared by every environment, so a leak from a staging box that a contractor could log into is a production compromise.

Storage options form a spectrum, and the useful way to rank them is not "more secure" but "which attacker does this defeat?" That framing turns a dogma argument into an engineering one and lets you defend a modest choice honestly.

The critical shift happens between tiers 3 and 4. A secrets manager gives your application a copy of the key; a KMS never does. You send the KMS data and an instruction — encrypt this, decrypt this, sign this — and it returns the result. The key material is not in your process, not in a core dump, not in a log, and not exfiltratable by a memory-disclosure bug. What the attacker can steal instead is your permission to make those calls, which is a genuinely different problem: it is bounded in time, visible in CloudTrail-style logs, revocable with an IAM change, and rate-limitable.

Tier 2 deserves an honest word, because dogma here is unhelpful. Environment variables on a hardened host, with no shell access, no debug endpoints, and a small blast radius, are a defensible choice for a small service — they defeat the most common real-world leak, which is repository exposure. What they do not survive is any capability to read the host: a process listing, a crash dump that captures the environment, a debug endpoint that prints config, or an image layer that baked them in. Choose tier 2 knowing that list, not by default.

KMS solves key custody and creates a throughput problem: you cannot send a million database rows through a network service on every page load, and cloud KMS APIs have both size limits (a few kilobytes) and request quotas. Envelope encryption resolves it, and it is module 5's hybrid pattern applied to storage instead of transport.

Generate a fresh symmetric data key per record, per object, or per tenant. Encrypt the data locally with that key using AEAD — fast, local, unlimited size. Then ask the KMS to encrypt (wrap) the data key under the master key, store the wrapped data key next to the ciphertext, and discard the plaintext data key from memory. To read a record, send the wrapped key to the KMS, get the plaintext data key back, decrypt locally, discard.

Read the thief panel carefully, because it contains the honest limit. Envelope encryption converts "steal the data" into "steal the data and obtain KMS decrypt permission." Against a leaked backup, a misconfigured snapshot, a decommissioned disk, or a database-only compromise, that is decisive. Against an attacker who has taken over the application role — which holds decrypt permission by necessity — it is not, and the controls that matter there are IAM scoping, per-tenant key policies that make bulk decryption anomalous, request-rate alarms on the KMS, and the detection work of module 8.

"We cannot rotate the master key; we would have to re-encrypt forty terabytes" is a sentence that reveals a missing envelope layer rather than a real constraint. In an envelope design, the master key protects only the data keys, which are 32 bytes each. Rotation unwraps each data key under the old master version and rewraps it under the new one. The record ciphertext is not read, not rewritten, and not touched. Rotating protection over 40 TB of data becomes an operation over a few hundred megabytes of keys, and cloud KMS products further reduce it by retaining old key versions so old wrapped keys stay openable while new writes use the new version.

Be precise about what rotation buys, because the compliance framing usually is not. It bounds the exposure window of an undetected key compromise: a key rotated quarterly can decrypt at most a quarter's worth of newly written data if the previous version leaked. It gives you a rehearsed procedure, which is the actual point — the first time you rotate a key should not be during an incident. It supports credential hygiene after departures and vendor changes. And it produces the evidence auditors ask for.

What genuinely does require re-encryption is a change of algorithm or data-key scope, or a compromise of a specific data key. Design for that too: store a key version and algorithm identifier with each record so a migration can proceed lazily — on read, if the record is on the old scheme, re-encrypt under the new one and write it back. The same lazy-migration shape as module 3's password rehash on login.

Every secret in this course begins as a random number. Keys, nonces, salts, session tokens, password-reset tokens, CSRF tokens, MFA recovery codes, ephemeral key-exchange values. If the number was predictable, the secret was never secret — and nothing anywhere in the stack reports an error, because a predictable random number is indistinguishable from a good one to every layer that consumes it. This is the quietest failure mode in the guide.

The distinction to hold: a general-purpose PRNG (Math.random(), C's rand(), random.random(), anything seeded from a clock) is designed for statistical properties — uniform distribution, long period, speed. Given some output, its future output is computable. A CSPRNG (crypto.getRandomValues, Python's secrets, /dev/urandom, java.security.SecureRandom) is additionally designed so that observing output reveals nothing about past or future output, and it is seeded from operating-system entropy. Both produce numbers that look random to a human and to a histogram; only one survives an adversary.

Two historical failures worth carrying, because both are precise:

Debian OpenSSL, 2008. A maintainer removed lines flagged by a memory-analysis tool that happened to supply entropy to the random number generator. For roughly two years, keys generated on affected systems were drawn from a space of about 2¹⁵ possibilities determined mostly by process id. Every generated SSH host key, TLS key, and OpenVPN key from those systems was enumerable. Nothing failed visibly; the keys were structurally valid and worked perfectly.

Sony PlayStation 3, 2010. ECDSA signatures require a per-signature random value, and the requirement is as strict as module 4's nonce rule: reuse it under the same key and the private key can be recovered algebraically from two signatures. Sony's implementation used a constant. The code-signing private key was extracted and arbitrary code could be signed as genuine. Note the shape — this is module 4's nonce sin appearing at the signature layer, with the same total-failure character.

Data exists in three states, and each has its own encryption story, its own attacker, and its own limits. Saying "encrypted" without specifying which is the ambiguity that lets weak systems sound strong.

In transit. The data is moving between two machines and is encrypted for the journey — TLS, almost always. The attacker it stops is on the network path: hostile Wi-Fi, a compromised router, an ISP, a passive tap at an exchange. It stops protecting the moment the data arrives and is decrypted, which is the point of arriving.

At rest. The data is sitting on storage and is encrypted there — full-disk encryption, database or column encryption, encrypted object storage, encrypted backups. The attacker it stops is one who obtains the storage medium without the running system's authority: a stolen laptop, a decommissioned drive, an exfiltrated backup file, a public snapshot, a cloud provider's departing employee walking out with a disk. It does not stop anyone who asks the running application nicely, because the application decrypts by design.

In use. The data is in memory, decrypted, being processed — because computing on data generally requires seeing it. This is the state with the weakest protections and the highest share of real breaches. Confidential computing (enclaves, encrypted memory) and homomorphic techniques are genuine frontiers, but they are narrow, slow, and rarely deployed for general workloads; assume, in a review, that in-use data is plaintext to anyone who owns the process.

Cross the three states with the attacker positions from module 1 and the arguments resolve themselves.

Look at the app-server row and read it as an incident answer. When an attacker exploits an injection flaw and queries data through your application, the at-rest encryption performs exactly as designed: the application asks the KMS to unwrap a data key, is authorized, decrypts, and returns the plaintext. Nothing failed. The control was never aimed at that attacker, and the only honest sentence is that it was not.

The most common misuse of encryption in the industry is not a broken algorithm. It is a true statement deployed to answer a question it does not answer.

The pattern: a framework requires encryption of sensitive data at rest. The team enables full-disk encryption on the database volumes, or turns on the storage service's default encryption, and the control is marked satisfied. The auditor is satisfied too, correctly — the requirement said at rest and the data is encrypted at rest. Then the breach arrives through SQL injection in a search endpoint, and the attacker reads plaintext through the application's own credentials, because the volume is mounted and decrypted on a running host and every query returns cleartext. The post-incident statement says customer data was encrypted at rest, which is true, and irrelevant, and readers will hear it as reassurance about an event it had no bearing on.

To be clear about the corrective: the answer is never to skip at-rest encryption. It is cheap, it is genuinely decisive against a whole class of real incidents — the exposed snapshot, the resold drive, the backup in a public bucket — and envelope encryption with per-tenant keys meaningfully raises the bar even against some database-level compromises. The discipline is claiming it for what it does.

End-to-end encryption is a specific and strong claim: only the communicating endpoints hold the keys, and the provider in the middle cannot read the content — not because policy forbids it, but because they do not possess the means. Under breach, under subpoena, under a rogue administrator, the answer is the same: they have ciphertext.

That is a much stronger claim than "encrypted in transit and at rest," which nearly every service can say truthfully while retaining full access to your content. Because the phrase is valuable, it is used loosely, and the loose usage is detectable with one question:

Three tells reveal provider-held keys reliably, and you can check all three from the product's own documentation:

Server-side search over content. If the provider can full-text search your messages or documents on their servers, they can read them. Encrypted-search techniques exist and are narrow, slow, and loudly advertised when actually deployed; ordinary search is decisive evidence.

Web access with no key ceremony. If you can log in from a borrowed browser with only a password and immediately read your history, the keys came from the provider. Real end-to-end products make this awkward on purpose — device linking, a recovery phrase, a key backup you must set up — and that awkwardness is the feature.

Full account recovery with content intact. "Forgot your password? No problem, everything is still here." If losing all your secrets does not lose your data, someone else has the keys. Compare with a real E2E product, where losing every device and the recovery phrase means the data is gone — a support burden they accept because it is the guarantee.

You do not need a mathematics degree to evaluate cryptographic claims. You need to notice which claims are unfalsifiable, which are true but uninformative, and which contradict each other. Here is the lexicon, with the reusable question attached to each entry — the question is the part you take into the meeting.

Then the rule that generates all the others: you do not roll your own. The rule is well known and usually understood too narrowly, as if it only prohibited inventing a cipher. Almost nobody does that. What people do constantly is invent protocols and compositions out of standard parts — a hand-rolled token format that concatenates fields and appends a truncated hash; a session scheme that encrypts a user id with AES-CBC and treats decryptability as authentication; a custom handshake between two internal services; XOR with a rotating secret because the data "just needs light protection."

These fail for exactly the reasons the primitive-inventors fail. The bugs are in composition — order of operations, what is covered by the tag, what happens on error, whether the same key does two jobs — and composition bugs are invisible to testing because the system works perfectly for well-behaved inputs. Every failure in this course is a composition failure: unauthenticated encryption, reused nonces, MACs used where signatures were needed, peppers stored beside hashes.

Now put it together on a real artifact. A vendor pitching the wine-cellar a customer-data platform writes:

"All customer data is protected with military-grade proprietary
encryption. Keys are stored securely in our database. Our platform
is end-to-end encrypted and independently audited."

Four sentences, and every one of them is answerable.

"Military-grade" — most likely AES-256, which is unremarkable and fine. Not a finding on its own; a finding when it is offered as the answer, because it names an algorithm where the question was about keys and states.

"Proprietary encryption" — this contradicts the previous phrase. "Military-grade" implies a standard (AES); "proprietary" says they did not use one. Both cannot be true, and the contradiction is the most informative thing in the paragraph: either the marketing copy is unsupervised, which tells you about their review culture, or there is a homemade scheme in the product, which is the roll-your-own anti-pattern in its original form.

"Keys stored securely in our database" — this is the finding with teeth. Keys beside the data they protect defeat the purpose entirely: any compromise that reaches the data reaches the keys, so at-rest encryption stops nothing beyond physical theft of the medium. This is module 7's spectrum, failed at tier 1 or 2, and it is stated in their own words.

"End-to-end encrypted" — directly contradicted by the previous sentence. If they hold the keys, the ends are not the endpoints. Ask the one-question test and ask whether they can produce customer data under subpoena; the answer will be yes.

"Independently audited" — unassessable as written. This is the one to mark plausible, verify rather than condemn: a real audit by a named firm with a published report would be genuinely reassuring and would change several other answers. Ask for the four facts.