The 1997 Timestamp That Cracked a 26-Year NIST Curve Mystery

For twenty-six years, five strings of hexadecimal digits sat inside a federal cryptography standard. Engineers used them every day. The standard explained how to check the curve parameters derived from those strings. It did not explain why those strings existed.

The strings were seeds for five NIST elliptic curves: P-192, P-224, P-256, P-384 and P-521. ECDSA, the elliptic-curve digital signature algorithm, was folded into FIPS 186-2 in 2000. Before the algorithm could be used, the curves had to be fixed. A seed is the starting material for that process. Feed the seed through the steps in the standard, and the resulting parameters can be checked. A public, reproducible seed gives people a reason to trust that the parameters were not hand-picked in a back room.

That trust had a hole in it. The seeds were public, but their origin was not. The question was simple and stubborn: why these numbers?

The payroll joke

The most durable clue was a memory. Jerry Solinas, the NSA mathematician who supplied the seeds, later recalled something about a joke phrase involving a raise for Bob and Jerry, converted into a number, with a counter added. The phrase “give Bob and Jerry a raise” became the story people repeated. It had the shape of a good origin myth: a few engineers turn an office joke into digits, and the digits end up in a standard used by the internet.

Filippo Valsorda, a cryptography engineer, put a bounty on the question and invited people to find the preimages of the five seeds. The search went on for years. People tried passphrases, hashes and counters. The payroll joke pulled the field toward human-readable text. That was the wrong direction.

Claude was not given that clue. According to Anthropic, the company handed the problem to an internal research model without mentioning the payroll story. Claude started somewhere else: the C standard library of the 1990s.

The row of zeros

The guess was that the seeds came from a pseudo-random number generator common in Unix and C software. Such generators produce numbers that look noisy but follow a fixed recurrence. If you can identify the recurrence, you can reverse the output. Claude wrote a scanner and tested 34 combinations of generator and output-truncation method, shifting through the bits of the public seeds.

One statistical feature broke the case open. When four of the seeds were split into 32-bit integers, the resulting twenty integers had a highest bit of zero. Every one of them. If the numbers were random, that would be an absurd coincidence. A run of zeros like that is a fingerprint of a generator that returns fewer bits than the storage slot allows.

The suspect was lrand48. The generator keeps a 48-bit integer. On each call, it multiplies that integer by a fixed constant, adds another constant, keeps the low 48 bits as the next state, and returns the high 31 bits. Put a 31-bit output into a 32-bit word, and the top bit has to be zero. The row of zeros was the padding.

Claude then used the LLL lattice-reduction algorithm to recover the generator state from the truncated outputs. LLL is a standard tool for problems where part of a state is known and part is missing. With the state recovered, only one question remained: how was the generator started?

The initialization function was srand48. It takes an input value, places it in the high 32 bits of the 48-bit state, fixes the low 16 bits at 0x330E, and lets the recurrence run. Claude pointed the search at Unix timestamps. The candidate inputs clustered between May 1997 and April 1998.

For P-256, the initialization moment was 01:52:34 UTC on 16 August 1997. Run the generator from that timestamp, take the 1,842nd candidate, and the seed begins with C49D. The other four curves mapped to their own timestamps and candidate numbers.

The answer was a clock.

The check

Anthropic’s account needed an independent check. Valsorda reimplemented the generation process in Go and confirmed the result. Anthropic collected the bounty and donated the $36,864 to the Internet Security Research Group, the nonprofit behind Let’s Encrypt.

Cryptography does not run on stories. It runs on reproduction. Claude supplied a hypothesis and a search path. Valsorda supplied an independent implementation. The result survived the check.

The work also left loose ends. Anthropic said the original program skipped some candidate curves that also appeared to qualify, and the reason is still unclear. The seed for B-163 and the generation method for some base points remain unexplained. The main puzzle is solved; the edges are not clean.

What the timestamp settles

The result does not expose a new vulnerability. Anthropic’s conclusion is that the five curves do not contain a hidden backdoor and can be used. The seeds came from a predictable Unix timestamp and a weak pseudo-random number generator, not from a secret selection process. Even if someone had wanted to manipulate the parameters, the room to do so was tiny.

For years, the missing origin of the seeds fed a suspicion that the parameters had been chosen to give some agency an advantage. The recovered process does not support that suspicion. It replaces a conspiracy with a timestamp and a library call.

Standards are written to the bit. The work behind them can depend on a temporary program and a machine that left no log. Twenty-six years later, the birth certificate had to be reconstructed by scanning bits and testing old generators.

Claude’s half hour left the security of elliptic curves where it was. What changed is that one blank spot is now legible. The seed for P-256 begins with C49D. The clock read 01:52:34 UTC on 16 August 1997. The rest is arithmetic.