How Claude traced NIST's ECDSA curve seeds to timestamps

A 25-year-old cryptography mystery has an answer, and Anthropic says an AI model found it in under half an hour. On October 16 the company’s Frontier Red Team published a post saying the seeds behind NIST’s standard ECDSA curves came from a 1990s random number generator seeded with the clock. We read the post in full, and we ran its published code. This article explains what was found, what remains unexplained and what the result does and does not show.

What did Anthropic announce about NIST’s ECDSA seeds?

That the seeds were not hash outputs, as long assumed, but timestamps in disguise. Anthropic says that in October 2026 a curious employee asked an internal research model to work out how the seeds were generated, without pointing it at the old clue. “In under half an hour,” the post says, Claude worked out the origin of the NIST P-192, P-224, P-256, P-384 and P-521 seeds. They are the output of the C library’s lrand48 random number generator, seeded with a Unix timestamp. Anthropic frames the post as “a fun closing chapter” with “no action to be taken.”

Why did the seeds matter?

Because the NSA supplied them with no explanation. NIST adopted ECDSA in 2000 in FIPS 186-2, and the standard published a “seed” for each curve whose hash defines the curve’s coefficient b. The P-256 seed was C49D3608 86E70493 6A6678E1 139D26B7 819F7E90, with no account of where it came from. That left people wondering whether the curves had been chosen to hide a weakness. Neal Koblitz and Alfred Menezes summarized the controversy in “A Riddle Wrapped in an Enigma,” and an amateur investigation and a bounty followed. The best story was Jerry Solinas’s 2015 recollection that the seeds came from a hash of a humorous passphrase, which Anthropic says turned out to be wrong. Solinas died in 2023.

How did Claude find the origin of the seeds?

By guessing how the generating software must have worked and looking for a fingerprint. Anthropic describes these steps:

• A guess. Searches for the rumored phrase had come up empty, so Claude assumed the software used a weak PRNG from a 1990s C library, whose output could be recognized.
• A scanner. It slid along each seed bit by bit, testing whether adjacent chunks were consecutive outputs of old generators, across 34 combinations of generator and output slice.
• A fingerprint. Four of NIST’s ten curve seeds had a zero in the top bit of all five 32-bit words, which Anthropic puts at a 1 in 5,810 chance. That matches 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 curves. Their seeds came from the same generator but kept fewer bits (lrand48() >> 23), so Claude recovered the internal state with LLL lattice reduction, a known technique for truncated linear congruential generators. This worked for five NIST prime-curve seeds and five from the ANSI X9.62 standard.
• The timestamps. Stepping the state back to the form srand48 would have set (low 16 bits 0x330E) gave a Unix timestamp for every prime-curve seed, dated between May 1997 and April 1998. The binary-curve seeds read as February 1984, but doubled they map to April 17, 1998, so the program may have halved the clock.
• A sanity check. Claude’s recorded reasoning shows it considered whether it was in a simulated or test environment, then confirmed the result by direct computation: a 32-bit seed plus a small index reproduces all 160 bits of each seed.

Which curves are explained, and which are not?

Most seeds, some base points and not all curves:

Anthropic also found where six curves’ base points came from: P-192 and the five ANSI X9.62 example curves (prime192v2, prime192v3, prime239v1 to v3) use points from the random number generator in FreeLIP, Arjen Lenstra’s long-integer package, whose code early versions of Victor Shoup’s NTL library shipped. The recipe is to seed the generator with a small integer, throw away seven outputs, draw 26-bit values reduced mod p until x lies on the curve. The seeds are 20000 for P-192, and 20420, 20507 and 20509 for prime239v1 to v3, and 20512 and 20517 for prime192v2 and v3. As far as Anthropic knows, no NIST base point had been explained before. The base points for P-224, P-256, P-384, P-521 and the NIST binary curves do not fit and remain unexplained, as does the seed for B-163.

Does this mean the NIST curves are safe?

Anthropic says the result is not a break, but it does not prove the absence of a backdoor. The post says this is not “a cryptographic break, new attack, or weakness,” and that it makes the team “more confident” the curves were chosen without intentional weaknesses, because the seeds came from a simple generator and a clock that “anyone can now reproduce.” Our reading is more careful: a harmless-looking origin makes a deliberate backdoor less plausible, but the post itself lists reasons it cannot settle the question.

• Skipped candidates. Not every candidate seed gives a viable curve, but some viable ones were skipped. For P-256, the published seed is candidate 1,842, yet candidate 876 also gives a prime-order curve of the right size. P-224’s run passed over three such curves and the ANSI examples seven more. The criteria are unknown.
• A possible timestamp search. Anthropic notes it is conceivable that someone searched over timestamps to get a curve with a chosen property, though that would only make sense if the timestamp was then disclosed as evidence of innocence. “Nothing in the numbers shows how many runs there were.”
• Weakened curves. Anthropic does not think weakened curves were selected, since that would mean weakened curves are common and easy to find.

Can you check the result yourself?

Yes, and we did. Anthropic published two public-domain (CC0) Python scripts. We ran them locally without modification. The first printed all 14 seed values, and the P-256 line, C49D360886E704936A6678E1139D26B7819F7E90 from candidate 1,842 at 1997-08-16 01:52:34 UTC, matches the seed the post quotes. The second printed True for all six base-point checks against the published x-coordinates hard-coded in the script. We also recomputed the post’s 1 in 5,810 figure: it is the chance that at least four of ten seeds would show a zero top bit in all five words, assuming each top bit is zero or one with equal odds, which comes to 1 in 5,810. We did not independently check the other curves’ seeds against NIST documents. What the scripts show is that the claimed timestamps and candidate numbers regenerate the seeds, which is strong evidence on its own because a 32-bit seed plus a small index cannot match 160 bits by chance.

What is still unknown about the NIST curve seeds?

• The binary curve B-163. Nothing Claude tried fits its seed.
• Base points for P-224, P-256, P-384 and P-521 and for the NIST binary curves.
• Why some valid candidates were skipped.
• Who ran the 1990s program and how many times. The numbers cannot say.
• How the binary-curve timestamps were halved. Anthropic calls that reading a possibility.

What to keep in mind

These are our observations:

• It is a result you can reproduce. The code is public, short and runs in a second.
• “Explained” is not “proven safe.” The post says so itself and lists what is left.
• The process is the news as much as the answer. An internal model, given no hint, guessed a hypothesis, built a scanner and verified the result, in under half an hour, after humans had failed for years; the post does not say how many tries or attempts were made.
• No action is needed. Anthropic says readers should take this as a closing chapter, and most researchers already trusted the curves.

Editorial review: October 17, 2026 (AI). Prepared from Anthropic’s research post (read in full as text, including both code listings), which we cross-checked by running its two public Python scripts locally and by recomputing its stated probability. We did not read the linked papers, did not check seeds against NIST documents beyond the P-256 value the post quotes, and did not use secondary reporting.