Claude Cracked the NIST Curve Mystery: P-256’s Seeds Came From a 1997 Clock, Not a Backdoor, and the Quantum Clock Is Still Ticking (AI Trends, 17 October 2026)

What’s trending in AI on 17 October 2026: For a quarter of a century, cryptographers have asked one awkward question about the encryption that protects most of the web: where did the numbers come from? The elliptic curves NIST standardised in 2000, including P-256, which secures a large share of HTTPS connections, passkeys and code signatures, were built from “seed” values the NSA supplied without explanation. On 16 October, Anthropic published the answer, and said its Claude model found it in under half an hour. The seeds were not a hidden backdoor or the hash of a joke phrase. They came from an ordinary 1990s C library random-number generator, started with the computer’s clock. The same day, a second Anthropic paper showed Claude designing quantum circuits for attacking elliptic-curve cryptography that use around 17 times fewer gates than the best published design. One result makes today’s cryptography look more trustworthy; the other is a reminder that its expiry date is set by quantum computing, not by the NSA. Below: what was found, how an AI cracked it, why it is not a vulnerability, what the quantum result does and does not mean, and a three-horizon plan for your own cryptography.

Key takeaways

A 25-year mystery is closed. The seeds behind NIST’s P-192, P-224, P-256, P-384 and P-521 curves, and four binary curves, came from the C function lrand48 seeded with Unix timestamps from 1997 and 1998.
It is not a break. Anthropic says the finding reveals no attack or weakness, and that a simple, reproducible process makes a deliberate backdoor less plausible. There is nothing to patch or rotate.
The AI did the detective work fast. Claude was not given the long-rumoured “hashed phrase” clue, guessed a 1990s random generator instead, and recovered the method in under 30 minutes.
The real deadline is quantum. A separate Anthropic study had Claude design elliptic-curve quantum circuits with about 17x fewer gates than the smallest prior design. These are paper designs, not a working attack.
Your takeaway is practical. If AI can reverse-engineer a clock-seeded generator from 1997, it can find the same mistake in your code, and it gives you a good reason to start a post-quantum inventory now.

P-256’s seed traces back to a program run at 01:52:34 UTC on 16 August 1997, according to the recovered timestamp.

1. The mystery: numbers nobody could explain

Elliptic-curve cryptography is everywhere. When your browser opens a secure connection, when a phone unlocks with a passkey, when software updates are signed, there is a good chance a NIST curve such as P-256 is doing the maths. Each curve is defined by a handful of constants. For the NIST “prime” curves, one of those constants, called b, was derived from a 160-bit seed. The seeds were published in FIPS 186-2 in 2000, when the US government adopted ECDSA. They had been handed to the ANSI X9.62 standards committee in 1997 by the NSA, with no explanation of how they were chosen.

That gap mattered. The idea behind a seed is “nothing up my sleeve”: if you can show how a constant was produced, nobody can accuse you of hand-picking a weak one. Without the method, people could only trust. That trust took a hit in 2013, when reporting on the Dual_EC_DRBG random-number standard suggested the NSA had promoted a design it could undermine. Cryptographers Neal Koblitz and Alfred Menezes summarised the curve controversy in 2015. The same year, NSA mathematician Jerry Solinas recalled that the seeds might have been hashes of a humorous phrase, but could not remember details. Solinas died in 2023. Filippo Valsorda later organised a public bounty of $36,864 for whoever could recover the seeds. Amateurs and several Anthropic staff chased the phrase theory without success.

It is worth saying up front what was never in doubt. No one had found a mathematical weakness in P-256; the question was about provenance, not a known flaw.

The suspicion grew after 2013; the answer turned out to be mundane.

2. What Claude found

According to Anthropic’s write-up, an employee asked an internal research model to work out how the seeds were generated, deliberately without mentioning the hashed-phrase rumour. Claude took a different route. It reasoned that a 1990s engineer might simply have used a standard pseudo-random number generator, wrote a scanner to test whether pieces of each seed looked like consecutive outputs from common generators of that era, and tried 34 combinations.

The tell was a pattern in the bits. In several seeds, the top bit of each 32-bit chunk was zero, something Anthropic puts at roughly a 1 in 5,810 chance. That fits lrand48, a POSIX C function that keeps a 48-bit internal state but hands back only 31 bits at a time. For four seeds, Claude brute-forced the 17 hidden bits, just 2¹⁷ possibilities. For prime-curve seeds that showed a truncated pattern, it recovered the generator’s internal state with LLL, a lattice-reduction technique familiar to cryptanalysts. From each recovered state the generator reproduces all 160 bits of the published seed, which would not happen by accident.

The answer, then: each seed came from lrand48, started with srand48 and a Unix timestamp. The program produced a series of 20-byte candidates and the published seed is one of them. For P-256, Crypto Briefing reports the timestamp as 871696354, which converts to 01:52:34 UTC on 16 August 1997, and the seed is candidate number 1,842. The ten prime-curve seeds, five NIST and five ANSI example curves, map to timestamps between May 1997 and April 1998. The binary curves’ timestamps read as February 1984, but doubled they land on 17 April 1998, two weeks after the P-224 run, which suggests the program halved the clock value. As a bonus, Claude traced six curves’ base points to the generator in Arjen Lenstra’s FreeLIP library.

