The NIST P-256 Backdoor Mystery Is Settled: The Seeds Were Just 1997 Timestamps

For more than two decades, the "magic seeds" behind curves like NIST P-256 were one of cryptography's great unsolved mysteries. Because the seeds' origin was unknown, the suspicion that "the NSA planted a backdoor" could never be definitively refuted. This month, Anthropic's Claude research model traced the seeds back to a 1997 Unix timestamp, reproducible with just 11 lines of C code. The mystery is solved—but the story isn't entirely over.

The Seed Mystery: From FIPS 186-2 to a Bounty

P-192, P-224, P-256, P-384, and P-521 were published in 2000 with FIPS 186-2. Each curve's b coefficient is derived by hashing a 20-byte seed with SHA-1. The seeds were supplied by the NSA, and their origin was never publicly explained. The generator, Jerry Solinas, reportedly said they were hashes of English sentences, something like "Jerry deserves a raise," but he passed away in 2023, and no one ever managed to reproduce that claim.

In October 2023, Filippo Valsorda launched a bounty: $12,288 for the seeds, tripled if the winner donated the prize.

On October 15, 2026, the Anthropic team claimed the bounty. According to their research article, an employee asked the internal Claude research model to work out how the seeds were generated, and it had the answer in under half an hour. The English-sentence claim was wrong. The actual method is as follows:

• The seeds are raw output from the POSIX srand48/lrand48 family of PRNGs, seeded with the current Unix time, with no hashing involved.
• The tell was this: in all four seeds, the high bit of every 32-bit word is zero. lrand48 returns only the top 31 bits of its 48-bit state, and the remaining 17 hidden bits were recovered by brute force; for outputs that retain even fewer bits (lrand48() >> 23), the state was recovered using LLL lattice basis reduction.
• Rewinding the state lands exactly where srand48 set it from a timestamp. The timestamps for the prime-field curves cluster between May 1997 and April 1998.
• The program draws 20 bytes at a time as a candidate seed and keeps going if the resulting curve is invalid. P-256 hit on iteration 1842.

Filippo reimplemented it in Go and got identical output. The timestamps he gives are: P-521 on 1997-08-08, P-256 on 1997-08-16, P-384 on 1997-08-30, and P-224 on 1998-04-03. The $36,864 bounty was donated to ISRG, the organization behind Let's Encrypt.

Reproducing the P-256 Seed Yourself

You can verify it yourself. P-256 is the truncated case: each byte of the seed is lrand48() >> 23, requiring 20 calls per candidate. The following code runs directly on glibc:

#include <stdio.h>
#include <stdlib.h>

int main(void) {
    srand48(871696354L);             /* 1997-08-16 01:52:34 UTC */
    unsigned char seed[20];
    for (long i = 1; i <= 1842; i++)
        for (int j = 0; j < 20; j++)
            seed[j] = (lrand48() >> 23) & 0xff;
    for (int j = 0; j < 20; j++) printf("%02X", seed[j]);
    printf("\n");
}

$ gcc p256seed.c -o p256seed && ./p256seed
C49D360886E704936A6678E1139D26B7819F7E90

The 1842nd candidate is exactly the officially published P-256 seed, matching byte for byte. Anthropic's article puts it plainly: "This is not a cryptographic break, a new attack, or a weakness in the ECDSA curves."

Why the Backdoor Theory No Longer Holds Up

The genuinely serious version of the backdoor argument came from Bernstein and Lange's 2017 analysis: if the NSA possessed some class of secret weak curves, the unexplained seeds would have given them room to search—by their model, roughly 70 bits of freedom, aimed at a hypothetical 2^61 weak curves.

Now we know the input space is "timestamps from 1997–98." Filippo calculated that even allowing any timestamp in that window and taking the first 16 prime-order candidates for each curve, there are only "barely 30 bits of freedom." His words: "Not enough to deliberately target a hypothetical small class of weak curves, and not enough to embed any form of NOBUS backdoor."

And the seed goes through SHA-1 before becoming b. You can't first pick the curve you want and then reverse-engineer a timestamp—you can only roll the dice, at most about a billion times.

