How LLMs Are Being Used to Audit Cryptographic Code

Most crypto bugs aren't theoretical - they're implementation mistakes hiding in plain sight. LLMs are now being used as a first-pass auditor to surface them faster.

The Core Technique: Prompting for Weakness Patterns

Cryptographic vulnerabilities tend to cluster around a handful of known failure modes: reusing nonces (a number-used-once that must stay unique per operation), using ECB mode (a block cipher mode that leaks patterns in ciphertext), timing-dependent comparisons that leak secret length via response time, and weak entropy sources for key generation. These aren't obscure edge cases - they're the same bugs that have broken real systems for decades.

The practical approach is to feed a suspect code block to an LLM with a structured audit prompt rather than a generic "find bugs" request. The model doesn't replace a cryptographer, but it pattern-matches against known vulnerability classes faster than a manual read-through, making it a useful triage layer before a formal review.

Real Example

Here's a prompt pattern that gets concrete, actionable output instead of vague warnings:

You are a cryptographic security reviewer. Analyze this code for:
1. Nonce/IV reuse across encryptions
2. Use of ECB mode or other deprecated cipher modes
3. Non-constant-time comparisons on secrets (e.g., == on HMAC digests)
4. Weak or predictable key/seed generation

For each issue found, cite the specific line and explain the attack vector.
Do not flag theoretical issues - only confirmed anti-patterns.

[paste code here]

Run this against, say, a Python AES encryption wrapper, and the model will often correctly flag AES.new(key, AES.MODE_ECB) as a pattern-leaking mode, or a bare hmac_a == hmac_b comparison as vulnerable to timing attacks (where an attacker infers correctness by measuring how long comparison takes). The specificity of the prompt constrains the output - generic prompts produce generic warnings that are hard to act on.

Worth noting: LLMs hallucinate occasionally, so any flag it raises should be verified against the actual spec (NIST guidelines, RFC documentation) before treating it as confirmed. Think of it as a smart grep, not an oracle.

Key Takeaways

• Structured prompts scoped to known vulnerability classes outperform vague "audit this" requests - the model needs a checklist, not a blank canvas
• LLMs are strongest at flagging anti-patterns they've seen in training data (ECB mode, timing comparisons, nonce reuse) - novel cryptographic flaws still require human expertise
• This workflow fits best as a pre-review filter: surface the obvious mistakes quickly, then spend human review time on logic and design-level issues

Have you tried using an LLM to audit a specific crypto primitive or protocol implementation, and did it catch something a linter would have missed?

Sources referenced: HackerNews discussion - Discovering Cryptographic Weaknesses with Claude (222 points, 168 comments)