The NIST curve riddle wasn't crypto, it was retro code archaeology

What if one of cryptography's most durable conspiracy theories died not because someone broke a cipher, but because someone recognized a bad random number generator from the 1990s? That is, in essence, what just happened, and we think it is a story about retro computing that happens to wear a cryptography costume.

The seeds were a clock and a weak generator, not a secret sentence

On October 16, 2026, Anthropic published a research post saying an internal Claude research model traced the seeds of the NIST curves P-192, P-224, P-256, P-384 and P-521 to lrand48, the C library's random-number generator, initialized with Unix timestamps from between May 1997 and April 1998. The seeds had been supplied by the NSA for the FIPS 186-2 standard with no explanation. The best-known story was that they were hashes of a joke passphrase. Anthropic says that was wrong, and that the model needed under half an hour.

The result is not a break. Anthropic says plainly that it is "not a cryptographic break, new attack, or weakness in the ECDSA curves." Filippo Valsorda, who ran the bounty, reimplemented the algorithm in Go to verify it, according to dev.to's write-up. The $36,864 prize goes to the Internet Security Research Group.

The skill that won was knowing what 1997 software looked like

Notice how the model got there. Searching for the legendary passphrase failed. What worked was a guess about the era: the generating program probably used a PRNG (pseudorandom number generator) that shipped with 1990s C libraries, and those are weak enough to be recognizable. Claude scanned the seeds and noticed that, in four of the ten, the top bit of every 32-bit word was zero. Anthropic puts the chance of that at 1 in 5,810. That is the fingerprint of lrand48, which returns only 31 bits of a 48-bit state.

Anyone who has poked at demoscene effects, old game save formats or classic tracker code knows this mindset. You don't ask "what did they intend?" You ask "what tools did they have on the shelf?" Linear congruential generators, clock-seeded srand calls, truncated outputs: this is the daily bread of anyone who has reverse-engineered a 16-bit-era title to find out how its "random" loot was rolled. The cryptography community spent 25 years treating the seeds as a political puzzle. The answer sat in the humble toolbox of the time.

We would argue this is the underrated lesson. Old Unix-era code is full of mundane explanations for things that later look sinister, and the people best prepared to find them are the ones who know the period's habits, not only the math.

AI as archaeologist: impressive, but read the fine print

It is tempting to read this as "AI solves 25-year mystery in 30 minutes." We'd temper that. The half-hour figure is Anthropic's own account of an internal run, and the model is not named beyond "an internal research model." As mind-verse notes, the reports document this specific reconstruction, not a general success rate. Some Hacker News commenters also argued that a retroactive search for fitting timestamps could produce similar matches, per borncity. Anthropic's post offers a strong check of its own: each recovered state regenerates all 160 bits of a seed, which it says does not happen by chance.

And the archaeology isn't finished. Anthropic concedes that the B-163 seed remains unexplained, and that it doesn't know how the base points for P-224, P-256, P-384 and P-521 were generated. So the model is a good excavator, not an oracle.

Still, what impressed us is the method, not the speed: form a hypothesis about period software, build a scanner, notice an anomaly, then apply a textbook lattice technique (LLL reduction) to recover the hidden state. That is what a sharp human reverse engineer would do. The difference is that this one never gets bored of trying 34 combinations of generator and output slice.

Use the AI as a shovel, and keep the archaeologists

For P-256 users: nothing to do. Anthropic says there is no action to take. For everyone else, there is a quiet, practical moral. A clock-seeded generator is only as secret as the clock. If your code mints tokens or invite codes with a non-cryptographic generator, we'd suggest switching to your operating system's cryptographic one.

Our verdict: celebrate the result, but celebrate the right thing. The headline is "AI is fast." The better story is that preserving and understanding old code is security work. Keep the old libraries documented, keep the people who can read them, and use the new tools as a very good shovel, not as a replacement for the archaeologist.