The Mystery Seeds Behind NIST's Curves Were Never Hashes, and Claude Found Out in Under Half an Hour

A question that stayed open after the one person who might have answered it died in 2023 had a mundane answer: a 1990s random number generator initialised from the clock. The authors say that answer makes them more confident the curves were chosen honestly, not less.

Executive Summary

• ECDSA was adopted by NIST in 2000 as part of the FIPS 186-2 Digital Signature Standard. The specifications published "seed" parameters whose hash value was meant to define the curve coefficient b. The NSA supplied the seeds with no explanation or justification.
• In October 2026, an Anthropic employee asked an internal research model to work out how the seeds were generated, without pointing at the clue. In under half an hour, Claude found that none of the seeds were hash outputs. They were the output of lrand48, a common pseudorandom number generator initialised from the clock.
• The finding is not a cryptographic break, new attack, or weakness in the ECDSA curves. The authors say it makes them more confident the curves were chosen without backdoors or intentional weaknesses.
• Claude also explained the base points of six curves from May 1997 as coming from the random number generator in FreeLIP, Arjen Lenstra's long-integer arithmetic package. As far as the authors know, no NIST base point had been explained before.
• Open questions remain: how the base points of P-224, P-256, P-384 and P-521 were selected, and what criteria, if any, were behind the skipped candidate curves.

A coefficient that looked derived and a seed nobody could account for #

ECDSA was adopted by NIST in 2000 as part of the FIPS 186-2 Digital Signature Standard. The specifications for its curves carried a "seed" parameter whose hash value is used to define the coefficient b of the curve. On paper, that is a reassuring design. If the coefficient comes out of a hash of a published seed, the argument goes, nobody could have tuned the curve by hand.

That argument is only as good as the seed. The seeds were provided by the NSA with no explanation or justification, and that gap is the whole problem. A hash is a one-way door: it proves the coefficient followed from the seed, and says nothing about where the seed came from. For years the seeds sat in the standard as unexplained constants.

There was a story to fill the gap. The best-known version had Jerry Solinas, a longtime NSA employee, generating the seeds from a hash of a humorous passphrase. The source later says this turned out to be wrong. Stories like that tend to be believed because they're specific and a little charming, and because nobody can contradict them. They fall short as evidence. The practical consequence was that nobody could check the claim, and searches for the phrase, built from the rumours, had come up empty.

The obvious person to ask was Solinas. Jerry died in 2023, and other colleagues at the time were not responsive. That left open the question of how these seeds were originally derived.

I'd argue this is the right way to see the situation: a provenance question that depends on a few people's memories is a fragile arrangement for a standard that underpins signatures. The interesting thing about what happened next is that it didn't need those memories. The answer was sitting in the published seeds, waiting for someone to test the right hypothesis.

Thirty minutes, no hint, and a result that wasn't a hash #

In October 2026, a curious Anthropic employee asked an internal research model whether it could figure out how those seeds were generated, without pointing at the clue. The phrasing matters. The model wasn't told what to look for, and it wasn't handed the answer to confirm.

In under half an hour, Claude discovered the origins of the NIST P-192, P-224, P-256, P-384 and P-521 seeds. The result is blunt: none of the seeds were the results of any hash algorithm. They were the output of the C library's lrand48 random-number generator.

So the passphrase story was never going to be found, because there was no passphrase to find. The seeds were generated by a common pseudorandom number generator initialised from the clock. It's an unglamorous explanation, and that's precisely its appeal: it needs no secret, no special knowledge, and no unexplained constant.

The mechanism is simple to describe. Each iteration of the algorithm draws 20 bytes from the generator as a candidate seed. The iteration count is the interesting detail, because it shows the process was a search and not a single draw. P-256, for example, required 1842 iterations to output the standardised seed. Whoever ran this program let it churn through candidates until one produced a curve that met their requirements.

The authors are careful about what this does and doesn't mean, and their framing is worth repeating. This is not a cryptographic break, new attack, or weakness in the ECDSA curves. There is no action to be taken. They go a step further and say it makes them more confident the curves were chosen without any backdoors or intentional weaknesses. That is a hedged conclusion, and it should stay one. The source frames it as the authors' confidence, which is a different thing from a proof of the curves' innocence. What the finding gives is a mundane, checkable account in place of an unverifiable story.

