Sixty Hours and $100,000 in API Cost Produced a Novel Lattice Attack on a PQC Candidate. Treat It as a Signal, Not a Rate

Anthropic published a piece of cryptanalysis on July 28, 2026 that is easy to misread in both directions. Working alongside Anthropic researchers, a semi-autonomous Claude Mythos Preview workflow spent about 60 hours and roughly $100,000 in API cost, and answered a question human cryptographers had left open a year earlier. A 2025 academic paper had proved a conditional: if someone could produce a particular kind of hidden symmetry in the math underneath HAWK — one of the digital signature schemes still competing for standardization in NIST’s post-quantum process — then recovering HAWK’s private keys would get substantially cheaper, cutting the number of security bits in half. That paper did not produce one. The model produced a method for deriving one from the public key. Nothing you are running today changed as a result: HAWK is an unstandardized candidate nobody deploys, the finalized post-quantum standards are untouched, and Anthropic says plainly that no production software has to change. What changed is the cost of producing a result like this, and that is the number worth taking into a planning meeting.

The mathematical claim, stated precisely: the public key permits constructing a τ-cocycle lattice whose short vectors yield an automorphism outside HAWK’s trivial automorphism group, reducing HAWK-n key recovery to polynomially many exact-SVP calls in dimension at most n/2 + 1 — an asymptotic factor-of-two cut in oracle dimension. The advance is the derivation, not the existence: the 2025 conditional assumed an attacker who already knew such an automorphism, and what was missing was a way to get one from the public key. The result is a general reduction, applying to every HAWK parameter set including the two submission sets targeting NIST Levels 1 and 5, but only the smallest was run to completion and neither larger set is practically recoverable under the published attacks. HAWK itself is an unstandardized candidate in the third round of NIST’s additional-signatures process. If you run only the finalized standards, there is no emergency cryptographic replacement to make this week — the work is validating inventory, reviewing any experimental candidate deployments, and watching the process. The number worth carrying into planning is the 60, as a capability signal and a scenario to stress-test against rather than a measured rate.

TL;DR

• A model workflow spent ~60 hours and ~$100,000 in API cost to supply the missing piece of the 2025 van Gent/Pulles conditional — which had explicitly named the automorphism group as an open attack avenue. Anthropic summarizes HAWK-256 as falling from roughly 2^64 expected work to 2^38; in the technical paper 2^38 is specifically the Core-SVP estimate for one oracle call at the reduced dimension, while the released implementation completed recoveries in a few hours.
• No standardized primitive is affected — HAWK is an unstandardized round-3 candidate and FIPS 203/204/205 are untouched, and Anthropic documents no impact on production software. But the reduction is general, and both submission parameter sets lost substantial modeled margin: under the paper’s gate-count model, estimated key recovery drops from 2^150 to at most 2^108 for HAWK-512 and from 2^288 to at most 2^182 for HAWK-1024. Neither is practically recoverable under the published attacks. Only HAWK-256 was executed end to end, and its 2^38 must not be copied across to either.
• The real finding is the trajectory, not a curve: two Anthropic-reported cost points at roughly $100,000 in API cost each and days of model work, then materially different amounts of human verification. No human-only baseline was measured and two points don’t establish a rate — treat it as an early acceleration signal and a planning scenario, and plan for more results per standardization round rather than for one algorithm’s fate.
• Verification is the bottleneck — Mythos produced the initial AES insight in roughly three days, while two researchers who were not cryptography experts spent several hundred hours learning the material, validating the claim and writing it up, taking nearly a month to gain confidence; treat “unverified” as its own handling state with a pre-agreed escalation path for anything touching the finalized FIPS standards.
• The actionable work is cryptographic inventory: TLS scanning and conventional SBOMs do not by themselves reliably expose pinned JCA/JCE providers, firmware-resident signing keys, or algorithms and suites selected only at runtime, and the hardware tier (HSMs, TPMs, smartcard applets, OT gear with ROM-resident RSA-2048) often presents the longest replacement lead time — identify and document any non-standardized PQC candidate that quietly became load-bearing, freeze new adoption by default, and prioritize migration on cryptanalytic status, vendor support, fallback path, and replacement complexity.

This is a story that is still moving as I write it. Anthropic published the result on July 28, 2026. Checked immediately before publishing this, I had not identified a publicly documented independent end-to-end reproduction of the HAWK-256 key recovery, nor an official NIST decision changing HAWK’s parameters, security claims, or standing in the process. Both are bounded search results rather than assertions that neither exists. Hold everything below at that confidence level.

The paper defined the conditional. The model supplied a way to derive the object.

