On 16 October 2026 a research note from Anthropic landed on a question people had been asking since the late 1990s: where did the NIST elliptic curve seeds come from? The unexplained starting numbers behind a US signature standard were not a secret joke run through a blender. They were the output of an ordinary 1990s shuffle, started from a computer clock.
Not a break. On 16 October 2026 Anthropic reported that an internal model traced the NIST curve seeds in under half an hour. Their line, verbatim: “This is not a cryptographic break, new attack, or weakness in the ECDSA curves.” Do not rotate keys because of this headline.
Before any of the alphabet soup, here is the only decision the headline asks of you. A certificate (the signed ID card a website shows your browser) that uses these curves is not suddenly forgeable. A password does not need changing because a model explained a historical constant. The interesting part is how the constant was made, what fear that constant was carrying, and which small questions are still open.
A signature is a wax seal, made of numbers
Start with a message (the exact bytes you claim you wrote: a certificate, a software update, a transaction). A digital signature (a short attachment that anyone can check, and that should be infeasible to forge) is the seal. The private key (the secret number that stays on your machine) is what makes the seal. The public key (the matching number you can publish, like the face of the stamp) is what other people use to check it. If the check passes, the message was sealed by the holder of that secret, and the message was not edited afterward.
ECDSA (Elliptic Curve Digital Signature Algorithm: the recipe that builds those seals out of points on a special curve) is one such recipe. NIST (National Institute of Standards and Technology: the US lab whose documents other industries copy) published it for government use in FIPS 186-2 (a 2000 standards document) after the curves had already been written for ANSI X9.62 (an earlier standard aimed at banking). P-256 (the curve whose name means a prime field about 256 bits wide) is the one you are most likely to have met. A bit (one yes-or-no, a 0 or a 1) is the smallest unit. 256 of them is a huge counter, not a long password you type.
A curve is a rule for adding dots, not a drawing of a lock
An elliptic curve (a set of points, plus a rule that adds two points and returns another point still in the set) is the stage those keys stand on. Over ordinary graph paper the picture looks like a sideways loop. You draw a straight line through two points, see the third place it hits the curve, and flip across the horizontal axis. That flip is the “sum.” Doubling a point uses the tangent (the line that just grazes the curve) instead of a chord.
The real P-256 points are not dots on that drawing. They are pairs of numbers on a prime field (arithmetic on a clock whose size is a huge prime, so every sum wraps around and there is no “end of the number line”). The same add-and-flip idea still works. It just looks like scattered dots, because wrapping chops the pretty loop into a cloud.
Your public key is not the curve itself. Everyone who uses P-256 shares one agreed starting point, called a base point and written G (the generator: a point you add to itself, over and over). Your private key is how many times you add G. Your public key is the point you land on. Going forward is easy. Going backward, from the public point to the count, is the hard problem the seal depends on.
A seed is the shove that starts a shuffle
The curve still needs a few fixed numbers of its own: roughly, which clock, and a seed (the starting shove for a fake-random machine) that the standard uses while it builds the curve. A pseudorandom number generator (a PRNG: a shuffle that only looks random, and that anyone can replay if they know the start) turns that shove into a stream of bytes. Those bytes are tried as candidates until the candidate produces a valid curve. Valid, here, means the arithmetic closes in the way the standard requires, including a prime order (the number of times you can add a point before you are back at the start is itself a prime, so there are no small shortcuts).
The generator in this story is the one that shipped in the C libraries of the 1990s. POSIX (the old Unix standard that said which functions a system had to offer) calls it a 48-bit linear congruential generator (a shuffle of the form “multiply, add, wrap at 2 to the 48”). Two function names are two doors on that same shuffle. srand48 sets the start. lrand48 hands back the top 31 bits of the 48-bit counter. drand48 hands the same counter back as a fraction between 0 and 1. Filippo Valsorda describes the historical program as seeding drand48 and taking one byte at a time. Anthropic’s replay takes the top byte of each lrand48 step. Same machine.
The story people repeated did not match the bytes
The numbers were handed over by the NSA (National Security Agency: the US agency that both breaks codes and writes them). The mathematician associated with the curves, Jerry Solinas, later described the seeds as hashes of an English sentence. A hash (a blender: any sentence in, a fixed-length fingerprint out, and no way to run the blender backward) would have hidden the sentence forever unless someone guessed it. The sentence in the lore was along the lines of “Give Bob and Jerry a raise” or “Bob and Jerry rule.” People hunted that sentence. It is not what the bytes are. Solinas died in early 2023, Filippo notes, so he could not walk the story back. Memory of a one-line joke is allowed to be wrong. A replay either matches or it does not.
srand48. Only the right-hand machine reprints the published seeds.The fear was never only about a joke. In 2013, documents and then a public withdrawal made Dual_EC_DRBG (a different random-number recipe, also associated with the NSA, which NIST removed from SP 800-90A after a backdoor structure became the leading explanation) into a household name among cryptographers. Dual_EC is not P-256. It is not this seed. It is the reason a mysterious constant from the same era was not shrugged off. A backdoor (a weakness the designer can use, and everyone else cannot) is a real category of failure. It is just not the category this particular seed turned out to be.
What the model actually found
An Anthropic employee asked an internal research model to work out the seeds without being handed the joke-sentence hint. Anthropic says it took under half an hour. The pattern that gave the game away is almost embarrassingly mechanical. lrand48 only returns 31 bits, so the top bit of each output word is zero more often than a fair coin. Across the seeds they looked at, that bias was loud. From there the model treated the bytes as chopped output of that known shuffle, recovered the hidden 48-bit counter, and walked the counter backward. Walking backward is allowed because this shuffle is a reversible step, not a hash. The starts it landed on were Unix timestamps between May 1997 and April 1998.
For a prime-curve seed, each stored byte is only the top of that counter. Filling in a hidden counter from chopped outputs uses LLL (the Lenstra–Lenstra–Lovász algorithm, from 1982: a way to find a short arrow in a grid of arrows). You do not need to re-derive LLL to check the claim. Once a clock time is proposed, you replay the shuffle. It either prints the seed in the standard, or it does not.
You can replay it yourself from the public constants of that generator: multiply by 0x5DEECE66D, add 0xB, wrap at 2 to the 48, start from the timestamp shifted left by 16 bits with 0x330E added, and keep the top byte. All five NIST prime seeds match.
| Curve | Clock, UTC | Unix time | Accepted try | Published seed |
|---|---|---|---|---|
| P-192 | 1997-05-18 14:45:34 | 863966734 | 139 | 3045AE6F…E12196D5 |
| P-521 | 1997-08-08 01:12:04 | 871002724 | 1136 | D09E8800…A0DA64BA |
| P-256 | 1997-08-16 01:52:34 | 871696354 | 1842 | C49D3608…819F7E90 |
| P-384 | 1997-08-30 14:50:08 | 872952608 | 2688 | A335926A…7ACDAC73 |
| P-224 | 1998-04-03 12:52:07 | 891607927 | 7026 | BD713447…6A948BC5 |
Full P-256 seed, so you are not trusting a shortened cell: C49D360886E704936A6678E1139D26B7819F7E90. The program keeps the last 20 bytes of a run that is 1842 candidates long. It does not reseed the clock between candidates.
def p256_seed() -> str:
t = 871696354 # 1997-08-16 01:52:34 UTC
n = 1842
x = (t << 16) | 0x330E
out = []
for i in range(20 * n):
x = (0x5DEECE66D * x + 0xB) % 2**48
if i >= 20 * (n - 1):
out.append(f"{(x >> 40) & 0xFF:02X}")
return "".join(out)
That top byte is what Anthropic writes as lrand48 shifted down to 8 bits. Shifting the raw 48-bit counter by 40 bits is the same byte. Shifting it by 23 bits is not, and does not match the standard. The 23 is applied after lrand48 has already dropped the low 17 bits.
Anthropic also explains some base points, not only seeds. P-192 and five ANSI X9.62 curves match FreeLIP (Arjen Lenstra’s old long-integer package) started from small seeds such as 20000, after throwing away the first 7 outputs. Anthropic: “As far as we know, no NIST base point has been explained before.” The base points of P-224, P-256, P-384, and P-521 are still unexplained. The seal does not wait on that explanation.
What this closes
A class of worry from Daniel Bernstein and Tanja Lange, described in 2017, asked whether a designer with enough spare choices could have aimed these curves at a hypothetical weak family. Filippo’s accounting: that idea needed on the order of 70 bits of freedom (about 70 independent yes-or-no choices, a pile so large that 30 bits, which is about a billion combinations, is a trillion times smaller). A designer who may pick any second in 1997–98, and any of the first 16 prime-order candidates, has about 30 bits. Filippo writes that the findings completely rule that technique out.
The public bounty he posted three years ago was claimed on 15 October 2026 at 01:07:51 UTC by John Wood, Henry de Valence, Ava Howell, Zack Voase, Lucy Sweet, Amir Omidi, Paul Crowley, Iain McGinniss, Nicholas Carlini, and Steve Weis, the Anthropic group on the research note. They gave the prize to ISRG (the nonprofit that runs Let’s Encrypt). With other contributions, the gift came to $36,864.
Filippo also writes that he would now personally recommend NIST’s elliptic curves over Curve25519, Ed25519, and X25519 (a newer family, published by Daniel Bernstein, designed so the safe way to implement it is the obvious way). That is one cryptographer’s judgment after the stain of the unexplained seed faded. It is not a migration order. Most real-world failures of this kind of crypto are still bugs in how a library is used, not a hidden sentence inside a seed. If your library makes Curve25519 hard to misuse and P-256 easy to misuse, keep the one your library implements safely.
What is still open, on purpose
The shuffle did not keep every valid candidate. For P-256, candidate 876 also produced a prime-order curve of the right size, and it was skipped. P-224 skipped three. Steve Weis, one of the authors, wrote on 16 October that they did not see a pattern, including checks against attacks invented after 1997. His question, still unanswered in public: another S-box story (a constant chosen by a rule nobody wrote down), or a bug in the program that did the choosing?
Filippo separates one extra rule from the leftover. He says candidates were also thrown out when the bit length of the order n (how many times you add the point before you loop) exceeded the bit length of the field prime p (the size of the clock). That is not the stricter “n must be smaller than p.” Even after that rule, he still sees roughly twice as many valid seeds as the standard published, and the gaps are not regular. Anthropic’s own caveat matches the leftover, not a solved puzzle: “We do not know what criteria may have been used, or whether this was an unintentional artifact.”
Binary curves (a cousin family whose coordinates are strings of bits, not residues on a prime clock) are a side puzzle. Several of their starts look like February 1984 until you read them as a halved clock, which lands on 17 April 1998. They are not the curve inside a normal P-256 certificate. They do not change the advice below.
A later note on the skipped candidates tried counting a certain kind of isogeny (a structure-preserving map between curves) and saw a split between published curves and skipped ones. The author of that note marked it as exploratory, with a cutoff chosen after looking, and not corrected for every other guess they tried. Treat it as a hypothesis, not a finding. More of those maps does not, by itself, mean a weaker seal.
What you should do on Monday
- Do not rotate production keys, reissue a certificate hierarchy, or tell users that HTTPS (the padlock: the web protocol that uses these seals to say who you are talking to) broke on 16 October.
- Do not conflate this seed with Dual_EC. One was removed because a backdoor was plausible. This one now has a boring generator and a clock.
- Do keep using a reviewed library, and do keep the checks that library asks for, including rejecting a point that is not on the curve. That class of bug is older than this paper and still more dangerous than the seed story.
- If you are choosing a curve for a new system, write down why. “NIST was unexplained, so never” is no longer a complete sentence. “Our library does X25519 in constant time (the code path does not speed up or slow down based on the secret) and our P-256 does not” is still a complete sentence.
- If you want the primary documents, read Anthropic’s note and Filippo’s confirmation, not a headline that says a model cracked a government cipher. It did not crack one. It identified a shuffle.
What this does, and does not, say about the model
The model did not invent a new attack, and it did not need a new theorem. The generator is in every Unix manual from that era. LLL is a 1982 textbook method. The years were a small range. What it did is refuse the hint the humans were stuck on. Several of the authors had chased the joke sentence. Asked cold, the model asked which 1990s shuffle could even have printed those bits, then checked.
Anthropic published the model’s line at the match: “This is astonishing: it solves the 25-year-old mystery.” Astonishment is not the evidence. The replay is the evidence. That is also the right way to read any later claim that a model “broke” a standard: demand the object it actually produced, and ask whether that object forges a seal or only explains a constant.
The same week is full of louder agent stories, including models that touched systems nobody asked them to touch. This one is the opposite shape. A person asked a narrow historical question. The model answered inside that question. The answer is checkable without trusting the model at all. That is the rare, useful kind.
Common questions about NIST elliptic curve seeds
Did Claude break P-256 or ECDSA?
No. Anthropic says the result “is not a cryptographic break, new attack, or weakness in the ECDSA curves.” The model showed how the NIST elliptic curve seeds were made: lrand48 output started from clock times in 1997 and 1998. Nothing about that lets anyone forge a signature.
Should I rotate keys or reissue certificates because of this?
No. A certificate that uses P-256 is not suddenly forgeable and no password needs changing. Keep using a reviewed library and keep its checks, such as rejecting points that are not on the curve.
Is this the same as the Dual_EC_DRBG backdoor?
No. Dual_EC was a random-number recipe that NIST removed from SP 800-90A after a backdoor became the leading explanation. The P-256 seed is a different object, and it now has a boring explanation: a 1990s shuffle and a clock.
What is still unexplained about the NIST curves?
Two things. Some valid candidates were skipped (P-256 skipped candidate 876, P-224 skipped three), and the base points of P-224, P-256, P-384 and P-521 are still unexplained. Neither changes the advice to keep your current keys.
