MySmartCoPilot
Ask Passes Your pass 7 days left 1 day left Last day

Your country

Tools that support it use your country for local currency, number formats, units and paper size. Your choice is saved only in this browser.

Applied Cryptography for Developers  Module 14 – Testing, side channels and review

Reviewing crypto code: a practical checklist

Review crypto code with twelve questions, prove each finding with a failing test, map it to CWE, OWASP and ASVS entries, and write comments that get fixed.

  • Intermediate
  • 20 minutes
  • Examples run with Node.js 24.21.0, Python 3.14.8 and Pyodide 314.0.7
  • By MySmartCoPilot
Free: A review asks twelve questions, in an order that follows each key. With a pass: the other 8 sections and 3 interview answers, about 16 minutes.

What you will learn

  • Apply a twelve-question checklist to code that encrypts, signs, hashes or verifies, in the order that follows each key
  • Review a Node.js and a Python module and back every finding with a test that fails on the submitted code and passes on the fix
  • Map each finding to a CWE entry, to OWASP A04:2025 and to the ASVS 5.0 requirement it breaks
  • Assess severity from exposure and write review comments that name the risk, the fix and the test

Before you start

What you’ll learn · Before you start

What you will learn

  • Apply a twelve-question checklist to code that encrypts, signs, hashes or verifies, in the order that follows each key
  • Review a Node.js and a Python module and back every finding with a test that fails on the submitted code and passes on the fix
  • Map each finding to a CWE entry, to OWASP A04:2025 and to the ASVS 5.0 requirement it breaks
  • Assess severity from exposure and write review comments that name the risk, the fix and the test

Before you start

On this page

A pull request adds a helper of under 30 lines that encrypts user notes and signs share links. The build is green and its round-trip test passes. Cryptographic code is hard to review because it keeps working when it is unsound: a fixed IV, a guessable token or a comparison that stops early gives the right answer on every test that checks only the answer.

This lesson gives twelve questions to ask in a fixed order, applies them to a Node.js module and a Python module with a failing test for every finding, and ties each finding to a CWE: Common Weakness Enumeration, a numbered catalogue of kinds of software weakness. A finding that cites a CWE entry names its flaw in a way that tools and other reviewers recognise. entry, to OWASP A04:2025 and to a requirement of ASVS: The OWASP Application Security Verification Standard: numbered security requirements, each marked level 1, 2 or 3, that an application can be checked against. 5.0. It also covers severity, comments that get fixed, and a scan that you write yourself.

A review asks twelve questions, in an order that follows each key

Read the diff once for what it does, then again for what each key, nonce and check does. The questions follow the life of a key, from its making to the failure of a check. Step through the six places a reviewer looks:

Interactive · stage by stage Where a reviewer looks, in order Step through the six places in the order a review visits them. Each box names the questions of the table that belong to it.
Where a reviewer looks, in order, step 6 of 6. Showing Primitives, Keys, Messages, Checks, Transport, Failure. In focus: Failure.after each fixPrimitivesquestions 1 and 2Keysquestions 3 to 5Messagesquestions 6 and 7Checksquestions 8 to 10Transportquestion 11Failurequestion 12

The drawing shows the whole scene; its 6 steps are listed below.

Every step as text
  1. Primitives. Start with what the code uses. List every algorithm and mode, and every place a random value is made. A wrong choice here changes the answer to every later question.
  2. Keys. Follow each key from the place it is created to the place it is used. Ask who can read it, how many jobs it does, and whether a new key can replace it without losing data.
  3. Messages. Look at what is sealed. Each nonce must be new for its key, and each message must be tied to the record, user and purpose it belongs to.
  4. Checks. Look at what is verified. A tag, signature or token is checked before its content is used, secret values are compared in constant time, and the code, not the token, decides how a token is checked.
  5. Transport. Connections come next. Certificate and host name checks must be on in every client, including the one that a test setup builds and the one a script uses once.
  6. Failure. Last, make each check fail and read what comes out: the message, the status, the log line and the time taken. Every cause should give the same answer. A fix sends the review back to the first box.

A question that the diff cannot answer is a finding in itself, because the author must be able to say where a key lives and who can replace it.

# Question Passes when
1 Which algorithms and modes? Approved for the job, from a maintained library
2 Where does randomness come from? The system generator, for every key, salt, token and nonce
3 Where does each key live? In a key store, never in source or a log
4 How many jobs does a key do? One
5 Can a key be replaced? The format carries a version, so two keys can coexist
6 Is each nonce new? Unique for its key, by random draw or a counter that cannot repeat
7 What does a message belong to? Its id, owner and purpose, as associated data
8 Is it verified before use? Tag, signature or MAC checked before any data is used
9 How are secrets compared? In constant time, after format and length checks
10 Who chooses how a token is checked? The code, not the token
11 Is TLS verification on? Certificate and host name, in every client
12 What does a failure look like? One answer for every cause, with no secret in message, log or timing

Most of these are also questions that OWASP’s Top 10:2025 asks under Cryptographic Failures. A checklist does not make a reviewer an expert in a primitive, so a new protocol or a hand-built algorithm goes to a specialist.

Key idea

Follow each key from the place it is made to the place it is checked, and treat every question that the diff cannot answer as a finding.

