Complete a cryptography review

A crypto review asks one question: does the complete system deliver the property we wanted? Algorithm names alone do not answer it. Every lesson in this course was one piece of that answer, and the review is where the pieces meet.

Take a webhook that uses HMAC-SHA-256. The team marks it secure, because the algorithm is fine. But the same secret is shared across environments. The 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 a feeling. I structure mine 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?

Each line maps to a lesson you already did. The list is short on purpose. A review you can finish in an afternoon gets done. A forty-page template gets skipped.

Run the failure paths

The review is only real if you run the failure paths. A successful verification proves very 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.

Write those as tests and keep them in the repository:

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)

Now the next refactor cannot silently remove a check. If someone catches the authentication error and returns partial plaintext, the first test goes red.

Review the surroundings too

The algorithm name is one input among many. Look at data formats, key access, nonce and 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. Reviews keep finding code that treats “signature valid” as “action approved”. They are two different questions, and the second one is yours to answer.

Keep an eye on standards changes, including the move to post-quantum algorithms. You do not need to invent a hybrid protocol today. Knowing which data would need re-protection, and having versioned formats ready, is enough preparation for most teams.

Schedule the review to recur. A design that passed in 2024 has aging parameters and possibly deprecated algorithms by 2026. Put it in the calendar, once a year at least.

Try this on your own project: review one encrypted field or signed webhook. Draw the diagram and fill in a table of goals, library, format, keys, failures, migration, and remaining assumptions. Run a successful verification and keep the output. Then test tampering, replay, wrong context, an old key version, and malformed input, and confirm every failure is safe and shows up in your logs.