I never trusted ECC, until now
Recently (october 2026), Anthropic proudly announced they found the seed origins for the SECG curves. This fundamentally changed my trust in ECC, especially in some curves. Let me explain.
About thirty years ago, public key cryptography was brand new. The only algorithm that was used was RSA. Then, in 2000, the Standards for Efficient Cryptography Group (SECG), founded by Certicom, published a set of recommended curves, called SEC 2. (The original publication was 2000, but they have been updated since.)
There’s a problem I had with these curves. Especially with the curve called Secp256r1 (also known as NIST P-256), a curve that is being used in many places all over the internet, and specifically by the financial industry.
Some background
It is useful to have standard elliptic curves. It is easier to all use the same values, so you don’t have to agree on a set of long numbers before you can do anything. Also, it isn’t easy to make an elliptic curve: a good curve needs to fulfill a list of security requirements. Curves that did not satisfy the security requirements would be easy to “break”, in the sense that there could be a backdoor that, for example, would allow to to sign a document in someone else’s name, or read encrypted messages that were based on that curve. And, especially around 2000, it wasn’t so easy to check all the requirements.
Why I don’t trust the NSA
The reason that I had to mistrust this curve is that in that time, part of the NSA’s strategy was to influence cryptography standards to their own advantage. An early example was the changes they made to DES (to the S-boxes, to be precise), without any explanation. Later it became clear these choices were influenced by strength against “differential cryptanalysis”, a technique that only became know two decades later. This convinced me that NSA had some pretty good cryptographers at the time (and, undoubtedly, today).
The most notorious example of NSA’s strategy is the random generator called Dual_EC_DRBG. This random number generator was complicated, slow and biased (that’s cryptography speak for: terrible). NSA managed to get this random number generator standardized by ISO. They even managed it to become the standard random number generators in several devices.
The NSA got the idea for this “evil random number generator” from a publication by Adam Young and Moti Yung: “Kleptography: Using Cryptography against Cryptography” at Eurocrypt ’97. The lecture (I was in the room!) was given in a tongue-in-cheek way, but to everyone’s surprise NSA implemented it almost to the letter in the Dual_EC_DRBG.
There’s no proof that NSA could spy on these random number generators, but why would they go through all that trouble if they couldn’t?
How to make a breakable curve
A few of these Certicom standard curves, including the Secp256r1, have become NIST standard, which is later recommended by NSA to use for public key encryption. For example, EMV uses it for encrypting your PIN.
Anyway, at the time Certicom published their standard curve, there weren’t many cryptographers around that understood elliptic curves, so it is not unreasonable to assume NSA had the opportunity to influence them if they wanted. It is also not unreasonable that the NSA knew of some secret backdoor that would allow them to break certain curves. So they had a motive to standardize a curve that would be just right for them.
The problem I have with this curve can be found in NIST SP800–186. Here’s an excerpt from pages 10 and 11:
3.2.1.3. P-256 The elliptic curve P-256 is a Weierstrass curve Wa,b defined over the prime field GF(p) that has order h⋅n, where h = 1, and n is a prime number. […]
a: -3
b: 1 115792089210356248762697446949407573529\ 996955224135760342422259061068512044369[…]
Seed: 0xc49d3608 86e70493 6a6678e1 139d26b7 819f7e90 […]
The definition of this curve consists of a long list of apparently random numbers (hidden by the ellipis). All of these numbers are derived from the “seed”. The algorithm that produces the curve from the seed is known, but the value of the seed isn’t specified.
Get Jurjen Bos’s stories in your inbox
Join Medium for free to get updates from this writer.
If NSA had chosen a curve with a builtin weakness, it would need to choose a special value of the seed. Since the document doesn’t specify where the seed comes from, it looks like the value is chosen in a particular way (by the NSA?).
Of course, the people from SECG were asked where those seed values came from, but nobody in that group could remember. I found this pretty suspect, and this is why I didn’t trust the SECG curves. I have always recommended the Brainpool curves, but they are not as widely supported.
Why I don’t think NSA made a special curve
Until a few days ago. Now we know that this was the recipe they used to generate the seed values:
- Take the current date (encoded as a UNIX timestamp)
- Feed that into a standard random number generator
- Let the generator spit out 20 bytes (the size of a SHA-1 block)
- Construct a curve from that seed
- Check all the required security properties. If something’s wrong, generate new random numbers and try again.
And since both the random number generator they used and the exact timestamp are now known, we can repeat the process for ourselves to see that they didn’t put in any special values. That makes secret values almost impossible to conceal.
There’s only one problem left: if you repeat the recipe they used to make the SECG curves, you’ll see that values have been skipped. Not many, only a handful; click the link of the recipe to see for yourself. I don’t know why these values are skipped; but since it is only a small number, there isn’t much room for concern. That’s is good enough for me.
Today, if someone needs a random number for a cryptosystem, they use a Nothing-up-my-sleeve number. This allows the maker to show that they didn’t put any secrets inside their design. (But it is impossible to completely eliminate that risk, as Dan Bernstein and others showed in the funny article “How to manipulate curve standards: a white paper for the black hat”. Their they produce a lot of numbers that all “accidentally” contain the string BADA55 in their hexadecimal representation, to prove a point.
Conclusion
The NSA has many reasons to want to influence cryptographic standards, and they have done so. But apparently they didn’t influence Certicom in standardizing the elliptic curves that are used widely.
If you want to know more about security requirements on elliptic curves, have a look at SafeCurves. You’ll find curves that are more secure than the SECG curves, more efficient and easier to trust, such as X25519. If you want, you can also test your own curve there.
The picture? That picture has something to do with elliptic curves over the real numbers, but it doesn’t help understanding ECC cryptography at all.