How a scanner found the fingerprint of a 1990s generator #

The method deserves attention, because it's the part other people can reuse.

Claude guessed that the software that generated the curves used a PRNG that shipped with 1990s C libraries. The source treats this as a guess, and it was a good one. It narrowed an unbounded search to a short list of candidates from one era.

Claude then wrote a scanner. It slid along each published seed one bit at a time and tested whether adjacent chunks were consecutive outputs of a 1990s-vintage generator. The scan covered 34 combinations of generator and output slices. The hit came as a pattern in the top bits, one that would happen by chance with probability 1/5810.

That pattern was a signature of the linear congruential generator lrand48, which only returns the top 31 bits of a 48-bit state. Here the generator's design leaks. Because lrand48 hides 17 bits of its 48-bit state on every call, the output has a regularity that a random string wouldn't show, and a scanner built to look for that regularity can find it.

To recover the state, Claude took the first word and tried all 2^17 values of the 17 hidden bits. That's a small search, and it's cheap because the generator is so simple. Each candidate state could be checked against the next chunk of the seed, and the right one made the whole sequence line up.

The prime-curve seeds were harder, though only slightly. They came from the same lrand48 generator but kept fewer bits of each output. Fewer visible bits means less to anchor a guess, so the brute-force trick no longer applies as neatly. The source's answer is that recovering the state of a truncated linear congruential generator is a textbook lattice problem, solved with the Lenstra-Lenstra-Lovasz (LLL) basis reduction algorithm. A model could recognise that, and apply a standard tool to it, without anything exotic.

The five NIST prime-curve seeds, plus five more from the ANSI X9.62 standard, all had the same pattern: lrand48() >> 23. Ten seeds sharing one extraction rule is strong evidence of a single process behind them.

Then comes the check that separates a lucky fit from a real one. Each recovered 48-bit state regenerates all 160 bits of its seed, which does not happen by chance. A partial match could be coincidence. A full regeneration of every bit is a much harder thing to explain away, and it's the reason the result can be stated plainly.

Running the generator backwards to read the clock #

Recovering a state tells you how the seed was produced. It doesn't yet tell you when. For that, Claude used a property of the generator: it runs backwards as easily as forwards. For each seed, Claude stepped the state back until it reached the form that srand48 initialisation would produce, with the low 16 bits equal to 0x330E.

That form is a fingerprint of its own. If a recovered state can be wound back to something with the low 16 bits at 0x330E, the generator was started the standard way, from a seed value passed to srand48. And the seed value, in this case, was a time. The seeds were generated using the weak PRNG seeded by Unix timestamp.

Claude's internal thinking at the time recorded the moment of recognition: all top bits were clear, 20 bits, with chance 1e-6. It's a small detail, but it shows the reasoning working on the numbers as they appeared, not on a story assembled afterwards.

The dates were not all clean. The four binary-curve initialisations read as February 1984, which is not a date anyone would expect for a generator in use in the late 1990s. With the timestamps doubled, the binary-curve initialisations map to April 17, 1998, two weeks after the P-224 run. The source concludes that the program may have halved the clock. That is hedged, and it should be: it's a proposed explanation for why the raw values read as 1984, and a doubling that lands two weeks after another run is suggestive without being a confirmation of the program's internals.

I find this the most persuasive part of the whole account, for a reason independent of the cryptography. A fabricated story would have produced tidy dates. This one produced an awkward one, then a correction that put the binary curves in a coherent sequence with the P-224 run. Messy data that resolves under a simple hypothesis is how real provenance looks.

The base points have a recipe, too #

Seeds define the curves. The base points are a separate matter, and the source treats them separately.

The base points of six curves generated in May 1997 (P-192 and the five ANSI X9.62 example curves prime192v2, prime192v3 and prime239v1 to v3) come from the random number generator in FreeLIP, Arjen Lenstra's long-integer arithmetic package. Early versions of Victor Shoup's NTL library shipped the same code. That second fact matters for checking: the generator exists as published code that others can read, not as a private tool.

The recipe is short. Seed the generator with a small integer. Throw away seven outputs. Generate candidate x-coordinates from 26-bit outputs reduced mod p. Repeat that candidate generation until x is on the curve.

