Hey there!

Last week, Anthropic announced that its AI model Claude had cracked a cryptography puzzle that had been open since the late 1990s: where the "seeds" behind the NSA-supplied NIST elliptic curves came from. These curves, including the famous P-256, help secure much of the web. For decades nobody outside the NSA could explain how their starting numbers were picked, and that silence fed suspicion of a hidden backdoor.

According to Anthropic's Frontier Red Team, Claude worked it out in under half an hour. The answer turned out to be surprisingly mundane. In this post I'll explain what the seeds are, what Claude found, how Anthropic checked it, and what's still unanswered.

What the NIST curve seeds are

When your browser connects to a website over HTTPS, the site proves who it is with a digital signature. A common way to make those signatures is ECDSA, the Elliptic Curve Digital Signature Algorithm. It relies on a mathematical object called an elliptic curve, and everyone has to agree on exactly which curve to use. That's where standards come in.

In 2000, the US standards body NIST published a set of recommended curves in a standard called FIPS 186-2. For each one, the standard listed a "seed": a long number that gets fed through a hash function to produce one of the curve's key settings. The idea was that the curve came from a fixed process rather than someone's hand-picked choice.

The problem was the seeds themselves. They were supplied by the NSA, and nobody explained where they came from. If you could choose the seed freely, you could in theory try lots of seeds until one gave you a curve with a weakness only you knew about. There's no public evidence that happened, but the concern had history behind it: Dual_EC_DRBG, a different NSA-linked standard, was widely believed to contain a backdoor.

Why nobody could answer it

The popular story was that an NSA mathematician, Jerry Solinas, created the seeds by hashing a humorous passphrase. Anthropic says that account was wrong. Solinas died in 2023, and his former colleagues didn't respond to inquiries, so there was no one left to ask.

That same year, cryptography engineer Filippo Valsorda and other contributors set up a bounty for recovering the seeds. It offered $12,288, tripling to $36,864 if the winner gave it to charity. The bounty was framed around finding the original phrases that had been hashed, which was the leading theory at the time.

What Claude found

The seeds were never hash outputs at all. According to Anthropic's write-up, they came straight out of lrand48, a basic random number generator in the standard C library, which had been started from Unix timestamps (the number of seconds since 1 January 1970).

A random number generator like lrand48 isn't truly random. It starts from a value called its state and then follows fixed rules, so if you know the starting point, you can replay every number it produced. Starting a generator from the computer's clock is a common shortcut.

The clue Claude spotted was small. In four of the seeds, the top bit of every 32-bit chunk was zero. That's a fingerprint of lrand48, which keeps 48 bits of internal state but only hands out 31 bits at a time. Once Claude suspected the generator, it recovered the hidden part of the state, by brute force for some seeds and with a lattice technique called LLL for the others. Then it ran the generator backward to find the timestamp each one started from.

The prime-curve seeds trace back to dates between May 1997 and April 1998. P-256, the curve behind a lot of web security, lines up with 16 August 1997. Anthropic adds that its own staff had tried and failed to make progress when they chased the hash theory. Claude dropped that assumption and went looking for patterns in the numbers themselves.

Claude also explained the "base point", another fixed curve setting, for P-192 and five example curves from a related ANSI standard. Those came from the random number generator in FreeLIP, a maths library written by Arjen Lenstra.

How Anthropic checked it

A result like this is easy to claim and hard to fake, which helps here. Anthropic published Python code, released into the public domain, that regenerates the published seeds and base points from the recovered timestamps. Anyone can run it and compare the output with the numbers in the standard.

Anthropic also gives the odds. The top-bit pattern alone would show up by chance about 1 time in 5,810. And the state recovered from each seed reproduces all 160 bits of it, which Anthropic says wouldn't happen by coincidence across ten seeds. The write-up doesn't describe independent outside confirmation yet, so it's worth watching for cryptographers who rerun the code.

The bounty prize of $36,864 is going to the Internet Security Research Group, the nonprofit behind Let's Encrypt.

Is P-256 safe?

This isn't a break of anything. Anthropic says the finding isn't an attack or a weakness in ECDSA or P-256, and there's nothing users need to do. If anything, it points the other way. A seed made by a simple, reproducible process like a clock-seeded generator makes a deliberate backdoor much less plausible, in Anthropic's words.

It doesn't close every door, though. Some candidate curves that would have worked were skipped during generation. For P-256, candidate 876 would also have produced a valid curve, and nobody knows the rule for choosing one over another. Anthropic doesn't think weak curves were being filtered out, because the number of skipped candidates is small and weak curves would be easy to find. Still, that selection step remains unexplained, along with one binary-curve seed (B-163) and the base points for P-224, P-256, P-384 and P-521.

If you came here from the crypto side: Bitcoin and Ethereum use a different curve, secp256k1, which wasn't part of this story.

The takeaway

For more than 25 years, a handful of unexplained numbers sat inside the standards that help secure the web, and they were a steady source of suspicion. Claude traced them to a 1990s random number generator and a few timestamps from 1997 and 1998, and Anthropic published code so anyone can check.

The result lowers the backdoor worry around P-256 rather than raising it, and it leaves a few smaller questions open. It's also a concrete example of AI being useful in security research, not by being clever with a new attack, but by noticing a pattern in old data that people had looked past while they were chasing the wrong theory.