A language model found an attack that forces HAWK to double its keys

On 28 July 2026 Anthropic published two cryptanalytic results found with one of the company's own language models. The first is an improved attack on the HAWK signature scheme, a third round candidate in the NIST call for additional post-quantum signatures. The second is an improved attack on a reduced version of AES. Anthropic states itself that neither finding has practical significance for systems in operation today, and that no production software needs changing. The work was done by the company's Frontier Red Team.

What happens technically

The HAWK result is the weightier one. The scheme rests on a lattice, and the attack exploits a symmetry in that lattice which nobody had exploited before. Earlier work had proved that such a symmetry would yield an attack, but not whether it existed in HAWK. That is exactly what the model found. For the smallest parameter set, HAWK-256, Anthropic reports that the expected cost of a full key recovery attack fell from 2^64 to 2^38 operations, and the attack is demonstrated with running code that extracts a secret key in a few hours on a single server. The cost falls for the larger sets too, from 2^150 to 2^108 for HAWK-512 and from 2^288 to 2^182 for HAWK-1024, but those remain impractical to attack. The attack is still exponential and applies to HAWK alone. It affects neither the other candidates nor lattice based cryptography as such. The consequence is that HAWK has to double its key size to keep its security level, and that doubling removes much of what made the scheme attractive. HAWK had survived two rounds of expert review across two years.

The AES result is weaker, and that deserves saying plainly. It concerns a modified AES-128 with 7 of 10 rounds, and builds on a 2013 attack that assumes the attacker can have 2^105 chosen plaintexts encrypted. Anthropic therefore calls it entirely impractical. The improvement consists of a fingerprinting method that removes the need to guess one key byte, cutting the work by a factor of 256, and with further optimisations yields an attack 200 to 800 times faster. The full AES cipher stands unchanged. Assessments diverge here: Anthropic describes the findings as substantial research advances, while the cryptographer Matthew Green calls the AES result a modest constant factor improvement on work from 2013, and questions whether the speed gain is real when the attack cannot be run. The work was published alongside the CryptanalysisBench benchmark, which holds 191 tasks across six families of cryptographic primitives. Two new results emerged there: a full key recovery attack on the AEAD scheme SpoC, and an error in the published security proof for KINDI. Of 14 schemes broken at full strength, only two stemmed from a genuine design flaw. Ten were errors in the reference code.

What this means for you if you are planning a post-quantum migration

The first thing to take away is what this is not. No algorithm you use today is weakened, and there is nothing to update or replace as a result of these findings. If somebody tells you otherwise, the sources do not support it. The second thing to take away is less comfortable. HAWK had stood through two years of expert review before this was found, and it was found by a machine searching systematically. Our assessment is that the important part here is not the attack but the speed: the time from a scheme being published to somebody having searched it thoroughly is becoming much shorter.

For anybody planning a migration, that means the choice of algorithm should tolerate a candidate dropping out. Set up your cryptography so that it can be swapped, and avoid binding formats and protocols to one particular scheme. That applies especially to candidates not yet standardised. If you are considering HAWK as a future signature scheme, it is worth knowing that a doubled key size removes much of the advantage the scheme had. Note as well how the benchmark revealed something other than what it looked for: among the schemes broken, most breaks were errors in the code rather than in the construction. That is a reminder that implementation is where most cryptographic failures actually arise.

Berigo recommends

• Do nothing urgent as a result of these findings. No algorithm in operation is weakened, and the source says so itself.
• Build your cryptography so the algorithm can be swapped without rewriting protocols and file formats.
• Hold off on committing to post-quantum candidates that NIST has not yet standardised.
• Weigh implementation quality when you assess cryptographic libraries. In the benchmark most breaks were errors in the code, not in the construction.
• Expect the review of new schemes to move faster from here, and keep track of whether the candidates you are considering still stand.