NOBUS stands for "Nobody But Us," referring to a weakness that only the designer can exploit and that no other party (including public cryptanalysts) can reproduce. In cryptographic discussion, it usually refers to secret structure embedded in an algorithm: the designer holds some trapdoor information that lets them break instances faster than anyone else, while outside researchers, even if they suspect a weakness exists, cannot find a way to exploit it in reasonable time. The key difficulty of a NOBUS backdoor is that it must evade worldwide public analysis while still being "worth using" to the designer. Filippo Valsorda points out that if the seeds came from timestamps in 1997–98, the input space has only about 30 bits of freedom, so the designer could not deliberately target a class of weak curves and thus could not construct such a "only we can use it" weakness.

LLL lattice basis reduction (Lenstra–Lenstra–Lovász) is an algorithm for finding short vectors in a lattice in polynomial time, widely used in cryptanalysis—especially for state recovery of pseudorandom number generators based on linear congruential methods or truncated output. When lrand48's output is heavily truncated (for example, keeping only the high bits of lrand48() >> 23), the number of hidden bits grows and direct brute-force enumeration becomes infeasible; at that point, the fact that "the observed output bits satisfy a linear congruence relation" can be turned into a short-vector problem on a lattice, and LLL recovers the full 48-bit internal state. Once the state is known, it can be rewound to the position set by srand48 from the timestamp. This technique is the key mathematical tool that let this seed tracing cover all curve variants.

What Remains Unexplained

It's not a hundred percent closed, and the commenters are right.

• P-256's generation skipped candidate 876, which would also have yielded a prime-order curve of suitable size. Filippo counted that "the number of valid seeds is about twice the published number." He identified one extra rejection rule (n's bit length cannot exceed p), but the second rule "still eludes us."
• The base points of P-224, P-256, P-384, and P-521 remain unexplained. P-192's base point is explained, as are some other ANSI X9.62 curves (FreeLIP's RNG, with seeds such as 20000 and 20420).
• B-163's seed is likewise unexplained; one Hacker News commenter suspects a typo in some digit.

On Hacker News, fidotron's objection is that this finding "doesn't explain their selection process." Fair enough. On Lobsters, one reply I agreed with was that speculation about a 2^30 backdoor is something "an individual could test in reasonable time without telling anyone," even back in 1997. Hiding a "only we can use it" weakness in a space anyone can enumerate doesn't make sense. And for a hidden weakness to be worth exploiting, it would have to exist in curves genuinely findable among a billion random attempts. Twenty-five years of cryptanalysis has found no such class.

Incidentally, base points don't matter for this: in a prime-order group, any generator is equivalent to any other.

So Why Do People Still Choose Ed25519?

My view is that the case for Curve25519 has always been primarily about engineering, and the backdoor rumors just made that case sound scarier.

Ed25519 is designed so that "the easy implementation" is also "the safe implementation." Signatures are deterministic, so a corrupted nonce won't leak your private key the way a constant ECDSA nonce did on the Sony PS3. X25519 has no invalid-curve attacks to defend against. Keys are only 32 bytes, and there aren't many parameters to get wrong.

But P-256 has caught up. Deterministic ECDSA is in RFC 6979, and P-256 now has complete addition formulas and formally verified field arithmetic. Filippo, who maintained Go's crypto libraries for years, now writes that he "would personally now recommend" NIST ECC over Curve25519/Ed25519/X25519. He follows that immediately with: "Just in time for them to be replaced by post-quantum signatures." On Lobsters he gave his reasoning: P-256 is everywhere, including in hardware; he'd rather concentrate effort on one well-implemented curve than spread it across two; and new signatures have a better option anyway in ML-DSA-44.

My position is that in 2026, the decisive questions are what your hardware supports and what your libraries make hard to get wrong. A rumor from 2013 shouldn't factor into the decision.

RFC 6979 defines a method for deterministic nonce generation in ECDSA (and DSA): it uses the private key and message hash as input and derives the random number k needed for each signature via HMAC, rather than relying on a system random source. With traditional ECDSA, if a nonce repeats or is predictable, the private key is immediately exposed—the Sony PS3 signing failure was caused by a constant nonce. The deterministic scheme eliminates the trust assumption in the random number generator, so signing the same message always produces the same result. The P-256 ecosystem widely supports RFC 6979, which is one of the important reasons Filippo Valsorda considers P-256 to have caught up with Ed25519 on engineering safety.