The prior work is the part most of the coverage skipped, and it’s the part that makes the result legible. Daniël van Gent and Ludo Pulles published “HAWK: Having Automorphisms Weakens Key” in IACR Communications in Cryptology in July 2025. Their result is conditional, and their abstract says so plainly: knowledge of such a nontrivial automorphism “speeds up the key recovery attack on HAWK at least quadratically, which would halve the number of security bits.” They did not find one. And their conclusion is narrower than it gets reported: they argued there were plausibly no more trivial automorphisms that make the revised omSVP game easy to win — while explicitly noting that their work “opens up a new attack avenue involving the automorphism group that may be theoretically interesting on its own.” They did not predict the door was shut. They pointed at it.

Worth separating the numbers before someone welds them together in a slide. Anthropic’s summary frames HAWK-256 as falling from roughly 64-bit expected security to 2^38. The technical paper’s like-for-like comparison is cleaner: per SVP-oracle call, the Core-SVP estimate goes from 2^62 before the reduction to 2^38 after it. Neither of those is a stopwatch reading — both are model estimates, and the 2025 paper’s conditional is a third kind of claim again.

A human paper stated the if, and named the avenue. A model produced the method that derives the required automorphism from the public key. Neither half is the result on its own, and the framing that treats this as a machine independently inventing lattice cryptanalysis from a blank page is doing the reader a disservice.

The mechanics, at the altitude that matters here: the attack builds a lattice derived from the public key, runs reduction and sieving to recover short vectors, and reconstructs a secret basis capable of signing for the original public key. Anthropic reports that the model built an end-to-end verification pipeline to convince itself and its human operator the recovery was real, and has published demonstration code. That last detail is the operationally interesting one. The release is a single-command pipeline with per-stage checkpoints that verifies its own output against the HAWK reference implementation as its final step, which should make reproduction far cheaper than discovery was. How much cheaper, in the hands of a team that has to audit as well as re-run it, nobody has established yet.

Scope, stated precisely

HAWK’s submission proposes exactly two parameter sets, per the HAWK team’s own site: HAWK-512 targeting NIST Level 1 and HAWK-1024 targeting Level 5. Neither is standardized or approved by NIST — they are the parameter sets the candidate has submitted for evaluation. HAWK-256 is not among them, and that is by the designers’ own design — the HAWK specification calls it a “challenge” parameter set whose security level, “around 64 bits,” is explicitly “too low for submission to NIST,” offered because “it is a good cryptanalytic target.” Which is worth sitting with: the 2^64 starting point everyone is quoting is the designers’ own estimate for an instance they published hoping somebody would attack it. Somebody did. Do not carry the 2^38 figure over to either submission set. That is the number people will quote at you in a steering meeting, and it is specific to the challenge instance.

But be careful not to over-correct in the other direction, which is the mistake I made in the first version of this post. The reduction is general. The technical paper’s title says so — “HAWK-n Key Recovery Reduces to SVP in Dimension n/2 + 1” — and its theorem covers every power of two n ≥ 4. HAWK-512 and HAWK-1024 are mathematically affected, and the paper prices them: under the specification’s own AGPS20 gate-count model, estimated total key-recovery cost falls from 2^150 to at most 2^108 for HAWK-512 and from 2^288 to at most 2^182 for HAWK-1024. A more aggressive heuristic in the specification’s own methodology puts them near 2^80.8 and 2^146.5, which the authors note makes their provable totals conservative by a further 2^27 and 2^35.

Neither was attempted — the paper says plainly of HAWK-512, “we have not attempted it” — and neither is practically recoverable under the published attacks. But hold that conclusion at the confidence the paper itself does: these are model-dependent estimates, the paper prices only the SVP-oracle calls on both sides (its words: “Only the SVP-oracle calls are priced”), and it labels the lower 2^80.8 and 2^146.5 figures heuristic. So the honest sentence is not “the submission sets are unaffected,” and it is not “anyone can burn through the remainder” either. It is: both proposed parameter sets lost substantial modeled security margin, and no practical attack against either has been demonstrated.

One more distinction worth keeping straight, because the two numbers get welded together: 2^38 is a Core-SVP work-factor estimate for a single SVP-oracle call at the attack’s reduced dimension, not a stopwatch reading. The stopwatch reading is separate and also real — the released implementation recovered functionally equivalent signing keys for two HAWK-256 public keys, every reported attempt succeeding, in a few hours on a single 96-core Sapphire Rapids server. Worth being exact about that output: the attack returns a basis satisfying the same public Gram matrix and capable of signing for the public key, not the original encoded secret-key seed. For anyone relying on that key, the distinction makes no practical difference. For anyone reading the claim, it does.

