Claude Cryptography Bug Hunt 2026: Run It Yourself

Anthropic published “Discovering cryptographic weaknesses with Claude” this week, and the claim is narrow enough to be interesting: Claude models, driven agentically, found real Claude cryptographic weaknesses in production-grade cryptographic implementations — not textbook toy ciphers. That lands in the same news cycle as Anthropic and OpenAI both telling Washington to consider slowing frontier AI development, a strange pairing to read back to back. The part worth your attention is not the safety framing but the reproducibility: the harness described in the post is essentially Claude Code with a fuzzer and a differential oracle, and you can stand it up this afternoon. Don’t take the blog post on faith. Point the same setup at your own code and see what falls out.

What’s actually new about Claude cryptographic weaknesses

Prior AI-for-security work almost always led with memory safety — buffer overflows, use-after-free, the stuff sanitizers already catch and fuzzers already find. Cryptographic bugs are a different animal. A broken AES implementation still encrypts and decrypts correctly. Tests pass. CI is green. The failure is mathematical: a nonce reused across messages, a modular reduction that leaks a bit of the private key through timing, a signature verification that accepts s = 0, a padding check that returns early. None of that shows up as a crash, so the traditional automated toolchain is close to blind to it. Anthropic’s contribution is showing that a model reading the implementation against the spec catches a meaningful slice of exactly this class.

The methodology matters more than the count. Per the Anthropic cryptography research writeup, the models were not asked “find bugs in this file.” They were given the reference specification, the implementation, and tooling — the ability to compile, run test vectors, write differential harnesses against a known-good library, and iterate on failures. That is an agentic loop, not a single-shot code review, and the distinction is the whole ballgame. Single-shot Claude Opus code review on a crypto file produces a plausible list of concerns, most of which are wrong. The same model given a compiler and thirty minutes to test its own hypotheses produces a much shorter list, most of which are right. Verification converts speculation into a finding.

The honest caveats: the reported flaws skew toward implementation-level errors rather than novel cryptanalysis, several were in code with known provenance issues, and Anthropic controls both the evaluation and the scoring. Nobody has independently replicated the numbers. But “AI finds cryptographic implementation flaws that fuzzers structurally cannot find” is a much weaker and much more useful claim than “AI breaks cryptography,” and the weaker claim looks defensible. Treat it as a new tool in the AI red teaming crypto toolbox, not a phase change.

Why it matters

• A new bug class becomes tractable. Constant-time violations, nonce misuse, weak parameter validation, and missing point-on-curve checks have historically required a specialist reading code line by line. That specialist is expensive and scarce. This shifts the first pass to something you can run in parallel across an entire repository.
• Your dependency tree is the real target. Almost nobody writes their own AES anymore, but plenty of teams ship hand-rolled JWT verification, custom HMAC comparison, homegrown key derivation, or a vendored copy of a crypto library that stopped receiving patches in 2021. That is where AI vulnerability discovery earns its keep.
• Defenders get the capability at the same moment attackers do. There is no exclusivity window. The same Claude Code security audit loop is available to anyone with an API key, so the practical question is whether you run it against your code before someone else does.
• Verification is the whole discipline. An agent that reports a timing leak without a measurement is generating a hypothesis. Any workflow you build must force the model to prove its claim with a compiled, executed test — otherwise you are triaging fiction at scale.
• The policy tension is now explicit. A lab publishing offensive-capability results the same week it asks regulators to consider slowing down is not necessarily inconsistent, but it does tell you the capability is real enough to be worth the awkwardness.
• Audit economics change. If a model clears the shallow findings first, a human crypto auditor’s hours go to protocol design and the genuinely hard cases — a better use of the scarcest resource in the field.

How to run the Claude cryptographic weaknesses workflow today

Below is a working approximation of the harness. It assumes Claude Code and a Unix-like toolchain. The critical design choice: the model must never report a finding it has not executed.

1. Install Claude Code and set up a scratch workspace with the target and a reference implementation side by side.

   npm install -g @anthropic-ai/claude-code
   mkdir -p ~/crypto-audit && cd ~/crypto-audit
   git clone --depth 1 https://github.com/your-org/target-lib target
   git clone --depth 1 https://github.com/openssl/openssl reference
   cd target && claude

2. Give the agent explicit rules of engagement in CLAUDE.md at the repo root. This file is the highest-leverage artifact in the whole process — it is what suppresses the plausible-but-wrong findings.

   # Crypto audit rules
   
   You are auditing cryptographic implementations. Rules:
   
   1. Never report a finding you have not demonstrated by executing code.
      Every finding requires: a compiled reproduction, the command you ran,
      and the observed output.
   2. Compare against the reference spec, not against your intuition. Cite
      the exact RFC/FIPS section number for each claimed deviation.
   3. Prioritize: nonce/IV reuse, non-constant-time comparison, missing
      parameter validation, modular reduction errors, early returns in
      verification paths, weak RNG seeding, signature malleability.
   4. If a test vector passes, say so. Passing vectors are evidence.
   5. Rank findings by exploitability, not by novelty. State explicitly
      when a deviation is spec-noncompliant but not exploitable.
   6. Do not modify files under reference/.

3. Pull the official test vectors before the agent starts guessing. Real vectors are the cheapest source of ground truth you will find.

   mkdir -p vectors && cd vectors
   curl -sO https://raw.githubusercontent.com/google/wycheproof/master/testvectors_v1/aes_gcm_test.json
   curl -sO https://raw.githubusercontent.com/google/wycheproof/master/testvectors_v1/ecdsa_secp256r1_sha256_test.json
   curl -sO https://raw.githubusercontent.com/google/wycheproof/master/testvectors_v1/rsa_pss_2048_sha256_mgf1_32_test.json
   ls -la

4. Run the audit with an explicit, verification-first prompt. Use Opus for the reasoning-heavy pass; the cost difference is irrelevant next to a missed key-recovery bug.

   claude --model claude-opus-5 --permission-mode acceptEdits \
     "Audit src/ecdsa.c against RFC 6979 and SEC 1 v2.0.
   
   For each function:
   1. Read the implementation fully before forming any hypothesis.
   2. Build the project and run every Wycheproof vector in vectors/
      against it. Report pass/fail counts per test group.
   3. For any suspected deviation, write a standalone C reproduction in
      repro/, compile it, run it, and paste the actual output.
   4. Check specifically: is the nonce derived deterministically per
      RFC 6979 section 3.2? Is s normalized to the lower half of the
      curve order? Is the point-on-curve check performed before any
      scalar multiplication? Are comparisons constant-time?
   
   Write findings to FINDINGS.md. Include a section titled
   'Unverified hypotheses' for anything you could not demonstrate.
   Do not promote a hypothesis to a finding without executed proof."

5. Add a timing harness so constant-time claims are measured rather than asserted. This is the most common place where a model will hand-wave, and the fix is to make measurement mandatory.

   cat > repro/timing.c <<'EOF'
   #include <stdint.h>
   #include <stdio.h>
   #include <string.h>
   #include <time.h>
   
   extern int target_verify_mac(const uint8_t *a, const uint8_t *b, size_t n);
   
   static uint64_t now_ns(void) {
       struct timespec ts;
       clock_gettime(CLOCK_MONOTONIC, &ts);
       return (uint64_t)ts.tv_sec * 1000000000ull + ts.tv_nsec;
   }
   
   int main(void) {
       uint8_t a[32], b[32];
       memset(a, 0xAA, sizeof a);
       for (int diff_at = 0; diff_at < 32; diff_at += 8) {
           memcpy(b, a, sizeof b);
           b[diff_at] ^= 0xFF;
           uint64_t best = ~0ull;
           for (int i = 0; i < 200000; i++) {
               uint64_t t0 = now_ns();
               target_verify_mac(a, b, sizeof a);
               uint64_t dt = now_ns() - t0;
               if (dt < best) best = dt;
           }
           printf("first difference at byte %2d: %llu ns\n",
                  diff_at, (unsigned long long)best);
       }
       return 0;
   }
   EOF
   gcc -O2 -o repro/timing repro/timing.c -L. -ltarget && ./repro/timing

   A rising staircase across the printed rows means the comparison short-circuits and you have a real leak. A flat profile means the comparison is constant-time and the model’s hypothesis was wrong — an equally valuable result.

6. Fan out across a repository once the single-file loop works. Keep each agent narrowly scoped; broad prompts produce broad, useless output.

   for f in $(grep -rlE 'memcmp|AES|EVP_|BN_mod|RAND_|nonce|HMAC' src --include='*.c'); do
     claude -p "Audit $f for the crypto bug classes in CLAUDE.md. Verify every
   claim by executing code. Output JSON: {file, findings:[{severity, cwe,
   rfc_section, repro_command, observed_output}]}. Empty array if nothing
   verified." --output-format json >> audit-results.jsonl
   done
   wc -l audit-results.jsonl

7. Wire the verified subset into CI so regressions get caught on the pull request rather than in a disclosure email.

   - name: Crypto review on changed files
     run: |
       CHANGED=$(git diff --name-only origin/main...HEAD -- '*.c' '*.h' '*.go' '*.rs')
       [ -z "$CHANGED" ] && exit 0
       claude -p "Review these changed files for cryptographic regressions:
       $CHANGED. Flag ONLY verified issues with an executed reproduction.
       Exit nonzero if any high-severity issue is verified." \
         --allowedTools "Read,Grep,Bash(make *),Bash(./repro/*)"
     env:
       ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}

How it compares

Approach	Finds crypto logic flaws	False positive rate	Setup cost	Best used for
Agentic Claude Opus code review	Yes — spec deviations, nonce misuse, timing leaks	Moderate; drops sharply when execution is mandatory	Low (hours)	First-pass audit of hand-rolled or vendored crypto
libFuzzer / AFL++	Rarely — crypto bugs usually do not crash	Very low	Medium	Parsers, ASN.1 decoders, memory safety
Wycheproof test vectors	Yes, for known bug patterns only	Near zero	Very low	Baseline correctness gate; run this first, always
ctgrind / dudect / valgrind	Timing side channels only	Low	Medium	Confirming constant-time behavior empirically
Formal verification (HACL*, Fiat-Crypto)	Yes, with proof	Zero	Very high (months)	New primitives you intend to ship for a decade
Human crypto auditor	Yes, including protocol-level design flaws	Very low	High (cost and scheduling)	Protocol design, novel constructions, final sign-off

These are complements, not substitutes. The efficient ordering: vectors first because they are nearly free, then the agentic pass to clear shallow findings, then timing measurement on anything the agent flags, then a human on whatever survives. Formal methods stay reserved for primitives you are committing to long-term.

What’s next

Watch for independent replication. Right now the strongest version of this claim rests on Anthropic’s own evaluation of Anthropic’s own models — not a criticism so much as a description of where the evidence stands. The signal to wait for is a third party — an academic group, a CTF team, a security vendor with no stake in the outcome — publishing findings from the same class of workflow against code Anthropic did not select. If that lands, the capability is established. If six months pass without it, the original result was probably narrower than the framing suggested.

The second thing to watch is where these cryptographic implementation flaws actually get found. The interesting frontier is not OpenSSL, which has thousands of eyes on it. It is the long tail: embedded TLS stacks, firmware key management, smart contract signature verification, and the enormous volume of application-layer code that reimplements HMAC comparison because == looked fine at the time. Expect the first genuinely notable public results from that tail, not from the well-audited core.

The third is the disclosure pipeline. If agentic auditing scales the way the setup above suggests, maintainers of small crypto libraries are about to receive far more reports than they can triage, and a meaningful fraction will be unverified model output. The teams that establish norms early — mandatory executed reproductions, severity claims backed by measurement, no bulk submissions — will be the ones whose reports still get read in a year. Build that discipline into your harness now, because the alternative is your findings landing in the same bucket as the noise.

Frequently Asked Questions

Did Claude actually break any real-world cryptography?

No, and the research does not claim it did. The findings are implementation-level defects — deviations from a specification that weaken or break the security properties of a particular piece of code. That is meaningfully different from cryptanalysis of the underlying algorithm. AES is not broken. Somebody’s AES-GCM wrapper reusing a nonce is a real and exploitable bug, and that is the category in play.

Which model should I use for a Claude Code security audit?

Opus for the audit reasoning, where the work is holding a specification and an implementation in mind simultaneously and forming testable hypotheses. Sonnet handles the mechanical parts well and cheaply — running vectors, compiling reproductions, formatting results — so a split setup is reasonable at scale. For a single high-value library, run Opus for everything and stop optimizing token spend.

How do I keep the model from inventing vulnerabilities?

Make execution non-negotiable. A finding with no compiled reproduction, no command, and no captured output is a hypothesis, and it belongs in a separate section of the report. Requiring an exact RFC or FIPS section number for each claimed deviation is the second-best filter, because it is hard to cite a section that does not say what you claimed it said. Both rules go in CLAUDE.md where every agent invocation picks them up.

Is it safe to point this at code I do not own?

Reading public source and running it in a sandbox is ordinary security research. Publishing findings without coordinated disclosure, or testing against systems you have no authorization to test, is not. Get written authorization before auditing a third party’s code in any engagement context, and follow the project’s stated disclosure policy for open source. The tooling being easy does not change the rules.

Does this replace a professional crypto audit?

No. It changes what you hand the auditor. An agentic pass clears the shallow class of bugs, so the expensive human hours go to protocol design, composition failures, and the reasoning that requires genuine domain expertise. For anything you are shipping to real users with real money behind it, the human sign-off still matters.

Why publish offensive capability research while asking regulators to slow AI down?

Because the capability exists whether or not it is published, and defenders benefit from knowing it does. That is the standard argument and it is a reasonable one. The tension is still worth naming: a lab demonstrating that its models find real security flaws, in the same week it argues for caution, is telling you the results are substantial. Read the demonstration as the more informative of the two signals.