FOUNDATIONS: what is crypto-agility? (read first if M12 is not open to you yet)
Crypto-agility is the ability to change the cryptographic algorithm a system uses quickly, without it being buried deep in code or hardware, if that algorithm is found insecure tomorrow. In practice this usually means “moving algorithm choice into a configuration file”: libraries like OpenSSL do it with plug-in modules called providers (which algorithm to use is decided by a provider choice, not baked into the code); hardware security modules (HSMs) provide a similar abstraction through a standard interface called PKCS#11. This lesson shows, with a concrete example, why this ability is not “nice to have” but essential. PRACTITIONER/ADVISOR readers will see this concept in much more depth in M12 (the crypto-agility lesson); this paragraph is just a starting point sufficient to follow this lesson.
Mental model
NIST’s additional signature standardization round (IR 8610 Round 3) had 9SOURCED candidates. As you saw in M4, that number dropped to 8SOURCED. This lesson is about the reason for the drop: a candidate called HAWK was withdrawn by its own team, before becoming a standard, because of a cryptanalysis finding.
The reason this case deserves its own lesson is not HAWK itself (it was not going to be a standard anyway and was used in production nowhere); what really matters is that the party that found the attack was not a human researcher but an AI agent, and this event teaches you two things at once. First, how to verify a claim independently (especially a claim that looks unusual). Second, that the real defence against the risk “an algorithm we trust today may be broken tomorrow” is not algorithm choice but the ability to change algorithms (crypto-agility).
What happened, in what order
HAWK was one of NIST’s nine Round 3 additional signature candidates with CANDIDATE status (see M4, hqc-and-ir-8610). On 28 July 2026, after about 60 hoursSOURCED of semi-autonomous work (the human operator had no background in lattice cryptography, and the total API cost was about USD 100,000SOURCED), an AI system from Anthropic called “Claude Mythos Preview” found an automorphism in HAWK’s lattice structure (an automorphism is, roughly, a symmetry that maps a structure onto itself without breaking its meaning; here, a symmetry that lets an attacker skip a large part of the search space). This automorphism significantly lowered the cost of a key recovery attack:
- For HAWK-512: 150SOURCED → 108SOURCED
- For HAWK-256 (Anthropic’s own example): 64SOURCED → 38SOURCED
The same day, a participant named Steve Weis shared the finding on NIST’s public pqc-forum mailing list (“HAWK-n Key Recovery Reduces to SVP in Dimension n/2+1”). Cryptographer Daniel Apon replied in the same thread: “It checks out independently for me”. This is evidence that the claim did not stay on Anthropic’s own page but was confirmed by a third party on NIST’s official forum.
The HAWK team (academics with no connection to Anthropic) formally withdrew HAWK from NIST’s Round 3 process on 28-29 July 2026. Today NIST’s own Round 3 page lists HAWK as WITHDRAWN2026-07-29.
Why we trust this: the verification chain
This lesson is also an example of how this course itself works. The sentence “an AI found a cryptographic attack” is, by its nature, a claim to be met with scepticism. Before accepting it there are four separate sources to check, and only one of them (the first) is the page of the party with a commercial interest:
- Anthropic’s own page: the source of the claim, but also the party with a commercial interest (it shows its own product’s capability). Not enough on its own.
- NIST’s pqc-forum: outside Anthropic, on an official NIST channel, an independent cryptographer (Daniel Apon) checked and verified the math.
- A second, independent finding in the same pqc-forum thread: a different participant (Hengyi Luo) shared in the same thread a second attack on HAWK, reached by a different route, run with an AI system completely separate from Anthropic’s (GPT-5.6). Two different AI lineages reaching a similar weakness without knowing of each other is a strong sign that this is not a quirk of one system.
- The HAWK team’s own action: if the attack had not been real, they would not have withdrawn their own candidate from NIST. A team acting against its own interest (withdrawing its candidate) is one of the strongest pieces of evidence that the claim is real.
All four hold together. This is a concrete application of the principle “don’t trust a single source, verify”, which you will meet throughout this course.
What we learned: why crypto-agility beats algorithm loyalty
HAWK was not yet a standard and was used in no production system; so in the real world nobody had to replace HAWK keys. But take the scenario one step further: if HAWK had been a standard and a bank had built its code signing infrastructure on it, what would happen when the same finding arrived?
(For PRACTITIONER/ADVISOR) The crypto-agility concept you saw in M12 (provider models, policy-driven algorithm selection) exists for exactly this scenario, but the claim needs to be kept precise here. If algorithm choice is a configuration parameter (switch the OpenSSL provider, switch the PKCS#11 mechanism), moving new signing operations to a new algorithm really can take days. But that does not mean the bank’s entire inventory has migrated: reissuing certificates in the existing chain (see M7, root rollover), repeating an HSM key ceremony (see M9), and getting counterparties to accept the new algorithm can take weeks or years, which is exactly why M13’s three-horizon (H1/H2/H3) roadmap exists. “A configuration change takes days” and “the bank fully migrates” are two different time scales; confusing them is exactly the kind of overstatement this course’s rule 4.1 warns against.
If algorithm choice is baked into code, certificate formats or hardware firmware (if there is no crypto-agility), both time scales above grow, and the system stays vulnerable for that whole period.
The lesson of the HAWK case: the security of the move to PQC depends not on which algorithm you choose but on how quickly the algorithm you choose can change for new operations if it has to change tomorrow, which does not mean the whole migration finishes instantly. That is the point to stress when explaining this case to a bank architect, not “PQC can be broken too, so why move”.