HAWK is one of nine algorithms NIST advanced to the third evaluation round of the Additional Digital Signature Schemes process, documented in NIST IR 8610 in May 2026 alongside FAEST, MAYO, MQOM, QR-UOV, SDitH, SNOVA, SQIsign, and UOV. It is the only lattice-based scheme left in that pool, and it rests on different hardness assumptions (smLIP, omSVP) than ML-DSA or Falcon. The finalized standards are untouched: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA). FN-DSA, still under development as the future FIPS 206, is also unaffected, and NIST has published no firm completion date for it. Anthropic’s own framing is the one to repeat verbatim when someone forwards you a headline: “neither of these results has a practical impact on today’s computer systems; no production software will have to change as a result.”

The second of those results is an attack on reduced-round AES, and it lands the same way. Seven rounds of AES-128’s ten, using a fingerprinting technique the authors call a Möbius Bridge. It eliminates one of the nine guessed key bytes the prior attack required — a 256-way enumeration step, so a factor-of-256 cut in key guesses — and comes out, by Anthropic’s own accounting, between 200 and 800 times faster than the strongest prior meet-in-the-middle attack depending on how you measure it. The attack setting it improves on is one where the adversary can request the encryption of 2^105 chosen plaintexts, which is its own answer to anyone asking whether this reaches production. Reduced-round cryptanalysis is how the field measures margin. AES is fine.

The verification asymmetry is the finding I’d actually staff for

Mythos found the Möbius Bridge after roughly three days and spent further days refining the attack, with about a billion output tokens across the full development. On the human side, Anthropic says two researchers who were not cryptography experts spent several hundred hours “learning enough cryptography research to validate the model’s claim, and to prepare the research paper itself,” and that it took them nearly a month to gain confidence the method was correct. Note what that number is and isn’t: it bundles learning the field, checking the work, and writing it up, which is a fair description of what consuming this kind of result actually costs. That ratio is the operational problem, and it does not stay confined to cryptography.

If you consume this class of research — and if you own a PQC migration plan, you do — you may have a queue-management problem coming. If this pattern generalizes, consequential claims may arrive faster than the available experts can independently reproduce them — two experiments don’t establish that, but they’re enough to make it worth designing for. Treat “unverified” as its own state with its own handling, distinct from both refuted and confirmed, and decide in advance what each state triggers. For a round-3 candidate you don’t run, the answer is to log it and move on. For anything touching FIPS 203/204/205, you want a pre-agreed escalation path that doesn’t route through a Slack thread at 4pm on a Friday.

I’d also resist the reflex, common in this field, to treat the absence of a reply on a mailing list as either endorsement or dispute. The Hacker News reported the public NIST-forum thread had no replies when it checked and that it could not locate an independent reproduction. Thread state moves; check it yourself rather than citing this post for it. Worth pairing that with a detail the same reporting surfaces: Anthropic’s forum post thanked the HAWK team for helping verify the result, and says disclosure was coordinated with HAWK’s authors on the NIST list in June — though the write-up doesn’t say whether that involved reviewing the proof, running the artifact, or both, and doesn’t say whether HAWK’s team accepts the analysis. So “no independent reproduction” is not the same as “nobody outside Anthropic has looked at it.” And state these as bounded search results, not universal negatives: as of July 28, 2026 I have not identified a publicly documented independent end-to-end reproduction, and I have not identified a public NIST decision changing HAWK’s parameters, claims, or standing. Both are things I looked for and did not find, which is a weaker claim than they do not exist. Re-check and re-timestamp before you brief anyone off this post.

What actually changed is the planning signal

Two novel results, roughly $100,000 in API cost each, days of model work, and then materially different amounts of human verification on top. Anthropic did not measure what the same results would have cost a human-only team, so treat this as an acceleration signal rather than a compression ratio — nobody has established a year-to-days figure, and I’d distrust anyone who quotes one. What the signal supports is a planning assumption: more results per standardization round, and a shorter interval between “candidate advances” and “candidate gets a paper written about it.”

Which is why I think the “AI broke post-quantum crypto” reading is backwards. Candidates are attacked before standardization precisely so this happens now. HAWK survived two rounds of human review; a result landing at round three is the process working exactly as designed. Ellen Boehm at Keyfactor made the same point to CyberScoop, and it’s the right one.

The thing worth worrying about is a procurement pipeline that reads “NIST candidate” as a safety label, and the vendor who shipped a round-2 signature scheme into a product because the signature sizes looked good in a slide deck.

The inventory is the work, and it is uglier than the vendors admit

The question to answer this week is not whether HAWK is safe. You are almost certainly not running it. The question is: for every place your systems do cryptography, how long would it take to change the algorithm, and do you know where those places are?

