Is NIST P-256 Backdoored? Its Seed Was a 1997 Unix Timestamp

The "magic" seed behind NIST P-256 is C49D3608 86E70493 6A6678E1 139D26B7 819F7E90. For more than 25 years nobody outside the NSA could say where it came from. This week Anthropic's Claude traced it to a Unix timestamp from August 16, 1997, fed into the same rand48 generator you'd find in any 1990s libc. You can reproduce it with 11 lines of C (code below).

Is P-256 backdoored? Not through its seed. That was the last real argument the "NIST curves are compromised, use Curve25519" crowd had, and this month it stopped working. The rest of this post covers how the seeds were generated, the parts nobody has explained yet, and whether your SSH, JWT or TLS setup needs to change.

What actually happened with the NIST curve seeds

P-192, P-224, P-256, P-384 and P-521 were published in FIPS 186-2 in 2000. Each curve's b coefficient comes from running SHA-1 over a 20-byte seed. The NSA supplied those seeds and never explained them. Jerry Solinas, who generated them, reportedly said they were hashes of English sentences, something like "Jerry deserves a raise." He died in 2023 and nobody ever got it to work.

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

On October 15, 2026, a team at Anthropic claimed it. According to their writeup, an employee asked an internal Claude research model to work out how the seeds were generated, and it found the method in under half an hour. The English-sentence story was wrong. What they found:

• The seeds are raw PRNG output from the POSIX srand48/lrand48 family, seeded with the current Unix time. No hashing involved.
• The tell: in four seeds the top bit of every 32-bit word was zero. lrand48 returns only the top 31 bits of its 48-bit state. The remaining 17 hidden bits were brute-forced. For seeds that keep fewer bits per output (lrand48() >> 23), they recovered the state with LLL lattice reduction.
• Stepping the state backward lands on what srand48 sets from a timestamp. The prime-curve timestamps fall between May 1997 and April 1998.
• The program drew 20 bytes at a time, tried each as a seed, and moved on if the curve was invalid. P-256 took 1,842 iterations.

Reproduce the P-256 seed yourself

You can check this yourself. P-256 is one of the truncated cases: each byte of the seed is lrand48() >> 23, 20 calls per candidate. This runs on glibc as-is:

#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

Candidate 1,842 is the published P-256 seed, byte for byte.

Anthropic's post says it plainly: "This is not a cryptographic break, new attack, or weakness in the ECDSA curves."

Why this kills the backdoor theory

The serious version of the backdoor argument came from Bernstein and Lange in 2017: if the NSA knew a secret class of weak curves, unexplained seeds gave them room to search for one, roughly 70 bits of freedom in their model, aimed at a hypothetical class of 2^61 weak curves.

Now we know the input space was "timestamps in 1997–98." Filippo's math: even if you allow any timestamp in that window and the first 16 prime-order candidates for each, you get "barely 30 bits of freedom." His words: "not enough to intentionally target a hypothetical small class of weak curves, not enough to embed any kind of NOBUS backdoor."

And the seed goes through SHA-1 before it becomes b. You can't pick the curve you want and work backward to a timestamp. You can only roll dice, about a billion times at most.

The part that's still unexplained

It isn't 100% closed, and the comment threads are right to say so.

• P-256's run passed over candidate 876, which would also have given a prime-order curve of the right size. Filippo counts "roughly twice as many valid seeds as were published." He identified one extra rejection rule (bit length of n can't exceed that of p). A second rule "still escapes us."
• The base points for P-224, P-256, P-384 and P-521 are still unexplained. P-192's is explained, along with some ANSI X9.62 curves (FreeLIP's RNG with seeds like 20000 and 20420).
• B-163's seed is also unexplained. One HN commenter suspects a mistyped digit.

On HN, fidotron's objection is that the finding "doesn't say anything about their selection." Fair. On Lobsters, the reply I agree with is that a guess about a 2^30 backdoor "can be tested by an individual in a reasonable time without telling anyone," even in 1997. Hiding a "nobody but us" weakness in a space anyone can enumerate makes no sense. And for a hidden weakness to be worth exploiting, it has to apply to curves you can actually find among a billion random tries. Twenty-five years of cryptanalysis haven't turned up a class like that.

Base points, for what it's worth, don't matter for this. In a prime-order group any generator is as good as any other.

So why would anyone still pick Ed25519?

My hot take: the case for Curve25519 was always mostly about engineering, and the backdoor rumor was a scarier way of making it.

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

P-256 has caught up, though. Deterministic ECDSA is in RFC 6979, and there are complete addition formulas and formally verified field arithmetic for it. Filippo, who spent years maintaining Go's crypto libraries, now writes that he "would now personally recommend" NIST ECC "over Curve25519/Ed25519/X25519." And then: "Just in time for them to be retired in favor of post-quantum signatures." On Lobsters he gives his reasons: P-256 is everywhere, including hardware, he'd rather have one well-implemented curve than split effort across two, and for new signatures ML-DSA-44 is the better choice anyway.

Where I land: in 2026 the deciding questions are what your hardware supports and what your library makes hard to mess up. Rumors from 2013 shouldn't factor in.

What to use today: SSH, JWT, TLS, WebAuthn

| Use case | My pick | Why |
|---|---|---|
| SSH user keys | ed25519, or ecdsa-sk/ed25519-sk on a hardware key | Ed25519 is the OpenSSH default for good reason. For FIDO keys, use whatever your token supports |
| JWT signing | ES256 if you need broad compatibility, EdDSA if both ends support it | ES256 works everywhere. EdDSA support in JWT libraries is still uneven |
| TLS certs | ECDSA P-256 | It's what CAs and clients optimize for. Key exchange is negotiated anyway (X25519, increasingly hybrid with ML-KEM) |
| WebAuthn / passkeys | Accept -7 (ES256) and -8 (EdDSA) | Most authenticators produce ES256. Don't reject either |
| TPM / HSM / Secure Enclave | P-256 | Often the only curve the hardware has |

For SSH:

# software key
ssh-keygen -t ed25519 -C "you@laptop"

# hardware-backed (FIDO2 token); use ecdsa-sk if your token lacks Ed25519
ssh-keygen -t ed25519-sk -O resident -C "you@yubikey"

If you have P-256 keys in production, leave them. Nothing about your keys changed this month, except that the main argument for treating them as suspect went away. Spend the migration energy on post-quantum planning: hybrid key exchange in TLS and SSH first, then ML-DSA signatures as your stack picks them up.

The checklist:

Did the seeds pick your curve?

Plenty of us, me included, picked Ed25519 over P-256 at some point and pointed to the unexplained NSA seeds. Did you? And now that the seeds are a 1997 timestamp, does it change anything, or were you really choosing it for the API all along? If you think the skipped candidates still leave room for a backdoor, tell me in the comments how you'd exploit 30 bits.

Sources

• Anthropic: Claude reveals ECDSA curve origins
• Filippo Valsorda: The NIST Elliptic Curves Seeds Bounty Has Been Claimed
• Filippo Valsorda: original seeds bounty (2023)
• Discussion: Hacker News, Lobsters