The numbers behind P-256, the elliptic curve in web certificates and passkey signatures, came from a computer clock reading 01:52:34 UTC on August 16, 1997. The NSA never said where they came from, so for years people wondered whether the curve hid a backdoor. On October 16, Anthropic gave the answer in a research post, “Claude reveals ECDSA curve origins,” and I reran the calculation myself and got the same numbers. The same week, Hacker News argued over whether passkeys, which sign with that very curve, are a trap. I read both stories together.
Numbers handed down without explanation
ECDSA is the most widely used elliptic curve signature scheme. In 2000, NIST’s FIPS 186-2 standardized five curves of different sizes (P-192, P-224, P-256, P-384 and P-521). Each curve’s coefficient b comes from hashing a 20-byte number, the seed, with SHA-1. Since a hash cannot be run backwards, the argument goes, nobody can rig the seed to get a b they want. The trouble was the seed itself: the NSA supplied it with no account of how it was chosen. Here is the seed for P-256.
C49D3608 86E70493 6A6678E1 139D26B7 819F7E90The suspicion lingered. Neal Koblitz and Alfred Menezes laid out the controversy in their 2015 paper “A Riddle Wrapped in an Enigma.” Daniel Bernstein and Tanja Lange described a technique that, with about 70 bits of freedom in choosing the seed, could target a hypothetical class of weak curves. Jerry Solinas, the NSA researcher who made the seeds, said the seeds came from hashing some humorous English sentences but could never remember which ones, and died in 2023. That year the cryptographer Filippo Valsorda offered a $12,288 bounty to whoever could explain the seeds, tripled to $36,864 if donated to charity.
Nor were we able to find archives from so long ago. If they exist, they are no doubt sitting on a hard drive near the Ark of the Covenant.
Jerry Solinas, the NSA researcher who made the seeds (quoted by Anthropic)
An answer in under half an hour
In October 2026, an Anthropic employee asked an internal research model how the seeds had been generated, deliberately leaving out the hint about hashed sentences. In under half an hour, Claude traced the seeds of all five NIST prime curves. No sentence had ever been hashed. The seeds were output from lrand48, the random number generator in 1990s C libraries, seeded with a Unix timestamp.
Here is how it got there. Claude guessed that the software behind the curves used a pseudorandom generator common at the time; such generators are weak enough that their output can be recognized. Sliding along each seed one bit at a time and testing for consecutive outputs of an old generator, it found a pattern in four binary-curve seeds: the top bit of all 20 of their 32-bit words was 0. That is the signature of lrand48, which returns only the top 31 bits of a 48-bit state. When it tried all 2¹⁷ values for the 17 hidden bits, the next words came out exactly as predicted.
The prime-curve seeds keep only part of each output (lrand48() >> 23), so the generator state was recovered with lattice reduction (LLL). The generator runs backwards as easily as forwards. Once each state was stepped back to the form srand48 sets up (low 16 bits equal to 0x330E), all ten prime-curve seeds, counting the ANSI X9.62 example curves, pointed to Unix timestamps between May 1997 and April 1998. The four binary curves pointed to February 1984, which doubles to April 17, 1998; the program may have halved the clock.
The four binary-curve seeds, split into twenty 32-bit words and drawn bit by bit.
All 20 top bits are 0. By chance, that would happen about once in a million.
Recovering the generator state from the P-256 seed and running it backwards.
The initial state’s low 16 bits are 0x330E, the value srand48 adds, and its top 32 bits are Unix time 871,696,354: 01:52:34 UTC on August 16, 1997.
Lined up, the recovered timestamps all fall between May 1997 and April 1998.
P-256 was made on August 16, 1997. The four binary curves were made minutes apart on April 17, 1998.
This is astonishing: it solves the 25-year-old mystery. Hmm wait. Let me be skeptical: am I in some sort of simulated/test environment?
Claude’s reasoning, from Anthropic’s post
I ran it myself
I ran the code Anthropic published, then rewrote the same calculation in a few lines. P-256’s moment, 01:52:34 UTC on August 16, 1997, is Unix time 871,696,354 (10:52:34 the same morning in Korea). Seed the generator with it, draw 20-byte candidates one after another, and the 1,842nd candidate matches the P-256 seed digit for digit.
from datetime import datetime, timezone
import hashlib
t = int(datetime(1997, 8, 16, 1, 52, 34, tzinfo=timezone.utc).timestamp()) # 871696354
x = (t << 16) | 0x330E # the state srand48(t) sets
seed = b""
for i in range(20 * 1842): # 1,842 candidates of 20 bytes
x = (0x5DEECE66D * x + 0xB) % 2**48 # one step of lrand48
if i >= 20 * 1841: # keep only the last (1,842nd) candidate
seed += bytes([x >> 40]) # lrand48() >> 23 = top 8 bits of the state
print(seed.hex().upper()) # C49D360886E704936A6678E1139D26B7819F7E90
# ANSI X9.62 / FIPS 186 check: seed -> SHA-1 -> c, then b^2 * c = -27 (mod p)
p = 2**256 - 2**224 + 2**192 + 2**96 - 1
b = 0x5AC635D8AA3A93E7B3EBBD55769886BC651D06B0CC53B0F63BCE3C3E27D2604B
z = int.from_bytes(seed, "big")
w0 = int.from_bytes(hashlib.sha1(seed).digest(), "big") % 2**95
w1 = int.from_bytes(hashlib.sha1(((z + 1) % 2**160).to_bytes(20, "big")).digest(), "big")
c = (w0 << 160) | w1
print((b * b * c + 27) % p == 0) # TrueA matching seed is not the whole story, so I also ran the check the standards define. ANSI X9.62 and FIPS 186 hash the seed with SHA-1 to get c and require the curve coefficient b to satisfy the equation below. Plugging in P-256’s published b gives true, and the same check passes for P-192, P-224, P-384 and P-521. The seeds also match, character for character, the list Filippo Valsorda published in the 2023 bounty announcement.
Some questions remain. P-256 was the 1,842nd candidate, yet candidate 876 from the same run also gives a valid curve of the right kind, and nobody knows why it was skipped. Valsorda found roughly twice as many usable seeds as were published. The seed of the binary curve B-163 is still unexplained, and so are the base points of P-224, P-256, P-384 and P-521.
So was there a backdoor?
Anthropic stresses that this is not a break or a new attack; if anything, it makes them more confident the curves have no backdoor. Some on HN pushed back: couldn’t someone have varied the timestamp or candidate number until a weak curve came out? Valsorda, who ran the bounty, did the arithmetic in the post announcing it had been claimed. Even if the NSA could pick any timestamp in 1997–98 and any of the first 16 prime-order candidates, that is barely 30 bits of freedom, far short of the 70 bits the Bernstein–Lange technique needed.
Not enough to intentionally target a hypothetical small class of weak curves, not enough to embed any kind of NOBUS backdoor.
Filippo Valsorda, who ran the bounty
On HN, tptacek wrote: “This is devastating news... for an entire generation of NIST cryptography conspiracy theories.” Valsorda now personally recommends the NIST curves over Curve25519 and its relatives, adding that their rehabilitation comes just in time for them to be retired in favor of post-quantum signatures. The $36,864 went to ISRG, the nonprofit that runs Let’s Encrypt.
The same week, a fight over passkeys
This curve sits under passkeys too. If a site does not name a signature algorithm, the W3C WebAuthn specification that defines passkeys falls back to ES256 (ECDSA on P-256) and RS256. On October 11, “Passkeys are a trap. Do not use them.” reached 1,146 points on HN. Its author, The Hack, described a “hidden dial”: if sites gradually start demanding attestation, a feature that proves which authenticator made a key, only approved devices and operating systems will be able to log in. The post recommends TOTP codes from an authenticator app instead.
Three days later, security researcher Scott Helme replied with “Passkeys are not a trap” (672 points on HN), which drew 814 comments, more than the original’s 577. Helme’s points: the synced passkeys most people use, in iCloud Keychain, Google Password Manager, 1Password or Bitwarden, give websites no attestation at all; a site can ask, but what comes back is none. When attestation is present, it identifies only the authenticator’s make and model, not your OS, browser or whether your phone is rooted. And a TOTP code can be typed into a fake site, while a passkey only works on the domain it was created for.
Swapping a phishing-resistant credential for a phishable one is a really bad trade.
Scott Helme, Passkeys are not a trap
The curves are cleared; what’s left is who sets the rules
As I see it, these are two sides of the same question. Years of suspicion about P-256 ended with a calculation anyone can check. The passkey debate is not about math but about who holds the keys and sets the rules, and Helme also says attestation creeping into consumer logins would be worth pushing back on, loudly. If you are adding passkeys to a site, these are worth getting right.
Include ES256 (-7) in your algorithm list. The WebAuthn spec says sites that want to support a wide range of authenticators should include EdDSA (-8), ES256 (-7) and RS256 (-257).
Request attestation only when you truly need it. Helme notes that consumer sites have been advised for years not to request it.
Keep passkeys in a password manager you trust. If you move between devices and platforms, Helme suggests picking one that lets you take your passkeys with you.
For more than 25 years, nobody knew where those numbers came from, and people wondered who was behind them. It turned out to be a clock in August 1997, and what ended the suspicion was a calculation anyone can run again.
Sources (numbers as of October 20, 2026)
Anthropic, Claude reveals ECDSA curve origins · 1,060 points on HN
Filippo Valsorda, The NIST Elliptic Curves Seeds Bounty Has Been Claimed · 242 likes on Bluesky
Filippo Valsorda, Announcing the $12k NIST Elliptic Curves Seeds Bounty (2023)
Neal Koblitz and Alfred Menezes, A Riddle Wrapped in an Enigma (2015)
The Hack, Passkeys are a trap. Do not use them. · 1,146 points on HN