Short answer
On 28 July 2026 Anthropic published two cryptanalytic results found by Claude Mythos Preview. The first cuts the effective key strength of HAWK, a post-quantum signature candidate, roughly in half. The second speeds up the best known attack on seven-round AES by 200 to 800 times. Both are real mathematics. Neither touches anything you run.
HAWK has never been standardised or deployed, and real AES uses 10, 12 or 14 rounds rather than seven. Your certificates, your TLS handshakes and your signed binaries are exactly as safe today as they were the day before the announcement.
What changed is the cost of finding this kind of flaw. A weakness that survived two rounds of NIST review over two years fell to about 60 hours of machine work and roughly $100,000 of compute. That is the part worth paying attention to.
What Anthropic actually announced in July 2026
Two separate results, produced by different processes, published together. Keeping them apart is the whole trick to reading this story correctly, because press coverage mostly collapsed them into one headline about AI breaking encryption.
The first is a key-recovery improvement against HAWK, a lattice signature scheme currently sitting in the third round of NIST's additional-signatures competition. A researcher and the model worked together in an agentic harness with Python and Sage available, across roughly a week of wall-clock time. The attack runs end to end, so verifying it was straightforward.
The second is an improvement on the 2013 Derbez–Fouque–Jean attack against seven-round AES. The model produced it with almost no human technical input, after initially arguing that no improvement was available. It invented a technique it named the Möbius Bridge, exploiting algebraic structure in the AES S-box to remove one of the guesses an attacker otherwise has to make. Anthropic reports around one billion output tokens for that run, and two researchers spent close to a month confirming the result was correct.
Anthropic disclosed the HAWK attack to the scheme's authors in June and coordinated publication with the NIST post-quantum mailing list. Its own post is blunt about the impact: neither result affects today's computer systems, and no production software has to change.
| Target | What changed | Where it is used | Action for you |
|---|---|---|---|
| HAWK (NIST additional-signatures candidate) | Effective key strength roughly halved | Not standardised, not deployed | None. Watch NIST's round 3 outcome. |
| AES, 7 rounds (research variant) | Best known attack 200–800x faster | Not used anywhere | None. |
| AES-128 / 192 / 256 (10 / 12 / 14 rounds) | No meaningful attack; margin intact | TLS, disk and backup encryption | None. |
| RSA and ECDSA in your certificates | Untouched by this research | Every public certificate today | Continue planned PQC migration. |
| ML-KEM, ML-DSA, SLH-DSA, FN-DSA | Untouched; standardised separately | Hybrid key exchange shipping in browsers | Enable hybrid KEX where supported. |
| LEA, Serpent-128, Salsa20, Poseidon, SHA-1 | Preliminary gains reported, papers pending | Varies; SHA-1 already deprecated | Reassess when the papers land. |
The HAWK attack: how AI halved a post-quantum candidate’s key strength
What is the HAWK signature scheme?
HAWK is a signature scheme from Ducas, Postlethwaite, Pulles and van Woerden, published in 2022. It is a relative of Falcon in spirit but not in construction: where Falcon leans on NTRU lattices and Gaussian sampling, HAWK builds on a module version of the Lattice Isomorphism Problem. Two lattices can be the same lattice viewed through different bases, and telling whether they are is hard. HAWK turns that into signatures.
The payoff was engineering rather than theory. HAWK signs and verifies quickly, its keys and signatures are compact, and it avoids the floating-point Gaussian sampling that makes Falcon genuinely difficult to implement without leaking timing information. For anyone who has had to ship a constant-time signature implementation, that is not a small thing. It is also why HAWK attracted attention as a candidate in the on-ramp NIST opened to add signature diversity beyond the algorithms already standardised.
What the automorphism attack on HAWK actually found
The model identified a nontrivial automorphism in HAWK's lattice that nobody had exploited. An automorphism is a symmetry: a way of mapping the structure onto itself that leaves it looking the same. Symmetry is a gift to an attacker, because it means large parts of the search space are copies of each other and only one copy needs searching. Feed that into lattice enumeration and the work drops.
The attack stays exponential, so HAWK is weakened rather than broken. The practical statement is that the effective key strength falls by about half, which means HAWK would need roughly double the key sizes to hold its intended security level. Since compactness and speed were the reasons to pick HAWK over the standardised alternatives, doubling the keys removes most of the argument for it. An independent ePrint paper, 2026/1593, gives a formal reduction consistent with a weakening of this severity.
Why a broken NIST candidate is the review process working
NIST's competition rounds exist precisely so that candidates get attacked in public before anyone deploys them. Rainbow and SIKE both died mid-competition, SIKE spectacularly, on a laptop, in about an hour. HAWK joining that list is not a failure of post-quantum cryptography. It is the reason the review period is years long rather than months.
The uncomfortable version of the same sentence: HAWK survived two rounds of expert human scrutiny over two years, and then fell in 60 hours to a system whose human operator was not a lattice specialist.
The 7-round AES attack: is AES-256 still safe?
Why cryptanalysts attack reduced-round AES instead of the real thing
AES applies its round function repeatedly: 10 times for AES-128, 12 for AES-192, 14 for AES-256. Each round mixes the state further, and after enough of them the relationship between plaintext and ciphertext is beyond any technique we have. Nobody can attack the full cipher, so the field attacks weakened versions and watches how far up the round count it can climb. The gap between the best attacked round count and the real one is the security margin.
Seven rounds against ten is a wide margin, and it has barely moved in two decades. Even the best result against full AES-128, the biclique attack, needs on the order of 2126 operations. Shaving a factor of four off a number that large is a paper, not a threat.
How the Möbius Bridge technique speeds up the attack
The prior best attack on seven-round AES in the single-key setting needed roughly 2105 chosen plaintexts and 299 time. The model's technique exploits algebraic structure in the S-box, the substitution table that provides AES's nonlinearity, to eliminate one of the values an attacker would otherwise have to guess. Removing a guess removes a multiplicative factor from the work, and the reported gain is 200 to 800 times depending on the parameters.
For scale: 299 divided by 800 is still around 289, against a variant of AES that does not exist outside academic papers. That is what a genuinely interesting cryptanalytic result looks like from the inside. It is also why nobody in the field is telling you to stop using AES-256.
Anthropic's own framing is worth quoting on this point: neither result has a practical impact on today's computer systems, and no production software will have to change. When the organisation with every incentive to make its model look dangerous says that, take it at face value.
AI cryptanalysis vs AI bug hunting: why this result is different
Models have been finding security bugs for a while now. Earlier in 2026 the same family of models was reported finding thousands of vulnerabilities in real codebases, including cryptographic libraries. Every one of those was an implementation bug: a buffer handled wrongly, a check in the wrong order, a nonce reused. Serious, worth fixing, and fundamentally a matter of reading code carefully at scale.
These two results are not that. They are flaws in the mathematics of the designs themselves, of the kind that get found by people who have spent careers on lattice theory or differential cryptanalysis, and they were found after those people had already looked. That is a different capability, and the honest reading is that it is a qualitative step rather than more of the same.
Two caveats keep it grounded. Human researchers built the scaffolding both results came out of, and human researchers spent a month verifying the AES one. Novel mathematics that nobody can check is not yet a result.
LEA, Serpent and the follow-up results that are still unpublished
Anthropic mentioned several further findings without publishing papers for them. Treat these as preliminary; the numbers below are the company's own prose summary and have not been through peer review.
- LEA, 13 rounds. The lightweight cipher standardised in ISO/IEC 29192-2 runs 24 rounds in full. Previous cryptanalysis of the 13-round version needed 298 plaintext pairs. The reported attack recovers a key with under 230 plaintexts, in under an hour on a desktop. Anthropic states it does not extend to the full cipher.
- Serpent-128, 6 rounds. A practical full key recovery, against a cipher whose full version runs 32 rounds. No complexity figures published.
- Salsa20, Poseidon, SHA-1. Described as limited improvements offering less than tenfold gains. SHA-1 has been deprecated for certificate signing for years regardless.
The LEA result is the one to watch, because it is a practical, runnable attack on a deployed standard's reduced variant rather than a complexity-theoretic improvement. It still stops well short of the full cipher, and until the paper appears there is no way to assess how close it gets.
CryptanalysisBench: a benchmark for AI cryptanalysis capability
Alongside the results, Anthropic released CryptanalysisBench with academic partners at ETH Zurich, Tel Aviv University and TU Berlin. It is a benchmark of 191 tasks across six families of cryptographic primitives, drawn largely from NIST standardisation competitions, with the code published openly.
This is the more consequential release in the long run. Anecdotes about a model cracking a scheme are hard to compare across labs and easy to cherry-pick. A shared benchmark turns AI cryptanalytic capability into something you can plot over time, which is exactly what standards bodies need if they are going to factor it into review cycles.
Is your SSL certificate at risk? What to check today
Nothing needs to change. Your certificate is signed with RSA or ECDSA over SHA-256, your session keys come from an ECDHE or hybrid post-quantum exchange, and your traffic is protected by AES-GCM or ChaCha20-Poly1305 at full round count. None of those appear in the research. There is no reissue to plan, no key to rotate, no cipher suite to disable.
If you want to spend the attention productively, spend it on the things that are already true and already biting. Certificate lifetimes are dropping to 199 days under SC-081v3, which forces renewal automation whether or not you wanted it. Weak configuration beats weak mathematics as a cause of real incidents by an enormous margin, so a current review of your cipher suite selection is worth more this quarter than anything in this announcement.
If you are choosing certificates and want to understand what actually differentiates them, our breakdown of the types of SSL certificates and what each validates is a better use of ten minutes than any cryptanalysis headline.
What this means for your post-quantum migration plan
The migration timeline does not move. NIST IR 8547 proposes deprecating 112-bit classical public-key security, which covers RSA-2048 and P-256, by 2030 and disallowing it by 2035. That schedule exists because Shor's algorithm breaks RSA and ECC outright on a sufficiently large quantum computer, and it has nothing to do with HAWK, which was never part of the standardised portfolio.
What the announcement does argue for is agility, and this is where most organisations are genuinely exposed. If a weakness turns up in a scheme you have deployed, the question that decides how bad your year is is how fast you can swap it. Most estates cannot answer that, because they do not know where their keys live, their certificate issuance is partly manual, and their signing pipelines have hardcoded algorithm assumptions from a decade ago.
Three things are worth doing regardless of what any model finds next. Keep an inventory of every certificate and key, including the forgotten internal ones. Enable hybrid post-quantum key exchange wherever your stack already supports it, since that is where harvest-now-decrypt-later risk actually sits. Make renewal and re-signing automatic, so that an algorithm change becomes a configuration edit rather than a project.
One more thought about the $100,000. That figure is nothing to a national cryptanalytic agency, and it is affordable to a well-funded research group. Whatever capability was demonstrated publicly here, assume the organisations that never publish have had it for a while. The right response is not alarm; it is treating cryptographic agility as an operational requirement rather than an architectural aspiration.
How we researched, sourced and reviewed this article
Every figure in this article comes from Anthropic's published post of 28 July 2026 and its accompanying technical PDF on the seven-round AES attack, cross-checked against the independent ePrint 2026/1593 reduction, HAWK's original design paper, NIST's own status page for the third round of the additional-signatures on-ramp, and reporting from Ars Technica, CyberScoop and CSO Online. Matthew Green's analysis informed the framing of what these results do and do not imply.
Three things circulating in coverage are deliberately absent here because we could not verify them: a reported parallel attack on HAWK using a different model, exact complexity figures for the LEA, Serpent, Salsa20, Poseidon and SHA-1 follow-ups, and reaction quotes attributed to well-known cryptographers who do not appear to have published anything on the subject. Where Anthropic's post names TU Berlin among the CryptanalysisBench partners and secondary coverage names the University of Haifa, we follow the primary source.
Our review process, step by step
- Primary sources first. Every claim was traced back to the originating publication — Anthropic’s research post and technical PDF, the IACR ePrint papers, and NIST’s own status pages. Where a news outlet and a primary source disagreed, the primary source won.
- Numbers quoted verbatim. Complexity figures, cost estimates and speed-up factors are reproduced as published, with the round counts they apply to stated explicitly. We did not round, extrapolate or convert any figure into a scarier one.
- Unverifiable claims removed. Anything we could not attribute to a named, checkable source was cut rather than hedged. What was cut is listed above.
- Operational review. The guidance sections were checked against how TLS, code signing and PKI actually behave in production — which algorithms browsers negotiate, what CAs issue, and what a certificate change costs an operations team.
- Scheduled re-review. This article is re-checked when the outstanding LEA, Serpent, Salsa20, Poseidon and SHA-1 papers are published, and when NIST announces the outcome of the third round of the additional-signatures on-ramp. The updated date at the top reflects the last substantive review, not a cosmetic edit.
We have no commercial relationship with Anthropic, NIST or any of the cited research groups. My-SSL sells TLS, code signing and S/MIME certificates, none of which use the algorithms discussed here, so nothing in this research affects what we sell — which is precisely why we can afford to tell you it changes nothing for you.