Most shops discover the answer to the second half is “partially.” TLS scanning is genuinely useful and will surface network-visible endpoints you had forgotten about, not just the load balancer and the public API. What it cannot reach is cryptography that never negotiates anything over the wire: the JCA/JCE provider registered or prioritized in java.security, or selected programmatically, in a service nobody has opened since the original author left; the signing key baked into a firmware image; the local keystore; the batch job that calls a crypto library directly. A sufficiently complete SBOM may identify OpenSSL as a component — coverage and dependency depth vary a lot in practice — but an SBOM alone generally cannot establish which algorithms, parameters, providers, or protocol suites actually get exercised at runtime. Runtime is where the answer lives, and getting there takes source, binary, configuration, endpoint, and network evidence together.

Then there’s the hardware tier, which is where migration plans go to die. HSM firmware on a support contract. TPMs. Smartcard applets. OT gear with a fixed RSA-2048 verification key in ROM and a vendor who will quote you a hardware refresh. Those entries have replacement horizons measured in capital budget cycles, and they often present the longest replacement lead time, which is why they are worth identifying first. NIST’s own NCCoE work on this, the Migration to Post-Quantum Cryptography project, gives discovery an entire volume of its own — SP 1800-38B, a preliminary draft titled “Quantum Readiness: Cryptographic Discovery,” which evaluates discovery tooling and lays out a multifaceted approach you can start using now — for exactly this reason.

Two concrete asks. First, if any corner of the estate pre-deployed a non-standardized PQC candidate — a hybrid experiment that quietly became load-bearing, an internal signing service someone built on a scheme with attractive parameters — find it, document its exposure and its fallback path, and prioritize migration on its cryptanalytic status, vendor support, and replacement complexity. I’d stop short of “rip it out this week” on the strength of this result alone; the published attacks on HAWK’s proposed parameters remain impractical by an enormous margin. But new work should default to the finalized standards unless someone can write down why not, and this result is the argument you needed to make that conversation happen. Second, when you next talk to a vendor, ask what their algorithm-change process looks like and how long it takes end to end. The shape of the answer tells you more than the answer does.

Treat the table as implementation rationale rather than an authoritative one-to-one mapping; your assessor’s reading will vary. The artifacts that go with it, if someone asks what you’d actually show: a documented algorithm-change process for SC-13, a key rotation runbook for SC-12, and inventory records that carry algorithm and key material as fields rather than a package version for CM-8. One runbook can serve both crypto controls, but don’t file primitive replacement under SC-12 alone — an assessor reading SC-12 is looking at key lifecycle, and the algorithm-substitution argument belongs in SC-13.

Nothing here is an incident. There is no IOC, no threat-detection query, no emergency rule to tune, and I’d be suspicious of anyone selling you one off the back of this — though targeted inventory searches for HAWK and other non-standardized PQC implementations are absolutely warranted, and that is a different kind of query. The finding is a planning input: Anthropic now reports two roughly $100,000 cryptanalysis experiments — one against the HAWK candidate, one against reduced-round AES-128, which is not a candidate at all. Test your migration plan against scenarios at that cost and timescale. What these two points do not establish is what most migration programs previously assumed, or how representative the two costs are — so treat it as a scenario to stress the plan, not a number to put in it. Build the cryptographic inventory while the pressure is theoretical, because the version of this conversation that starts with a standardized algorithm will not leave time for discovery.

Sources

• Discovering cryptographic weaknesses with Claude (Anthropic)
• HAWK-n Key Recovery Reduces to SVP in Dimension n/2 + 1 — Straznickas & Weis, Anthropic (technical paper)
• Cryptanalysis of 7-Round AES via the Algebraic Structure of its S-box — Nasr & Carlini, Anthropic (technical paper)
• HAWK: Having Automorphisms Weakens Key (IACR Communications in Cryptology)
• Hawk — parameter sets and performance (HAWK team)
• HAWK specification v1.1 (HAWK team)
• NIST IR 8610, Status Report on the Second Round of the Additional Digital Signature Schemes for the NIST Post-Quantum Cryptography Standardization Process (NIST CSRC)
• Migration to Post-Quantum Cryptography (NIST NCCoE)
• Claude AI Just Cracked a Post-Quantum Test Scheme and Found a Faster 7-Round AES Attack (The Hacker News)
• Anthropic’s Claude Mythos finds weaknesses in encryption algorithms (CyberScoop)

This post was engineered and validated through a multi-agent AI workflow — drafted, adversarially reviewed by several independent models, checked against primary sources, and given a human review before publishing. See an inaccuracy, or found this useful? Leave a comment below — corrections and feedback are read and shape what comes next.