reviewing-cryptography

Reviewing Cryptography

Almost no real system is broken by cryptanalysis. They are broken by misuse: a reused nonce, unauthenticated ciphertext, a comparison that returns early, a key checked into git. Review for misuse, and leave primitive design to cryptographers.

When to Use

• Auditing code that encrypts, decrypts, signs, verifies, or hashes
• Reviewing key management, rotation, and storage
• Assessing TLS/mTLS configuration and certificate validation
• Reviewing JWT, session token, and API signature schemes
• Checking password and secret storage
• Evaluating randomness quality for security-relevant values

When NOT to Use

• Designing a new primitive or protocol — that needs a cryptographer and formal review, not a code audit
• Breaking cryptography in a CTF — different discipline; use solving-oriented offensive skills and known-attack tooling
• General code review — use auditing-code-for-vulnerabilities
• Password cracking — use cracking-passwords

The Misuse Checklist

Work through these in order. Each has caught real production breaks.

1. Is the ciphertext authenticated?

Encryption without authentication is the single most common serious finding. CBC or CTR without a MAC means an attacker can modify plaintext — and with a decryption oracle, recover it (padding oracle).

Good:  AES-GCM, ChaCha20-Poly1305, AES-CBC + HMAC (encrypt-then-MAC)
Bad:   AES-CBC alone, AES-ECB (ever), CTR without a MAC, MAC-then-encrypt

rg -n 'AES/ECB|AES\.MODE_ECB|CipherMode\.ECB|"AES"\)' -i
rg -n 'AES/CBC/PKCS5Padding|MODE_CBC|createCipheriv\(.*cbc' -i

If you see CBC, find the MAC. If there is no MAC, that is a finding regardless of how the ciphertext is transported.

2. Nonce and IV handling

Mode	Rule	Failure
GCM / ChaCha20-Poly1305	Never reuse a (key, nonce) pair	Catastrophic: reveals the auth key, forgery becomes trivial
CBC	IV must be unpredictable and random per message	Chosen-plaintext attacks (BEAST-class)
CTR	Never reuse a counter with the same key	Keystream reuse; XOR of plaintexts