Cryptocurrency
private-key public-key ecdsa secp256k1 openssl
Updated Thu, 28 Jul 2022 10:48:23 GMT

Openssl magic values? Secp256k1 and ECDSA similarities? What makes secp256k1 special?


Part 1:

Running this command seems to be a reliable way to produce a pubkey from a valid private key that for Bitcoin. Is this a correct assumption?

openssl ec -inform DER -text -noout -in <(cat <(echo -n "302e0201010420") <(echo -n "PRIVATE_KEY_HEX_STRING") <(echo -n "a00706052b8104000a") | xxd -r -p) 2>/dev/null | tail -6 | head -5 | sed 's/[ :]//g' | tr -d '\n' && echo

These magic values:

302e0201010420

a00706052b8104000a

Openssl seems to use these values for DER encoding rules, and it doesn't seem to have anything to do with secp256k1 or Bitcoin specifically. Is this a correct assumption?

Part 2:

It doesn't seem like the y^2 = x^3 + 7 formula / secp256k1 is used anywhere explicitly when deriving the pubkey from the private key in the above openssl command.

Are all public keys for Elliptical Cryptography practically derived the same way.. meaning there is a ton of overlap between these ECDSA curves?

Seems like the only thing specific to Bitcoin compared to another ECDSA curve is the maximum upper limit for a private key of FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141.. is this a correct assumption? How is it that I'm able to produce the private and public keys without having to use the formula? It's like Satoshi lied to us and this formula has no meaning!

A bit confused here would love if someone could clear this up for me and the 2 other people who can't sleep at night because of this.

Solution

These magic values:

302e0201010420

a00706052b8104000a

Openssl seems to use these values for DER encoding rules, and it doesn't seem to have anything to do with secp256k1 or Bitcoin specifically. Is this a correct assumption?

They have nothing to do with Bitcoin, but I believe that those bytes contain a reference to secp256k1 (probably through its OID 1.3.132.0.10).

Specifically, I think the 8104000a part encodes the numbers 132, 0, 10.

Are all public keys for Elliptical Cryptography practically derived the same way.. meaning there is a ton of overlap between these ECDSA curves?

No, there are lots of relevant parameters that go into public key computation:

  • The field size for its coordinates (2^256 - 2^32 - 977 for secp256k1)
  • The type of curve (Weierstrass, Edwards, twisted Edwards, ...)
  • The coefficients of the curve equation (for short Weierstrass curves the equation is y^2 = x^3 + a*b + b; for secp256k1 a=0 and b=7).
  • The generator point (the point corresponding to private key 1, which has to be chosen by convention)
  • The order of the generator (which is equal to the number of points on the curve for secp256k1, but can also be a small factor less)

The last item, the order of the generator, defines how many valid private keys there are. It is implied by all other parameters, but computing it is a nontrivial computation, so it is usually precomputed.


References