AI Just Started Breaking Crypto — And the Real Question Isn't the One You'd Expect

Cryptography was supposed to be AI’s last sanctuary. Code review, sure. Bug hunting, fine. But algorithms backed by mathematical proof? Statistical pattern matching was never going to touch those. Anthropic’s recent work on using Claude for cryptanalysis suggests that assumption deserves a much harder look.

Worth saying up front: this isn’t a hot topic right now. Search the last month of security discussion and you’ll find almost nothing substantive. Partly that’s the barrier to entry — cryptanalysis doesn’t produce viral threads. But it’s also a signal that the industry hasn’t finished doing the math on what this changes.

What “Secure” Actually Means

There’s a distinction here that gets collapsed constantly, and everything depends on it.

Breaking AES or RSA mathematically is one thing. Finding holes in the code that implements them is something else entirely.

The first remains out of reach. Brute-forcing AES-256 requires more time than the universe has existed, and no amount of LLM capability changes that. Math is math.

The second is where crypto actually dies. In practice, nearly every real-world cryptographic failure traces to implementation, not algorithm. Predictable random number generators. Comparisons that aren’t constant-time and leak through timing. Reused nonces. Botched padding validation. Heartbleed was implementation. ROCA was implementation. Sony’s PS3 ECDSA disaster — signing every message with the same nonce, which let anyone recover the private key with basic algebra — was implementation.

And implementation review is close to the thing LLMs are best at. Read code. Recognize patterns. Flag the part that looks wrong.

What AI Catches Well

Practitioners working with these tools report a consistent pattern of strengths.

Side-channel candidates top the list. Branches that depend on secret values. Comparison functions that return early. These leak timing information, and they’re exactly the kind of tedious detail human reviewers skim past on hour six. To a model, they’re a bright flashing signal.

Protocol state machine gaps are similar. The classic shape is a handshake where sending messages in an unexpected order lets you skip an authentication step. Enumerating every path by hand takes days. A model sweeps it in minutes.

API misuse is the most common of all, and the most embarrassing. Modern crypto libraries are built to be hard to misuse. People misuse them anyway — ECB mode, hardcoded IVs, keys derived from something that isn’t a KDF. Models catch these with near-perfect recall, because the patterns are unambiguous and well documented.

The weaknesses are equally clear. Inventing genuinely new mathematical attack techniques — designing a differential or lattice-based attack from first principles — still belongs to human researchers. But applying known techniques to new targets is already substantially automatable. And that’s where the overwhelming majority of real-world vulnerabilities live.

Which Way Does the Asymmetry Tilt

This is where reasonable people split.

The attacker-advantage case: defenders have to close every hole, attackers need one. Lower the cost of searching and you raise the odds of finding that one. Attackers also get to eat false positives for free. A model flags 100 issues, 99 are noise, the hundredth is real — that’s a win. Defenders pay engineering hours for every one of those 99.

The defender-advantage case is stronger than it first appears. There isn’t that much cryptographic code in the world. The libraries that matter — OpenSSL, BoringSSL, libsodium, ring — fit on one hand, and they already have audit teams and continuous fuzzing attached. Drop AI review into CI and vulnerabilities die before they ship. Reviewing code before release, rather than after, is a structural advantage attackers can’t replicate.

My read: defense wins long-term, attack wins short-term. Wiring AI audit into a pipeline takes time. Procurement, security review of the tool itself, false-positive triage budget, someone who owns the process. Attackers face none of that friction. An API key and an afternoon.

And the real exposure was never OpenSSL. It’s the hundreds of thousands of lines of in-house crypto that nobody has ever audited. IoT firmware written in 2016 and shipped unchanged since. Open source libraries whose maintainer stopped answering email in 2021. Point a capable model at that surface and nobody — including the people who own it — knows what comes back.

What To Actually Do

Concrete steps, in order of how fast they pay off.

If you have homegrown crypto, run an AI audit on it now. Attackers will be running one shortly. Seeing it first is the whole game.

Tag and inventory your crypto-touching code. A surprising number of organizations can’t answer where cryptography lives in their codebase. No inventory means no audit, which means the answer arrives from someone else.

And do not trust findings on sight. LLMs are exceptionally good at producing confident, plausible false positives — and in cryptographic code, a wrong fix is frequently worse than the original bug. A developer who “hardens” a comparison and accidentally reintroduces a timing leak has made things worse while feeling productive. An unverified patch isn’t a patch.

The Part That Lingers

Cryptography was never special because the math was hard. It was special because the number of people who could handle it correctly was vanishingly small. That scarcity is what’s collapsing. The mathematical wall stands exactly where it did — but the crowd standing in front of it just grew by orders of magnitude.

So: how many lines of cryptographic code are in your codebase, and when was the last time anyone looked at them? Most teams don’t know. Until now, not knowing was survivable, because exploiting that ignorance required an expert.

That’s the assumption that’s coming apart.