A ten-person Anthropic team has claimed the community bounty for explaining where the NSA-supplied seeds behind the NIST elliptic curves came from, after, by Anthropic’s account, an internal Claude model solved the puzzle in under half an hour. The $36,864 prize goes to the charity behind Let’s Encrypt, and the episode says a lot about where AI-assisted research and bounty programmes are heading.
What happened
In 2023 the cryptography engineer Filippo Valsorda launched a public bounty for one of the field’s longest-running puzzles: how were the “seeds” for the NIST elliptic curves chosen? The NSA supplied these values in the late 1990s, they appeared in FIPS 186-2 in 2000, and nobody had ever documented where they came from. Valsorda and a group of matching contributors put up $12,288, rising threefold if the winner gave the money to charity.
Valsorda confirmed on 16 October 2026 that the bounty was claimed at 01:07:51 UTC on 15 October. The claimants are ten Anthropic staff: John Wood, Henry de Valence, Ava Howell, Zack Voase, Lucy Sweet, Amir Omidi, Paul Crowley, Iain McGinniss, Nicholas Carlini and Steve Weis. They chose to donate the prize to the Internet Security Research Group (ISRG), the non-profit that runs Let’s Encrypt, which lifted it to $36,864.
Anthropic’s Frontier Red Team published its write-up the same day. It says a staff member put the question to an internal research model, deliberately withholding the old theory that the seeds were a hashed joke phrase. In under 30 minutes the model traced the seeds for P-192, P-224, P-256, P-384 and P-521 to an ordinary 1990s C library random number generator, seeded with Unix timestamps from between May 1997 and April 1998.
The technical picture
Under the ANSI X9.62 process, a curve’s coefficient is derived by hashing a 20-byte seed with SHA-1. The seed itself was meant to be arbitrary. The suspicion was that whoever picked it could have tried enormous numbers of candidates until one produced a curve with a weakness only they understood.
According to Anthropic, the model approached the problem by asking how 1990s software would most likely have produced random-looking bytes, rather than by guessing phrases. It built a scanner to look for the fingerprints of weak generators from that era. It then spotted that the top bit of every 32-bit word in several seeds was zero, which pointed to the POSIX 48-bit linear congruential generator. Anthropic names the lrand48 function; Valsorda, who re-implemented the method in Go to check it, describes it in terms of drand48. Both belong to the same generator family.
Recovering the hidden state took brute force in some cases and lattice reduction (the LLL algorithm) in others. Because the generator runs backwards easily, each state could be stepped back to its clock-based starting point. The published P-256 seed turns out to be the 1,842nd 20-byte candidate from a run started on 16 August 1997. Anthropic has released the reproduction code under a CC0 public domain dedication.
Some questions are still open. Some valid candidates were skipped for reasons that are only partly understood. For P-256, for example, candidate 876 would also have produced a suitable curve. The fifth binary-field seed (B-163) is still unexplained, and so is the origin of the base points used by the larger prime curves from P-224 upwards. The model did trace the base points of P-192 and several ANSI example curves to the random number generator in Arjen Lenstra’s FreeLIP library.
Why it matters for UK organisations
This is not a vulnerability, and nobody needs to patch anything. Anthropic says plainly that no action is needed. P-256 and P-384 underpin many of the TLS certificates, VPN gateways, code-signing keys and hardware security modules in UK networks, so the finding is reassuring rather than alarming. Valsorda argues that the result rules out a theoretical seed-manipulation attack described by Daniel Bernstein and Tanja Lange in 2017, which needed around 70 bits of freedom in choosing the seed. Even on generous assumptions, the timestamp-driven process left something like 30 bits, which he says is far too few to aim for a rare class of weak curves.
The more lasting point for UK security teams concerns research and disclosure. A bounty that had been open for three years was claimed by a lab using its own model, and the prize went straight to a public-good charity. That is the positive side of AI-assisted research. The negative side has filled the bug bounty news all autumn. Google stopped accepting reports to its open-source VRP on 1 October, citing a flood of invalid automated submissions. TechTarget reports that Intel has paused its paid bounty “until further notice” while it keeps a disclosure programme open. Google figures quoted by TechTarget put monthly disclosed vulnerabilities at 10,740 in August, roughly double January’s total.
Expert view
In my experience of crypto reviews, the NIST curves are almost never the problem. What we find instead are expired certificates, keys sitting in config files, legacy RSA-1024 on forgotten appliances and TLS libraries years behind on patches. If this result ends the occasional procurement debate about whether P-256 is “NSA-tainted”, that is a small win.
What interests me more is how the work was presented. It came with reproducible code, a verifiable claim and an honest list of what remains unknown. That is the standard every programme owner should expect, whether a finding comes from a human, a model or both. The programmes now collapsing under AI-generated reports are getting the opposite: plausible prose with no working proof. A puzzle with one checkable answer suits a model well; most bounty findings are messier, and triage teams cannot treat fluent prose as proof.
The ending is also a little ironic. Valsorda notes that the NIST curves have earned back their reputation just as post-quantum signatures arrive to retire them. For UK organisations, the quantum migration matters far more than 1997 seeds.
What to do now
- Change nothing about your curve choice. P-256 and P-384 remain sound. Do not start re-keying projects in response to this news.
- Know what cryptography you actually run. Build or refresh a cryptographic inventory covering certificates, key lengths, protocols and libraries. It is also the first step towards post-quantum migration planning.
- Patch the crypto stack. Under Cyber Essentials, security update management applies to TLS libraries, VPN appliances and HSM firmware as much as to operating systems.
- Tighten your disclosure intake. If you run a vulnerability disclosure policy or bounty, ask for reproducible evidence (code, logs, steps you can verify) before a report reaches engineering.
- Set rules for AI-assisted submissions. Say in your programme terms whether automated findings are accepted, and require human validation before submission.
- Keep secure configuration in view. Disable obsolete cipher suites and protocol versions on internet-facing services, a Cyber Essentials secure configuration control.
Bottom line
A three-year-old cryptography bounty has been settled with reproducible evidence, and the money has gone to a charity that secures much of the web. The NIST curves are as safe as practitioners always believed. The more important lesson for UK defenders and programme owners concerns standards of proof: AI can now settle hard research questions quickly, but the result only counts because anyone can check it.
