Claude traced the mysterious seeds behind the NIST curves in under 30 minutes, but humans were the ones who confirmed it was real

Hi, Haru here. The story that surprised me most this week is about an AI solving a cryptography puzzle that had gone untouched for nearly 30 years. The most interesting part is that once it was solved, a human did the work of checking whether the answer was actually right. As usual, I didn't run anything myself. I read through the primary-source posts, the blog write-ups and the Hacker News discussion and put this together.

The "NIST curve seeds" were a mystery for nearly 30 years. Claude traced their origin in under 30 minutes

First, the background. A lot of the cryptography that protects internet traffic is built on elliptic curves, a particular kind of mathematical curve that serves as the foundation for the encryption. Among the most widely used are P-192, P-224, P-256, P-384 and P-521, which were standardized by NIST, the US standards agency. Each of these curves was generated from a "seed," the starting number fed into the generation process. Nobody had been able to explain where those seeds came from.

Why does that matter? Without a known origin for the seeds, it's impossible to rule out a backdoor: the suspicion that the curves' creators chose seeds that would produce weak curves only they could break. The prevailing theory had been that the seeds were made by hashing English sentences that someone had written.

According to Anthropic's research post, a 10-person research team that included John Wood, Henry de Valence, Nicholas Carlini and Steve Weis handed the investigation to an internal research version of Claude. Claude's hypothesis was that the seeds weren't English text at all. Instead, it proposed, they were output from lrand48/drand48, pseudorandom number generators found in 1990s C libraries, seeded with Unix timestamps. Working from the published seeds, it then recovered the generators' internal state by treating the problem as a lattice problem.

The result: the origins of the seeds for five curves were identified in under 30 minutes. The timestamps embedded in the seeds fall between May 1997 and April 1998. For P-256, the 1,842nd candidate was the one adopted, even though the 876th candidate would also have produced a curve with prime order, one of the conditions a curve needs to be usable for cryptography. The team also found that the base points (the starting points on the curve used for calculations) of six curves came from the random number generator in a math library called FreeLIP, with initial values ranging from 20,000 to 20,517. The "English sentence" theory turned out to be wrong.

A human said "it's real." Valsorda rebuilt it in Go to check

This is my favorite part. When an AI says "solved," you can't just take its word for it, and that's especially true in cryptography. Enter cryptographer Filippo Valsorda. In 2023, he and other cryptographers offered a bounty to anyone who could find the text behind the NIST curves.

On the same day as Anthropic's announcement, Valsorda wrote on his blog that the bounty had been claimed. He didn't stop at signing off on it. He reimplemented the algorithm in Go to check that the seeds could be reproduced as claimed, and published that code on GitHub. What matters is that someone outside the research team reproduced the result independently.

The bounty was $12,288. The team donated it to ISRG, the organization that runs the free certificate authority Let's Encrypt, and the donation was tripled to $36,864. The puzzle was settled roughly three years after the bounty was posted. There's a bit of irony here: the bounty asked for the original English text, and the answer turned out not to be English text at all.

So what about the backdoor suspicion? By Valsorda's estimate, the NSA had at most about 30 bits of freedom to pick a seed that suited it. That's 2 to the 30th power, meaning it could have chosen from roughly a billion options. The backdoor technique described by researchers Bernstein and Lange, however, requires about 70 bits. 2 to the 70th power is about 1.2×10^21, or roughly a billion times a trillion. The available room to choose falls far short, so that technique could not have been used. I thought narrowing down the suspicion with hard numbers was a very honest way to approach the question.

The Hacker News thread collected 774 points and reportedly became the top AI-related story on October 16th. In the thread, cryptography experts including Valsorda himself and tptacek said the P-curve backdoor theory was now essentially dead.

Not everything is solved, and doubts remain

I want to be clear about this part. First, Anthropic's post does not disclose the model version used, the number of attempts, the token count (a rough measure of how much the AI read and wrote) or the cost. The "under 30 minutes" figure comes from the company's own report, and outsiders can't test it under the same conditions. What Valsorda verified was that the answer is correct, not that an AI produced it in 30 minutes. Those are two separate claims.

The puzzle also isn't fully solved. The seed for a curve called B-163 is still unknown. How the base points for P-224, P-256, P-384, P-521 and the binary curves (curves built over a different kind of number field) were generated is also unknown. On top of that, about half of the valid seeds were discarded for reasons nobody understands. Valsorda himself writes that one of the criteria used to reject them is "still unknown."

Skepticism on HN was strong as well. User fidotron wrote that even knowing the seeds were random, it doesn't dispel the suspicion that the curves to adopt were picked by undisclosed criteria, and pointed to the precedent of the S-boxes (internal substitution tables) in DES, an older standard cipher. User schiffern wrote that if you generate a large number of candidate seeds in advance, you retain deniability. User ezoe was doubtful too: it's hard to believe NIST would casually use a low-quality random number generator for such an important standard, they wrote, and suggested Claude may simply have hit the jackpot by chance.

My take: with an upper bound of 30 bits, a backdoor using known techniques now looks quite unlikely. But nobody has fully answered "Why the 1,842nd candidate?" or "What was the criterion for discarding seeds?" The AI proposed a hypothesis, humans reproduced it, and humans put into words the gaps that remain. Seeing that division of labor so clearly was the biggest takeaway for me.

Another example from the same week: Claude read USB traffic logs and built a driver Linux didn't have

There was another story this week with the same pattern. Christian Schaller, known for his work on GNOME and Fedora, wrote about it on his blog. His target was the Plustek OpticFilm 8200i, a film scanner that had never worked on Linux.

His method is interesting. He ran Windows in a KVM virtual machine, installed the manufacturer's official Windows driver, and connected the physical scanner to it. He recorded the USB traffic that passed between them and had Claude read the logs. From there he built a SANE backend, the model-specific component of Linux's common scanner framework, and within a few hours he had the first-ever scan on Linux. He also fixed the MIPI camera on a ThinkPad X1 Carbon (MIPI being an interface commonly used for laptops' built-in cameras), raising its measured brightness from 31.1 to 90.9. On HN, there were also reportedly claims that analyzing products from three competitors took three hours, and Ursa Major's product line took 20 minutes.

Schaller writes that "deciding what to build and verifying it on real hardware is the human's job." That's exactly the same as the NIST case. Claude is good at reading huge volumes of traffic logs and producing hypotheses and code. But it's the human sitting in front of the actual hardware who checks whether an image really comes out of the scanner.

There's pushback, of course. One HN commenter argued that "the moat (a manufacturer's defense against being copied) hasn't disappeared. It was only ever half-dug. The real protection is firmware encryption." Others worried that small manufacturers' products could be copied wholesale. It's good news for users, but a bit scary for the people who make the hardware.

The takeaway: AI finds the answer, humans decide if it's real

What the two stories have in common is that an AI quickly worked through a long-standing mystery or a tedious analysis, and a human made the final call on whether the result was genuine. With the NIST seeds, Claude found the likely answer and Valsorda confirmed it by rebuilding it in Go. With the scanner, Claude wrote the driver and Schaller confirmed it on real hardware. "AI for Science" tends to get discussed in grand terms, but on the ground it looks like this kind of steady division of labor.

Put the other way around, an "AI solved it" claim that nobody has checked deserves only about half your trust for now. That includes the fact that Anthropic's "under 30 minutes" can't be reproduced from outside. As readers, we should get in the habit of asking who verified a result, and how.