Claude found the generator seeds: 20000 for P-192, 20420, 20507 and 20509 for prime239v1 to v3, and 20512 and 20517 for prime192v2 and v3. These are small integers of the kind a person types into a program, which is exactly what the recipe's first step calls for.

The authors make a claim here that's modest and worth quoting in spirit: as far as they know, no NIST base point has been explained before. The hedge is theirs, and it's appropriate. They aren't asserting a survey of every document ever written, only the limit of their knowledge.

Then the recipe stops working. The base points of P-224, P-256, P-384 and P-521 don't fit this recipe, and the authors were not able to explain how they were selected. A write-up that glossed over this would look tidier, and the authors left it in. The explanation covers six curves from May 1997 and leaves four of the NIST prime curves' base points unexplained.

Candidates that were passed over #

The last finding is the one most likely to start arguments, so it's worth reading precisely.

For P-256, the published seed is candidate 1842. But candidate 876 of the same run also gives a prime-order curve of the right size, with parameters chosen the same way as on the published curve. In other words, the process passed over a curve that, on the face of it, would have been acceptable.

It isn't a one-off. P-224's run passed over three such curves, and the two runs behind the ANSI X9.62 example curves passed over seven more.

The authors are direct about what they don't know. They do not know what criteria may have been used for skipping curves, or whether it was an unintentional artifact. That's a limitation, stated as one, and the hedge on "unintentional artifact" is the honest position: the data shows candidates were skipped and doesn't show why.

They then offer a judgement. Because the number of skipped candidates is small, they do not believe it is plausible that weakened curves were selected. That is hedged reasoning about plausibility, and it rests on the counting. If a process skips only a handful of candidates in total, there is little room in which to search for a weakness.

One caveat remains, and the source states it as a possibility and not a finding. It is still conceivable that these curves were selected to have a specific property in principle by searching over timestamps to the random number generator. This is speculation, flagged as such. It shouldn't be read as evidence of anything, and it shouldn't be quietly dropped either. A fair account keeps it on the table as an unexcluded route, while noting that the authors consider weakened curves implausible.

What the result changes, and what it leaves open #

Start with what it doesn't change. The curves are not broken. The source says so twice, in different words, and there is no action to be taken. Anyone reading this as a reason to rip out P-256 has misread it.

What it changes is the status of an old doubt. For as long as the seeds were unexplained, "provided by the NSA with no explanation" was a standing question mark over a standard. That question mark now has a concrete answer. The seeds were not inscrutable hashes of a secret phrase. They were lrand48 output from a clock-seeded program, regenerating every bit of each seed from a recovered state. An explanation that anyone with the published seeds can test beats a rumour that no one can.

There's a point here for founders and engineers who build on cryptographic standards. Provenance claims are cheap to make and expensive to check, and the check described here took under half an hour once the right question was asked. The scanner, the 2^17 search and the lattice reduction are all standard moves. What was missing for years was someone doing the unglamorous work of trying them against the published numbers.

I'd also resist the temptation to oversell the method. The source reports one team's result on a specific set of seeds. It doesn't claim the same approach will crack every unexplained constant in every standard, and I won't claim it for them. What it demonstrates is narrower and, to my mind, more useful: when a parameter's origin is a mystery, a careful model with a plausible guess about the era's tooling can test the guess quickly and show its work.

The unfinished business is clear enough to be a research agenda. Four base points, those of P-224, P-256, P-384 and P-521, still lack an explanation. The skipped candidates, such as 876 against the published 1842 for P-256, lack a stated criterion, and nobody yet knows whether the skipping was deliberate or an artifact. Whether those answers survive in old source code, in surviving colleagues' memories, or in the same kind of pattern-hunting that cracked the seeds is the open question. The seeds took half an hour; the base points have already resisted this approach once.

Questions? Answers.

References #

• Anthropic Frontier Red Team, (2026). Claude reveals ECDSA curve origins ⧉. Anthropic.
• National Institute of Standards and Technology, (2000). FIPS PUB 186-2: Digital Signature Standard (DSS) ⧉. NIST.
• Victor Shoup, (2024). NTL: A Library for doing Number Theory ⧉. libntl.org.

Last reviewed 2026-11-01.