No, an AI Did Not Break AES

No, an AI did not break AES

Read the headline version of Anthropic's new research and you might think the sky is falling: a language model found weaknesses in AES and a NIST post-quantum candidate. Close the laptop, TLS is over.

It isn't, and the gap between what happened and what people will say happened is the whole story. Every result in this work targets a weakened cipher — a reduced-round variant or a scheme still in standardization. Nothing you ship touches these attacks. Full-strength AES-128 remains exactly as sound this week as it was last week. What actually changed is subtler and, for anyone who builds systems, more interesting: cryptanalysis just got a new kind of labor input, and the economics of finding a flaw shifted.

What was actually found

The two headline results are worth separating, because they represent different things.

The first is against HAWK, a lattice-based signature scheme that made NIST's third round of post-quantum signature candidates. HAWK is Falcon's cleaner cousin — same lattice pedigree, but it drops Falcon's gnarly floating-point sampling in favor of integer arithmetic, which makes it attractive for constrained devices. Working with one Anthropic researcher over roughly a week, Claude improved a key-recovery attack by exploiting an automorphism in the lattice structure, cutting the effective security of HAWK-256 dramatically. Here's the thing that matters: this is exactly what NIST's process is for. A candidate is a candidate precisely so that people beat on it before it becomes a standard. Finding a weakness in a round-three submission is the system working, not failing. Independent academics have been publishing HAWK cryptanalysis for a while now; this is one more entry, arrived at faster.

The second result is the one that should make cryptographers sit up. A scaffolded, largely autonomous run produced a meet-in-the-middle attack on 7-round AES-128 — seven of the ten rounds real AES uses — with a claimed several-hundred-fold speedup over prior work via a new fingerprinting trick. The plaintext requirement is astronomical (on the order of 2¹⁰⁵), so it's pure theory. But reduced-round AES cryptanalysis is a decades-deep field where progress comes in small, hard-won increments from people with PhDs in the subject. A machine contributing a genuine step there is a different claim than "AI finds bugs."

Rounding out the work: practical-ish attacks on reduced-round LEA and Serpent, plus minor sub-10× improvements against Salsa20, Poseidon, and SHA-1. All reduced-round. All theoretical against real parameters.

The number that actually matters

Each headline attack cost about $100,000 in API spend to develop. Hold onto that figure, because it reframes the entire debate.

The doom reading — "AI breaks crypto for anyone with a prompt" — collapses against a six-figure price tag per result, months of expert validation, and a payoff that is a reduced-round academic curiosity. No attacker is spending $100k and a month of a cryptographer's time to weaken a cipher nobody deploys. That's not an economically motivated adversary. That's a research budget.

Which is the correct frame. This is a research accelerator, not a weapon. The right comparison isn't a hacker at a keyboard; it's a grad student who costs a stipend and takes two years. Against that baseline, $100k for a week of work is either expensive or cheap depending entirely on how the cost curve moves — and cost curves for this kind of thing tend to move one direction. The interesting question is not whether AI can do novel cryptanalysis. This work says it can, at least with a capable human in the loop. The question is what a 10× cost reduction does to the field's throughput.

What developers should actually take from this

If you write application code, your to-do list from this research is short, because you were already supposed to do all of it:

• Don't roll your own crypto. This has been the rule forever, and every result here reinforces it. The attacks land on primitives; use vetted libraries that implement full-strength, standardized primitives and you are outside the blast radius entirely.
• AES-GCM, ChaCha20-Poly1305, Ed25519 — unchanged. Nothing in this research touches full-round deployed ciphers. If your threat model was fine yesterday, it's fine today. Resist the urge to "upgrade" in a panic; panic migrations cause more outages than they prevent.
• If you're planning a post-quantum migration, prefer the finished standards. ML-KEM and ML-DSA are ratified. HAWK is a candidate — promising, but this is precisely the phase where it might not survive. Don't build production dependencies on round-three submissions, and this result is a concrete reminder why.

The one genuinely new thing to internalize sits upstream of your code: the review process that gives you confidence in a cipher is about to get a new participant. That cuts both ways. Defenders and standards bodies get a tool that can stress-test candidates faster and cheaper than the human-only pipeline ever could — arguably the best possible time to find HAWK's weakness is now, before anyone deploys it. But the same tool, aimed at whatever gets standardized and shipped, is a capability that didn't exist before, and the disclosure norms and cost curve around it are being written in real time.

The quiet bottleneck

One detail from the work deserves more attention than the attacks themselves: validating the AES result took human researchers about a month. Generation got cheap; verification did not.

That inversion is the real preview of where this goes. When a model can generate a hundred plausible cryptanalytic arguments overnight and each one takes a domain expert a month to confirm or refute, the bottleneck moves entirely onto human judgment — and human judgment doesn't scale on an API. The bragging-rights headline is that a model did novel math. The load-bearing insight is that we don't yet have a cheap way to know when it's right. Solve verification and this becomes a routine part of how ciphers get vetted. Don't, and you get a firehose of unfalsifiable claims. For now, the correct posture is calm: impressive research, real methodological shift, zero reason to touch your TLS config.