Complete a cryptography review

A crypto review asks whether the complete system provides the intended property. Algorithm names alone are not enough — every lesson in this course was a piece of that sentence, and the review is where the pieces meet.

Here is what “the algorithm is fine, the system is broken” looks like. A webhook uses HMAC-SHA-256, so the team marks the design secure. But the same secret is shared across environments, raw bytes are not preserved before verification, replay is allowed, and failures leak which check failed. Four exploitable gaps, zero broken algorithms.

Walk a fixed checklist

Review against a list, not against vibes. Check the threat model, high-level construction, current guidance, nonce rules, authenticated context, key access, error handling, versioning, backup, revocation, and tests. In practice I structure it like this:

goal        which property, against which attacker?
construct   maintained AEAD / HMAC / signature API, not raw primitives?
randomness  every key and nonce from a CSPRNG?
nonces      reuse impossible by design, not by discipline?
context     record IDs, versions, purpose in authenticated data?
keys        who can use each key, for which operations, logged where?
failures    fail closed, uniform errors, no partial plaintext?
format      key id + version stored with every output?
recovery    rotation rehearsed, revocation decision written down?

The review is only real if you exercise the failure paths. Verification succeeding proves little; what matters is that tampering, replay, wrong context, an old key version, and malformed input all fail — safely, uniformly, and visibly in your logs:

node --test crypto-review.test.js
# ✔ rejects modified ciphertext (1.2ms)
# ✔ rejects replayed webhook delivery (0.9ms)
# ✔ rejects wrong record context (1.1ms)
# ✔ unknown key id fails without trial decryption (0.4ms)

Review the surroundings too

The algorithm name is only one input. Review data formats, key access, nonce or replay rules, failure behavior, migration, recovery, and the authorization decision that follows verification. That last one is subtle: a verified webhook still needs an “is this event allowed to do that?” check, and reviews keep finding code that treats “signature valid” as “action approved.”

Track standards changes, including post-quantum transitions, without inventing a premature hybrid protocol. Knowing which data would need re-protection, and having versioned formats ready, is preparation enough for most teams today.

Schedule the review to recur. A design that passed in 2024 has aging parameters and possibly deprecated algorithms by 2026.

Practice

Review one encrypted field or signed webhook and save a diagram plus a table of goals, library, format, keys, failures, migration, and remaining assumptions. Run successful verification and preserve the evidence. Then test tampering, replay, wrong context, old key version, and malformed input, and record that every failure is safe and observable.