Anthropic says Claude has explained where the seeds behind the NIST elliptic curves came from, including P-256, the curve that signs a large share of the web’s TLS handshakes, passkeys, and software updates. The answer is mundane: the seeds were not hashes of a secret phrase, as long rumored, but the output of lrand48, the stock random-number generator in 1990s C libraries, started from a Unix timestamp.
Anthropic’s Frontier Red Team published the finding with code that regenerates the seeds, and it shot to the top of Hacker News within hours. The company is clear about what this is and is not: it is not a break of ECDSA, not a new attack, and nobody needs to change anything. If anything, it makes the old backdoor theory less plausible.
We ran Anthropic’s published Python on our own machine. It reproduced the official P-256 seed (C49D3608 86E70493 6A6678E1 139D26B7 819F7E90) and the P-384 seed exactly, in well under a second. Everything else below comes from Anthropic’s write-up and public coverage.
Key points
- What was solved: The seeds for NIST P-192, P-224, P-256, P-384, and P-521, plus five ANSI X9.62 example curves and four NIST binary curves.
- How they were made:
srand48seeded with a Unix timestamp, then 20-byte candidates drawn one after another. P-256 is candidate 1,842 from a run started in August 1997. - How long it took: Anthropic says an internal research model got there in under half an hour, without being pointed at the old “secret phrase” rumor.
- Bonus: Claude also explained the base points of six curves, which Anthropic believes is a first for any NIST base point.
- Still open: The B-163 seed and the base points of P-224, P-256, P-384, and P-521 remain unexplained.
- The bounty: The $36,864 seed bounty organized by Filippo Valsorda goes to the Internet Security Research Group, the nonprofit behind Let’s Encrypt.
Why these seeds mattered
ECDSA is the most widely used elliptic-curve signature standard. When NIST adopted its curves in FIPS 186-2, each came with a “seed” whose hash sets the curve’s b coefficient. The idea was “nothing up my sleeve”: if the parameters come from hashing a seed, the designer could not have picked a weak curve on purpose.
The problem was that the NSA supplied the seeds with no explanation. A seed you cannot explain does not prove much, because in theory someone could have tried many seeds until one produced a curve with a hidden property. After the Dual_EC_DRBG scandal, that doubt stuck. Neal Koblitz and Alfred Menezes summed up the controversy in “A Riddle Wrapped in an Enigma,” and some projects leaned toward alternatives such as Curve25519 partly to avoid the question.
The best clue came from NSA mathematician Jerry Solinas, who recalled hashing a joke phrase along the lines of “Give Bob and Jerry a raise.” Solinas died in 2023, and nobody could reconstruct the phrase. Anthropic says several of its own staff had chased that lead without luck.
How Claude cracked it
Instead of guessing phrases, Claude guessed at the software. Old C-library generators are weak enough that their output leaves fingerprints, so Claude wrote a scanner that slid across each seed bit by bit and tested whether neighboring chunks looked like consecutive outputs of a 1990s generator. It covered 34 combinations of generator and output slice.
The giveaway was in the binary-curve seeds. Split into 32-bit words, four of them had a zero in the top bit of every word, which happens by chance about once in 5,810 tries. That is the signature of lrand48, which returns only the top 31 bits of a 48-bit state. Claude brute-forced the 17 hidden bits of the first word and checked that the next four words followed.
The prime-curve seeds were harder because they kept fewer bits of each output (lrand48() >> 23). Recovering a truncated linear congruential generator is a textbook lattice problem, and Claude solved it with LLL basis reduction across every possible bit window. Each recovered 48-bit state regenerates all 160 bits of its seed, which does not happen by accident.
Because this generator runs backward as easily as forward, Claude then rewound each state to the form srand48 creates. For all ten prime-curve seeds, the starting value read as a Unix timestamp between May 1997 and April 1998. The binary-curve values only made sense if the program had halved the clock, which puts them two weeks after the P-224 run.
Anthropic also shared Claude’s reasoning at the moment of discovery. The model briefly wondered if it was in a test environment, then checked itself: a 160-bit match from a 32-bit seed and a small index, across ten seeds, rules out coincidence.
What it means for security teams
Short version: nothing to patch. The curves are as strong as they were yesterday. What changed is the trust story around them.
- Backdoor theory weakens. A clock-seeded generator that anyone can rerun leaves far less room to secretly hunt for a weak curve.
- A small open question remains. Not every candidate was used. For P-256, candidate 876 of the same run also gives a valid prime-order curve, yet 1,842 was published. P-224’s run skipped three such curves, and the ANSI runs skipped seven more. Anthropic does not know why, but argues the numbers are too small for deliberate weakening to be plausible.
- Curve choice does not need to change. If your team already prefers Ed25519 or X25519 for new work, nothing here argues against that. If you run P-256 for compliance or hardware reasons, this is reassurance, not a migration trigger.
What it means for people building with AI
The more interesting signal is the method. Claude did not search the web for a forgotten answer. It reframed the problem, wrote its own analysis tools, applied a known but non-obvious technique (lattice reduction against a weak generator), and verified the result by regenerating the data exactly. That is the same loop strong engineers use on hard debugging: form a hypothesis about the system that produced the output, then prove it.
It also fits a pattern in Anthropic’s recent research posts, where Claude is shown doing long, checkable technical work rather than chat. We covered a similar case in physics with Claude’s nine-loop amplitude result. The common thread is verifiability: the claims come with code or math anyone can rerun.
Two honest caveats. First, this was an internal research model, and Anthropic does not say which public Claude version, if any, matches it. Second, the same skill set, spotting weak randomness and recovering hidden state, is exactly what offensive security work needs. That is likely why the work came from Anthropic’s Frontier Red Team, and why the company keeps expanding access controls for advanced cyber capabilities.
What to watch
- Whether cryptographers crack the B-163 seed or the remaining NIST base points using the same approach.
- Independent write-ups checking the skipped candidates and the halved-clock reading for the binary curves.
- Which public Claude models can reproduce this kind of investigation, and how Anthropic gates them for security use.
Sources
- Anthropic: Claude reveals ECDSA curve origins (includes CC0 reproduction code)
- Hacker News discussion
- Investing.com via Yahoo Tech coverage