The breakthrough was a better hypothesis, then fast, checkable maths.

The table below summarises what is now explained and what is not.

Curve group	Seed explained?	Timestamps	Still open
NIST prime curves: P-192, P-224, P-256, P-384, P-521	Yes, all five	May 1997 to April 1998	Base points for P-224, P-256, P-384 and P-521; why some valid candidates were skipped
ANSI X9.62 example curves: prime192v2, prime192v3, prime239v1, v2, v3	Yes, all five	Same 1997–98 range	Little; base points traced to FreeLIP’s generator
NIST binary curves: B-233, B-283, B-409, B-571	Yes	Read as Feb 1984; doubled, 17 April 1998	Base points
NIST binary curve B-163	No	Unknown	The seed itself

Source: Anthropic, Origins of the NIST ECDSA curve seeds (16 Oct 2026).

3. Why this is good news, not a vulnerability

Anthropic is blunt: “This is not a cryptographic break, new attack, or weakness in the ECDSA curves.” Knowing how a seed was produced does not help anyone forge a signature or decrypt traffic. P-256 is exactly as strong this week as last week.

If anything, confidence goes up. The fear with unexplained constants is that a designer generated millions of candidates and quietly kept one with a secret weakness. A clock-seeded generator producing a numbered list leaves much less room for that. Anthropic is careful not to overclaim: someone could in principle have tried many timestamps, and for P-256 an earlier candidate, number 876, would also have produced a valid curve but was skipped for unknown reasons. Still, given how few candidates were passed over, the researchers say they do not believe weakened curves were picked, and that there is nothing anyone needs to do differently.

There is a quieter irony here. Using lrand48 and a timestamp would be flagged as a bug in modern security code, because both are predictable. In 1997 it was enough for producing public constants that only had to look arbitrary. In your own systems, the same pattern used for session tokens, password-reset links or API keys is a real vulnerability, and section 6 returns to that.

4. Same day, different paper: Claude designs cheaper quantum attacks

The more consequential long-term news for elliptic-curve cryptography came in a separate Anthropic study published on 16 October. Led by Andi Gu of the Anthropic STEM Fellows Program with collaborators at Harvard and QuEra, it gave Claude plain-language specifications for eight quantum computing building blocks, plus an automated checker that verified correctness and scored designs by qubits times gates. Claude then iterated in a closed loop. In every case, its designs beat the best published versions on that cost measure.

One of those building blocks is elliptic-curve point addition, the core step in quantum algorithms that solve the elliptic-curve discrete logarithm problem, which is what a large enough quantum computer would do to break ECDSA and ECDH. One of Claude’s designs uses 12% more qubits but about 17 times fewer gates than the smallest previous design, after a 53-hour run the paper describes as having needed only minimal human input. For a decoder step in Google’s Decoded Quantum Interferometry optimisation algorithm, Claude cut gate counts by about 12 times and reduced a worst-case reserve of 665 qubits to 19.

The caveats are important. These are circuit designs and resource estimates, not a demonstration on hardware. Today’s machines have hundreds to thousands of physical qubits, far from what a cryptographically relevant attack needs, and the cost measure is a proxy rather than real runtime. But the direction is the point: as the paper notes, estimates for a well-known chemistry problem fell about 150,000-fold between 2017 and today through better algorithms alone. Every cheaper circuit pulls the day a quantum computer can break today’s public-key cryptography a little closer. That ties into the broader trend we covered in AI-generated maths and the verification gap: the bottleneck is shifting from generating ideas to checking them.

Better algorithms, not just bigger machines, are what shorten the road to a quantum threat.

5. What the two papers say together

Read side by side, the papers make a tidy argument. The classical story about P-256 has ended well: the curve’s origins look innocent and its maths is sound. The remaining threat to it is not a hidden trapdoor but physics plus algorithms, and AI is now speeding up the algorithm side. Meanwhile, NIST already has replacements. It finalised three post-quantum standards in August 2024: ML-KEM (FIPS 203) for key exchange, and ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) for signatures. Its draft transition plan, NIST IR 8547, proposes deprecating quantum-vulnerable algorithms at the 112-bit security level after 2030 and disallowing RSA, ECDSA and ECDH in NIST-conformant systems after 2035.

There is also a lesson about AI as an investigator. Several humans failed on this puzzle because they followed the wrong lead. The model succeeded because it tried a plainer hypothesis and could test it fast. That is the same capability we have seen in vulnerability research, from Anthropic’s free AI scans for open-source code to the flood of AI-found bugs that is straining bug bounty programmes. It cuts both ways: attackers with similar models can hunt for predictable randomness, weak key handling and legacy cryptography in your systems just as quickly.

The 2030 and 2035 dates come from a NIST draft and may change, but the direction is set.

6. What this means for businesses

