# What is the reasoning behind the choice of 2^256-2^32-977 for the prime on the secp256k1 curve?

In Bitcoin's elliptic curve (secp256k1),

the prime

``````p = 2^256 - 2^32 - 2^9 -2^8 - 2^7 - 2^6 - 2^4 - 1
``````

the generator point

``````Gx =
0x79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798

Gy =
``````

and the order of the group generated by G

``````n = 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141
``````

are predefined.

What is the reasoning behind this? Why are these values more secure or efficient than any other ones?

Secp256k1 was designed to be a 256-bit size elliptic curve without cofactor and admitting an efficient endomorphism for optimization purposes. The choices of the relevant parameters are derived from these criteria.

P is selected allow a more efficient implementation on general purpose computers. See Solinas' paper on Generalized Mersenne Numbers. We don't know the exact search procedure Certicom used to select P, but it is the first prime you get if you search 2^256 - 2^32 - (1024 - x).

We know, however, that this may not be the exact procedure they would have needed because the presence of the endomorpism requires a cube root of unity. See this answer on crypto stack exchange. But they could have searched this way and got lucky.

The generator could be just any point on the curve and it is trivial to prove that the choice of generator is irrelevant to the security of any scheme that doesn't involve coercing values into curvepoints, and pretty narrowly relevant otherwise.

We haven't been able to uncover how G was selected, but I did discover that it a value that was likely obtained by doubling a point with a very small (166 bit) x coordinate. The same value was used in several other ECC standards. (I wouldn't be surprised if it was the hash of someone's name of something silly like that, but it seems that this trivia might have followed Scott Vanstone to his grave).

Since the curve order is prime the order of G isn't a parameter so much as the result of the selection of the field and the curve equation. 'b' in the curve equation being 7 was almost certainly just because it was the first value that gives a secure curve. 'a' being 0 is a necessary condition for the endomorphism.

You might also find this old thread on bitcointalk interesting.

• What do you mean by "admitting an efficient endomorphism"? I know the meaning of the word endomorphism. But where and how is it being used? I could open a separate question if that was necessary. Mar 18, 2019 at 6:51
• @Rene Pickhardt: the optimization to use the efficiently-computable endormorphism to speed up elliptic curve computations is called the Gallant-Lambert-Vanstone method, but the details probably warrant their own question Mar 19, 2019 at 7:42

That is probably for others here to answer but I will give it a shot.

We are looking for an elliptic curve which has a cyclic subgroup with a high order (but not higher than `2^256` as we want to work with 32byte private keys and the private keys are the orders of the elements with respect to the generator point) this particular elliptic curve over that prime field seems to fulfill these properties.

The order of the subgroup basically defines the difficulty for the discret logarithm. If the subgroup for example was of an order so small that one could store all group ements on a computer one could just compute it and break any public key coming from that group.

As for the generator point. I believe this is an arbitrary choice. Since the group is cyclic (and afaik of prime order) any other element (unless the neutral one) could have served as the generator. However we need to agree on a fixed generator point for ecdsa to have the same results every time we run the algorithms. Therefor one element was chosen.

I am not sure if there is more theory as to why this particular configuration seems preferable.

• Tiny nit: an elliptic curve with a cyclic prime subgroup. Most elliptic curves are cyclic on their own, but most are of composite order. Mar 18, 2019 at 4:49

A very short layman's answer (not mathematically correct) is the normalization of the the private key needs to be a very large prime number less than 2^256-1 to ensure the cyclic modulo operation does not easily repeat predictably to compute the associated public key. If someone was able to discover a larger prime number than p = 2^256 - 2^32 - 2^9 -2^8 - 2^7 - 2^6 - 2^4 - 1 and less than 2^256-1, such a number could have been used for cyclic normalization. Additionally, a good pseudo random number generator heuristic is to initially seed them with very large prime numbers.