What to Use Today: SSH, JWT, TLS, WebAuthn

Scenario	Choice	Rationale
SSH user keys	ed25519, or ecdsa-sk/ed25519-sk on hardware keys	Ed25519 is OpenSSH's default for good reason. For FIDO keys, use whatever algorithm the token supports
JWT signing	ES256 for broad compatibility, EdDSA if both ends support it	ES256 works everywhere; JWT library support for EdDSA is still uneven
TLS certificates	ECDSA P-256	CAs and clients are optimized for it. Key exchange is negotiated separately (X25519, increasingly hybrid with ML-KEM)
WebAuthn / passkeys	Accept both -7 (ES256) and -8 (EdDSA)	Most authenticators generate ES256; don't reject either
TPM / HSM / Secure Enclave	P-256	Often the only curve the hardware supports

For SSH:

**ML-DSA** (Module-Lattice-Based Digital Signature Algorithm) is the digital signature algorithm selected in the U.S. NIST post-quantum cryptography standardization project, formerly CRYSTALS-Dilithium, published as FIPS 204. It is based on hard problems on module lattices and aims to resist quantum computers' Shor's algorithm attacks on RSA/ECC. **ML-KEM** (formerly CRYSTALS-Kyber, FIPS 203) is a key encapsulation mechanism, used to replace (EC)DH key exchange in TLS/SSH. The current practice trend is "hybrid mode": layering ML-KEM on top of existing X25519 or P-256 key exchange to combine classical and post-quantum security; on the signature side, ML-DSA is being introduced gradually. The article's advice to prioritize migration effort on hybrid post-quantum key exchange refers to exactly this approach.
# Software keys
ssh-keygen -t ed25519 -C "you@laptop"

# Hardware support (FIDO2 tokens); use ecdsa-sk if the token doesn't support Ed25519
ssh-keygen -t ed25519-sk -O resident -C "you@yubikey"

P-256 keys in production can stay as they are. Nothing about your keys changed this month; the only thing that changed is that the main argument for treating them as suspicious has disappeared. Spend your migration effort on post-quantum planning: start with hybrid key exchange for TLS and SSH, then introduce ML-DSA signatures as your stack allows.

Checklist:

1. Don't rotate P-256 keys because of this finding.
2. Use Ed25519 for new SSH keys; use P-256 when hardware or compatibility requires it.
3. Audit all hand-rolled ECDSA nonce generation. If it isn't RFC 6979 or a hedged scheme, fix that before worrying about seeds.
4. Accept both ES256 and EdDSA in WebAuthn.
5. Invest time in hybrid post-quantum key exchange.

Did the Seeds Influence Your Choice?

Many of us, myself included, chose Ed25519 over P-256 at some point and cited the NSA's unexplained seeds as the reason. What about you? Now that the seeds have turned out to be nothing more than a 1997 timestamp, does that change anything—or were you always really in it for the API? If you think the skipped candidates still leave room for a backdoor, feel free to explain in the comments how you'd exploit those 30 bits.

One-line Summary

Claude traced the NIST curve seeds to 1997 timestamps, collapsing the backdoor theory, but choice still hinges on engineering and post-quantum.

Paragraph Summary

Anthropic's Claude research model traced the "magic seeds" of curves like NIST P-256 to Unix timestamps from 1997–98: the seeds were generated directly by srand48/lrand48 rather than hashed English sentences, and 11 lines of C code reproduce P-256's 1842nd-iteration output. Filippo Valsorda verified it in Go and donated the $36,864 bounty to ISRG. With only about 30 bits of freedom in the input space and SHA-1 standing between seed and curve, the serious backdoor hypothesis is hard to sustain. Still unexplained: P-256 skipping candidate 876, the base points, and the B-163 seed. The author argues choices should rest on hardware support and library ergonomics—Ed25519 for SSH, P-256 for TLS certificates—with post-quantum migration prioritized.