Do not rotate keys because of this news. There is no technical case for an emergency move off P-256, whatever vendors may pitch. Spend that energy on the post-quantum plan instead.

Do audit your own randomness. The 1997 method, a non-cryptographic generator seeded with the time, is a classic coding mistake. Tokens built with rand(), Math.random(), Python’s random module or a timestamp can be predictable. AI coding tools sometimes write this pattern, and AI-assisted attackers can spot it. Use the operating system’s secure generator, for example Python’s secrets module or the Web Crypto API.

Do treat post-quantum work as a project, not a someday. The risk that worries security teams is “harvest now, decrypt later”: encrypted traffic or files captured today and kept until a quantum computer can open them. If your data must stay confidential for ten years or more, such as health records, contracts, intellectual property or long-lived credentials, the clock already matters. As we noted in our earlier look at quantum computing and cryptography, the hard part is not the new algorithms but finding every place the old ones hide.

Do ask vendors the question. Most of your cryptography lives in products you buy: browsers, VPNs, cloud key management, payment terminals, identity providers. The same vendor-risk discipline we recommended after Bank of America’s AI patch bill applies: ask for a post-quantum roadmap in writing, with dates.

7. A three-horizon cryptography plan

Split the work by when it pays off, and tick items as you go.

Horizon 1: this week

☐ Brief leadership in one line: “The NIST curve news is reassuring; no action on P-256 is needed.”
☐ Search your code for weak randomness: grep for rand(, Math.random, random. and time-based seeds anywhere tokens, IDs, reset links or keys are made.
☐ Add a rule to code review and AI coding assistants: security values must come from a cryptographically secure generator.

Horizon 2: this quarter

☐ Start a cryptographic inventory: list where you use RSA, ECDSA and ECDH, including TLS certificates, VPNs, SSH keys, code signing, document signing and databases.
☐ Rank data by shelf life: flag anything that must stay secret beyond 2035; that is your harvest-now-decrypt-later exposure.
☐ Send vendors three questions: Do you support ML-KEM or hybrid key exchange today? When will you support ML-DSA signatures? Can algorithms be swapped by configuration?
☐ Check your browser and CDN settings: many already offer hybrid post-quantum key exchange for TLS; confirm whether yours is on.

Horizon 3: before 2030

☐ Build crypto-agility: make algorithm choices configurable so future swaps are a setting, not a rewrite.
☐ Migrate long-lived secrets first: key exchange protecting long-shelf-life data, then signatures on long-lived artefacts such as firmware and contracts.
☐ Write it into contracts: require post-quantum support dates from new suppliers, in line with NIST’s proposed 2030 and 2035 milestones.
☐ Re-check yearly: AI-designed circuits mean quantum cost estimates can fall faster than expected; review your timeline every year.

For organisations already stretched by AI-driven attack volumes, our 30-day plan from Microsoft’s Digital Defense Report pairs well with horizon 1, and our guide to patching faster as AI hacking spreads covers the process side.

8. The bottom line

A question that hung over internet security for 25 years now has an ordinary answer: someone at the NSA ran a standard random-number generator off the system clock in 1997 and 1998. It took an AI model half an hour to see what people had missed, and the answer makes P-256 look cleaner, not weaker. The same week, the same company showed AI making quantum attacks on elliptic curves cheaper on paper. The message for businesses is consistent: trust today’s curves, fix predictable randomness in your own code, and start the post-quantum inventory you will need either way. As with AI-driven scientific discovery more broadly, the advantage goes to those who can check results quickly and act on them.

Frequently asked questions

Did Claude break P-256 or ECDSA encryption?

No. Claude worked out how the curve seeds were generated, which is a question of history, not of security. Anthropic says the finding is not a cryptographic break, new attack or weakness, and that no one needs to change anything as a result.

Where did the NIST P-256 seed come from?

According to Anthropic, it came from the C library generator lrand48, seeded with a Unix timestamp that Crypto Briefing reports as 16 August 1997, 01:52:34 UTC. The published seed is candidate number 1,842 from that run.

Does this prove there was no NSA backdoor in the NIST curves?

It does not prove it absolutely, but it makes a backdoor much less plausible. A reproducible, clock-seeded process leaves little room to hunt for weak curves. Some details, such as why certain candidates were skipped and how most base points were chosen, remain unexplained.

How long did it take Claude to solve the mystery?

Anthropic says an internal research model found the seeds’ origin in under half an hour, without being given the long-rumoured hashed-phrase clue. Its results are checkable: Anthropic published reproduction code that regenerates the seeds.

Do Claude’s quantum circuit designs put elliptic-curve cryptography at risk now?

Not now. The designs cut the estimated cost of a key quantum attack step, with one using about 17 times fewer gates than the previous smallest design, but they are paper designs. Today’s quantum computers are far too small. They do strengthen the case for planning a post-quantum migration.

What should my business do after this news?

Keep using P-256. Check your code for predictable random numbers used in tokens or keys. Start a cryptographic inventory, identify data that must stay secret beyond 2035, and ask vendors for post-quantum support dates using NIST’s ML-KEM and ML-DSA standards.

Delana Technologies