Claude traced the NIST curve seeds. The private keys were never at issue

Five published NIST prime-curve seeds can now be regenerated from specific dates in 1997 and 1998 and a generator that once shipped with C libraries. Anthropic reports that Claude found the procedure in under half an hour. The reproducible result answers a question about public cryptographic parameters; it does not recover signing keys, forge signatures, or demonstrate an NSA backdoor.

In the relevant NIST and ANSI specifications, a public seed feeds a defined process that derives parts of an elliptic curve's parameters. Every implementation needs the same published parameters. That seed is not an ECDSA account's secret signing scalar, and it is not a nonce produced by a wallet during a signature. Reconstructing it explains how a standardized input might have been chosen, without granting access to any user's private key.

The absence of a documented selection method encouraged suspicion because the NSA had originally supplied seed values. Anthropic's research disclosure replaces one historical unknown with a testable generator and candidate sequence. The evidence is unusually concrete for a model-assisted mathematical result: the proposed timestamps and recurrence regenerate complete published 160-bit seed values rather than merely resembling them.

The disclosed procedure starts the 48-bit lrand48 recurrence at (Unix timestamp << 16) | 0x330E. Each step updates the state as state = (0x5DEECE66D * state + 0xB) mod 2^48. For the prime curves, the upper eight bits of each state form successive bytes; every group of 20 bytes is one candidate. A candidate number specifies which group to read.

For this review, a fresh implementation of that short recurrence reproduced all five full 20-byte outputs exactly from the specified dates and candidate indexes. The table abbreviates the hex for readability; the complete values and published procedure remain in Anthropic's source. This check independently tests deterministic computation. It does not show who ran the historical generator or why one viable curve was picked instead of another.

Anthropic describes two routes to identifying the generator. An unusual pattern of zero top bits pointed toward lrand48. For more heavily truncated outputs, the model used lattice reduction to reconstruct generator state. Neither step is an attack on the elliptic-curve discrete logarithm problem. The search recovered state from deliberately public standardization material generated by a weak, older pseudorandom process.

The recovered recipe does not explain every selection decision. For P-256, candidate 876 appears to have satisfied the reported prime-order screening conditions, although the standardized seed is candidate 1,842. Some other valid-looking candidates were also passed over. The origin of the later NIST prime-curve base points, including P-224, P-256, P-384 and P-521, remains unexplained by the proposed base-point generator. The B-163 binary-curve seed was not recovered in the paper.

Cryptographer Filippo Valsorda, who organized the historical seed bounty, reported independently reimplementing the generation in Go. His analysis also treats additional candidate-selection criteria as unresolved. The bounty's resolution is meaningful independent scrutiny, but the surviving public evidence still cannot reconstruct the intentions of the original standard writers. A matching output is evidence for a plausible generating process, not a record of every decision that led to a standard.

Bitcoin's signature curve is secp256k1, rather than the NIST P-256 domain parameters reconstructed here. X25519 is an elliptic-curve key-agreement scheme, not an ECDSA certificate-signature algorithm. Neither fact changes the narrower finding. The Telegram assertion that Claude somehow recovered ECDSA private keys confuses a public parameter seed with signing secrets.

The useful AI-security outcome is therefore a checkable research trail. The model produced a hypothesis, executable calculations reproduce the published constants, and external cryptographers can inspect what is still missing. Developers have no evidence from this result that existing ECDSA keys need rotating or that an ECDSA exploit occurred. The underlying Case retains the unresolved selection questions alongside the verified output match.