Support for keys generated by ecdsatool (explicit curve parameters)

[Mikaela]

There is longer discussion at kaniini/ecdsatool#5 . I don't think I can say anything useful, but maybe @kaniini can probably help.

[warner]

Does that mean accepting arbitrary curves, instead of the fixed set of (NIST192p, NIST224p, NIST256p, NIST384p, NIST521p, SECP256k1)? Hm. I see the functionality, but I'm nervous about accepting arbitrary curves because of the extra validation you might want to do before using them.

OTOH, maybe we could compare the suggested parameters against our list of known curves and accept it iff it matched one: that would enable interoperability without changing the security properties.

[kaniini]

It does not mean arbitrary curves. The keys in question are valid ASN.1 structures with the curve parameters encoded differently, but your code does not handle them correctly.

[g-p-g]

I think it's limiting to mention ecdsatool here, ideally the module should be able to load at least keys that contain the parameters encoded explicitly. You can generate those using openssl ec ... -param_enc explicit, and there are frameworks for languages that only produce keys like that.

Here's the ASN1 structure for a ec public key encoded like that:

    0:d=0  hl=3 l= 245 cons: SEQUENCE          
    3:d=1  hl=3 l= 174 cons: SEQUENCE          
    6:d=2  hl=2 l=   7 prim: OBJECT            :id-ecPublicKey
   15:d=2  hl=3 l= 162 cons: SEQUENCE          
   18:d=3  hl=2 l=   1 prim: INTEGER           :01
   21:d=3  hl=2 l=  44 cons: SEQUENCE          
   23:d=4  hl=2 l=   7 prim: OBJECT            :prime-field
   32:d=4  hl=2 l=  33 prim: INTEGER           :FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F
   67:d=3  hl=2 l=   6 cons: SEQUENCE          
   69:d=4  hl=2 l=   1 prim: OCTET STRING      [HEX DUMP]:00
   72:d=4  hl=2 l=   1 prim: OCTET STRING      [HEX DUMP]:07
   75:d=3  hl=2 l=  65 prim: OCTET STRING      [HEX DUMP]:0479BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8
  142:d=3  hl=2 l=  33 prim: INTEGER           :FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141
  177:d=3  hl=2 l=   1 prim: INTEGER           :01
  180:d=1  hl=2 l=  66 prim: BIT STRING

To me it seems the easiest way to handle this is specify the curve you assume this to be, and then get only the final bit string from that and parse as usual. It would be better to parse the a, b, p, r, Gx, Gy present in there and check if it matches the curve you're assuming the key to be, but that seems to be a secondary concern.

[g-p-g]

Sample implementation for the above: 5037d6f

[tomato42]

the code in 5037d6f completely ignores the curve parameters... that doesn't look to me like a good approach

the point of including curve parameters, is that the implementation doesn't have to have the parameters for the named curves, it can load them from file and operate on them like that

[tomato42]

I was thinking a bit about it, and I think the first step would be to implement to_der, to_pem, from_der and from_pem in the curves.Curve class. The Curve.to_der and Curve.to_pem should have an optional parameter that will save the curve parameters as either named curve or using explicit parameter encoding (something like openssl ecparam -param_enc option).

The Curve.from_der and Curve.from_pem methods should try to first check if the parameters being imported (if they are explicit, not named curve) are not one of the ones already known to the library. If they are, those methods should return the already pre-generated objects instead of creating a new one (this will make stuff like Curve.openssl_name handling much cleaner).

For cases when the parameters do not match any of the implemented curves, there should be an option to validate the curve parameters (to research: how) but given the complexity of it, we may move it to separate issue and first release without support for curve parameter validation.

Once the previous items are done, they will need to be integrated into the SigningKey and VerifyingKey classes: import from PEM and DER should allow the option of validation of unknown parameters (or refusal of unknown parameters if verification is unimplemented), export should allow specification what kind of encoding should the parameters use (the default of using named curve should be preserved).