Checkpoint

Check: The twelve questions

  1. Question 1 of 2 A diff adds token = hashlib.md5((user + str(time.time())).encode()).hexdigest() as a password-reset token. Which questions of the checklist does that one line raise? Choose all that apply.

    Choose every answer that is right.

    Show the answer

    Answer:

    • Where does randomness come from?
    • Which algorithms and modes?

    The hash fails the question about algorithms, and the input fails the question about randomness. The other questions are raised by other lines.

  2. Question 2 of 2 Every question passes except one, because decrypt throws one error for a bad tag and another for a bad length. Which question fails, and what is the smallest repair?

    Choose one answer.

    Show the answer

    Answer: What does a failure look like, repaired by catching the errors and giving one answer for every cause

    Question 12 asks for one answer for every cause. Catching the library's errors and returning a single refusal passes it.

Flashcards · 5 cards

Recall it, then check

Say the answer to yourself before you look: recalling it is what makes it stick.

  1. Why is cryptographic code hard to review?

    Because it keeps working when it is unsound. A fixed IV, a guessable token or an early-exit comparison still returns the right answer in every test that checks only the answer. Read the diff once for what it does, and again for what each key, nonce and check does.

  2. What are the twelve questions of a crypto code review?

    Which algorithms and modes? Where does randomness come from? Where does each key live? How many jobs does a key do? Can a key be replaced? Is each nonce new? What does a message belong to? Is it verified before use? How are secrets compared? Who chooses how a token is checked? Is TLS verification on? What does a failure look like? They follow the life of a key.

  3. What does a passing answer look like for questions 1 to 6?

    1: algorithms suited to the job, from a maintained library. 2: the system generator for every key, salt, token and nonce. 3: a key store, never source or a log. 4: one job per key. 5: a version in the format, so two keys can coexist. 6: a nonce unique for its key, by random draw or a counter that cannot repeat.

  4. What does a passing answer look like for questions 7 to 12?

    7: the message's id, owner and purpose as associated data. 8: tag, signature or MAC checked before any data is used. 9: constant-time comparison, after format and length checks. 10: the code, not the token, chooses how a token is checked. 11: certificate and host name verified in every client. 12: one answer for every cause, with no secret in message, log or timing.

  5. In a crypto code review, what is a question the diff cannot answer?

    A finding in itself: whoever wrote the code has to be able to tell you where each key is kept and who is able to replace it. A checklist does not make anyone an expert in a primitive, so anything new, such as a protocol or an algorithm built by hand, should be handed to a specialist.

First review: a Node.js helper that encrypts notes and signs links Pro

In this part:

  • Second review: passwords, reset codes and tokens in Python
  • Each finding maps to a weakness entry, a Top 10 category and a requirement
  • Severity follows who can reach the flaw and what it protects
  • A good comment names the risk, the fix and the test
  • Practise: write the first-pass scan
    • Write the first-pass scan a reviewer runs before reading
  • Interview questions
    • How do you structure a review of code that uses cryptography, and what do you do with a question the diff cannot answer?
    • A pull request encrypts invoices before they go to object storage. It uses AES-256-CBC with a random IV for each invoice, a key read from an environment variable, no MAC, and the invoice number as the file name. Review it: what do you write, in what order, and what do you ask for before you approve?
    • A scanner reports a static IV in two places: the handler of a public upload API and a helper in a test fixture folder. A manager asks you to rate both and to say which fix ships this week. How do you decide, and what do you write in the finding?
    • You review a service that verifies bearer tokens with a JWT library. The code calls verify(token, publicKey) and reads the subject from the result. List what you check, the tests you ask for and the ASVS requirements behind them.
  • Key takeaways

1 diagram · 4 runnable examples (JavaScript, Python, accounts_v2.py, notes_v2.mjs, review_tests.mjs, review_tests.py) · 1 exercise with sample tests · 3 interview answers · about 40 minutes

Opening this part with your pass…

This part opens with any MySmartCoPilot pass.

  • Pro pass · 1 week₹79$2.99
  • 30 days₹179$5.99
  • 1 year₹1,699$45

One payment; a pass never renews. The price shown is the total you pay: no fees or charges are added at checkout.

Choose a passI have a licence key

It also opens every other in-depth part in Learn and every Pro tool. Sales are final, except where the law gives you a right to withdraw, for example in the EU and the UK (refund policy).

Terms in this lesson

algorithm allowlist
A short list, fixed in the code, of the algorithms a token or message may use. Anything else, including a token that names no algorithm, is refused.
ASVS
The OWASP Application Security Verification Standard: numbered security requirements, each marked level 1, 2 or 3, that an application can be checked against.
CWE
Common Weakness Enumeration, a numbered catalogue of kinds of software weakness. A finding that cites a CWE entry names its flaw in a way that tools and other reviewers recognise.
injected clock
A clock passed to a module as an argument instead of read from the system, so that a test can move time forward in one line instead of waiting for it.
regression test
A test written for a fixed flaw. It fails on the code that had the flaw and passes on the fix, so the flaw cannot return unnoticed.

References

Related tools

Secret & Credential Leak Scanner Find leaked keys, tokens and passwords in code and logs before someone else does.

Report a problem with this lesson