On Oct 27, 2015, at 12:27 PM, Peter Hamilton <peter.allen.hamil...@gmail.com> wrote: > I'm trying to add a tests/hazmat/primitives/fixtures_ec.py file containing > EllipticCurve fixtures for use in testing the certificate validation feature > I'm working on, and I have a few questions. I'm using OpenSSL to generate > EllipticCurve public/private keys, with the intent of then adding them in > fixtures_ec.py as Python literals (like how fixtures_rsa.py and > fixtures_dsa.py handle things). > > When defining EllipticCurvePrivateNumbers, is the hex string used for the > private_value argument taken verbatim from the priv field in the > EllipticCurve private key file, or is it the hex of the integer produced > after converting the priv hex string according to the rules in RFC 5915 and > 3447? I have the same questions regarding the x and y fields of the > EllipticCurvePublicNumbers object that's also needed by > EllipticCurvePrivateNumbers. It's not clear to me, from looking at the RSA > and DSA examples, how they're handled so without more context here I'm pretty > much stuck. I tried backtracking how the EllipticCurvePrivateNumbers data is > used by the backends but I didn't find anything that shed light on the > situation.
The private value in DER or PEM encoded ECDSA keys is an octet string, but it must be converted to an integer before it is passed to EllipticCurvePrivateNumbers. In Python, you can use “int.from_bytes” for this, passing in ‘big’ as the byte order. The x and y public values in DER or PEM encoded ECDSA values must also be converted to integer values before being passed to EllipticCurvePublicNumbers. However, they are encoded together in a single ASN.1 value which must be first decoded as described in RFC 5480 or http://www.secg.org/sec1-v2.pdf. The point byte string is encoded as an ASN.1 bit string in the case of EC private keys, so it must first be decoded as bytes (and confirming that it is a multiple of 8 bits long with no padding bits). EC public keys encode this in ASN.1 directly as an octet string, so this last point isn’t an issue there. There’s work going on right now to add EC point encode/decode functions to Cryptography, so if you wait a bit you won’t need to code that yourself. See the discussion at: https://github.com/pyca/cryptography/issues/2346 > Also, is OpenSSL the best tool to use here for generating these test > examples? It's what I've always used but if there's another tool that > generates the EllipticCurve keys in the format that cryptography expects, I'm > happy to switch to using that to generate the examples. I generally use OpenSSL to generate keys, but it’s also possible to use “ssh-keygen”. In addition to PKCS#8 and the older PEM encoding, it supports a few more formats, but those are probably only interesting if you are looking to interoperate with SSH rather than SSL. -- Ron Frederick r...@timeheart.net _______________________________________________ Cryptography-dev mailing list Cryptography-dev@python.org https://mail.python.org/mailman/listinfo/cryptography-dev
