Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PrivateKey parameters and RFC 5915 #493

Closed
richardschneider opened this issue Dec 27, 2017 · 3 comments
Closed

PrivateKey parameters and RFC 5915 #493

richardschneider opened this issue Dec 27, 2017 · 3 comments

Comments

@richardschneider
Copy link

The PrivateKey.parameters produced by ec_privkey_export_der currently contain the curve parameters. According to RFC 5915 section 3, it should contain the curve name (OID).

Is it possible to change this method, or add a ec_privkey.export_RFC5480

parameters specifies the elliptic curve domain parameters
associated to the private key. The type ECParameters is discussed
in [RFC5480]. As specified in [RFC5480], only the namedCurve
CHOICE is permitted. namedCurve is an object identifier that
fully identifies the required values for a particular set of
elliptic curve domain parameters. Though the ASN.1 indicates that
the parameters field is OPTIONAL, implementations that conform to
this document MUST always include the parameters field.

Expected

SEQUENCE(4 elem)
  INTEGER 1
  OCTET STRING(32 byte) FD1DFE200F8133418031877BF9B54A816D9066011C426ACD46E1B8C16863FEA9
  [0](1 elem)
     OBJECT IDENTIFIER 1.3.132.0.10 secp256k1 (SECG (Certicom) named elliptic curve)
  [1](1 elem)
     BIT STRING(264 bit) 0000001110001111011111001101110011101011001100011011010111110010001101…

Actual

SEQUENCE(4 elem)
  INTEGER 1
  OCTET STRING(32 byte) FD1DFE200F8133418031877BF9B54A816D9066011C426ACD46E1B8C16863FEA9
  [0](1 elem)
    SEQUENCE(6 elem)
      INTEGER 1
      SEQUENCE(2 elem)
        OBJECT IDENTIFIER 1.2.840.10045.1.1 prime-field (ANSI X9.62 field type)
        INTEGER(256 bit) 1157920892373161954235709850086879078532699846656405640394575840079088…
     SEQUENCE(2 elem) 
       OCTET STRING(1 byte) 00
       OCTET STRING(1 byte) 07
     OCTET STRING(33 byte) 0279BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798
     INTEGER(256 bit) 1157920892373161954235709850086879078528375642790749043826051631415181…
     INTEGER 1
  [1](1 elem)
     BIT STRING(264 bit) 0000001110001111011111001101110011101011001100011011010111110010001101…

This was first raised in cryptocoinjs/secp256k1-node#123

@sipa
Copy link
Contributor

sipa commented Dec 27, 2017

Pull requests welcome.

That function is only provided for backward compatibility with systems that need to interact with OpenSSL, though, and the implementation matches what OpenSSL does (as far as I know).

@richardschneider
Copy link
Author

Its not just OpenSSL. I need to store the key in PKCS #8 for exchange with other system.

As for OpenSSL, it now complies with RFC 5915

openssl ecparam -name secp256k1 -genkey -noout -out secp256k1-key.pem
openssl asn1parse -in secp256k1-key.pem

    0:d=0  hl=2 l= 116 cons: SEQUENCE
    2:d=1  hl=2 l=   1 prim: INTEGER           :01
    5:d=1  hl=2 l=  32 prim: OCTET STRING      [HEX DUMP]:74B598DD666A5844A2625FB2AC3B9CF4136F53B982CB731263F56273657E96B7
   39:d=1  hl=2 l=   7 cons: cont [ 0 ]
   41:d=2  hl=2 l=   5 prim: OBJECT            :secp256k1
   48:d=1  hl=2 l=  68 cons: cont [ 1 ]
   50:d=2  hl=2 l=  66 prim: BIT STRING

@gmaxwell
Copy link
Contributor

@richardschneider What sipa was pointing out is that encoder inside our contrib directory is not a first class part of the library. We would rather not have that functionality at all and encourage people to not use it-- but we include it (in contrib/) for sake of compatibility with OpenSSL because we needed it for that.

If someone wants to submit PRs to make it better, that aren't incompatible with our usage in bitcoin, and aren't too hard to review-- we'll gladly and thankfully take them. But otherwise we are not very interested in supporting DER private key encoding.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants