Finding Crypto Misuse

Finding crypto misuse: the finding is a recovery, not a weak primitive

Most crypto findings that matter are not "the algorithm is broken"; they are the algorithm used wrong in a way that hands you plaintext, a key, or a forgery. A cipher is only as safe as its nonce discipline, a signature only as safe as its randomness, a MAC only as safe as its construction. Finding crypto misuse means looking for the specific misuse patterns that collapse to a concrete attack, and proving the attack rather than flagging the primitive.

When to use

• You are reviewing code that encrypts, decrypts, signs, verifies, MACs, or hashes.
• A protocol or service rolls its own crypto or composes primitives by hand.
• You need to separate an exploitable misuse from a cosmetic "weak crypto" alert.

Scope check

Analyze crypto in code you own or are authorized to test. Demonstrate recovery or forgery only against your own keys and data. If you can't name the authorization, stop.

The loop

1. Inventory the crypto operations and their inputs. List every place the code encrypts, decrypts, signs, verifies, MACs, or hashes, and for each capture the primitive, the mode, and where the key, nonce or IV, and randomness come from. The misuse lives in the inputs, not the primitive name.

2. Hunt nonce and IV reuse. For any stream or counter/GCM mode, does a (key, nonce) pair ever repeat across messages (a fixed IV, a counter that resets, a random nonce in too small a space)? Reused keystream lets an attacker combine two ciphertexts to strip the key, and GCM nonce reuse additionally leaks the authentication key, enabling forgery. This is the highest-yield check.

3. Hunt signature-randomness reuse. For ECDSA or DSA, is the per-signature secret drawn fresh from a strong source every time, or can it repeat or be predictable? Two signatures under the same secret reveal the private key by simple algebra. Look for fixed, derived, or low-entropy per-signature values in signing code.

4. Hunt oracle and construction flaws. Does decryption or unpadding reveal, through an error, a timing difference, or a distinct response, whether padding was valid? That is a padding oracle, and it decrypts ciphertext without the key. Is a MAC built as hash(secret then message) on a length-extendable hash? That is forgeable by length extension. Check for these constructions specifically.

5. Hunt key and randomness hygiene. Are keys hardcoded, reused across contexts, derived from low-entropy material, or generated from a non-cryptographic random source? Is a fast hash used where a slow password hash is required, or an unsalted hash where reversal matters? Each is a concrete downgrade, not a style issue.

6. Prove the concrete attack and record. A crypto finding is confirmed by naming the recovery or forgery it enables (recover this key, decrypt this ciphertext, forge this token) and, where possible, demonstrating it. Rate by that impact. Kill the lead if the input discipline holds: unique nonces, fresh randomness, constant-time comparison, sound construction.

Where crypto collapses

• The nonce is the whole security of the mode. Repeat it once and confidentiality, and for GCM integrity, is gone.
• Signature randomness is a secret. Reused or predictable per-signature randomness is a private-key disclosure.
• An error message is an oracle. Any observable difference on decrypt can be a decryption oracle. Make failures indistinguishable and constant-time.
• "It uses AES" says nothing. The mode, the nonce, and the key handling decide security, not the cipher name.

Worked example (a confirm and a kill)

Confirm. A service encrypts each session token with a counter mode and a fixed, hardcoded IV, the same key for all users. Two tokens share keystream; combining them cancels the keystream and, with one known token, recovers the other's plaintext. Confirmed keystream reuse, high, remediation = a unique random nonce per message, never a fixed IV, and separate keys per context.

Kill. A service signs with ECDSA drawing a fresh per-signature secret from a cryptographic source, uses a distinct random nonce per encryption, compares MACs in constant time, and returns an identical error on any decrypt failure. Repeated inspection finds no reuse or oracle. Killed, kill_reason = "unique nonces and fresh signing randomness, constant-time verification, indistinguishable decrypt failures; no recovery or forgery path."

Rationalizations to reject

• "It uses a strong algorithm." → Strength is in the usage. A strong cipher with a reused nonce is broken.
• "A random-nonce collision is astronomically unlikely." → Only with a large space and a strong source. Check both; small or weak spaces collide.
• "It's just an error message." → Distinguishable decrypt errors are an oracle. Unify them and make timing constant.
• "We hash the password." → With a fast, unsalted hash that is reversible at scale. Use a slow, salted password hash.

Executing this in practice

You need to see every crypto call site with its key, nonce or IV, and randomness source, and to reason about whether any of those repeat or leak. A call graph and dataflow into the nonce and key arguments help you prove reuse; the misuse-pattern checklist and the concrete-attack requirement are the method.

Related

• adjudicating-taint-paths - tracing whether attacker-controlled or repeated values reach a nonce or key.
• writing-vuln-reports - turning a recovery or forgery into a reproducible writeup.
• FINDING-SCHEMA.md - source = the misused key, nonce, or randomness, sink = the recovery, decryption, or forgery it enables.