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

Question

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.

Answer 1

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.

Answer 2

You are using the eliptic curve function of openssl and providing a serialized bytestring as an input. DER (Distinguished Encoding Rules) is a restricted variant of BER for producing unequivocal transfer syntax for data structures described by ASN.1.

The ASN1 structure for a privkey looks like this:

# ASN.1 STRUCTURE FOR PRIVATE KEY:
#   30  <-- declares the start of an ASN.1 sequence
#   74  <-- length of following sequence 
#   02  <-- declares the start of an integer
#   01  <-- length of integer in bytes (1 byte)
#   01  <-- value of integer (1)
#   04  <-- declares the start of an "octet string"
#   20  <-- length of string to follow (32 bytes)
#           3cd0560f5b27591916c643 ... a738d2e912990dcc573715d2c 
#           \--------------------------------------------------/
#            this is the private key 
#   a0   <-- declares the start of context-specific tag 0
#   07   <-- length of context-specific tag 
#   06   <-- declares the start of an object ID
#   05   <-- length of object ID to follow 
#   2b 81 04 00 0a <-- the object ID of the curve secp256k1

See also: Signing transaction with SSL - private key to PEM