[Cryptography-dev] keys and signatures import/export

Fri Nov 21 06:58:10 CET 2014

That’d be terrific, Paul, thanks! I’ll keep an eye out for it.

In the meantime, it was straightforward enough to work around it, but only because I happened to already have an ASN.1 decoder in AsyncSSH for other purposes.

By the way, I published version 0.9 of AsyncSSH to PyPI last week, and it now allows you to use either PyCrypto or PyCA or take algorithms from both as the basis for its crypto!

On Nov 20, 2014, at 9:43 PM, Paul Kehrer <paul.l.kehrer at gmail.com> wrote:
> We’ve got an issue filed to track adding support for (r, s) return on DSA/ECDSA (from your original email about this actually!): https://github.com/pyca/cryptography/issues/1285
> 
> I am in favor of adding this, but haven’t spent the time to implement my most recent comment on the issue. I may try to take a look at this soon so we can get it into the seventh release.
> 
> -Paul
> On November 20, 2014 at 7:33:54 PM, Ron Frederick (ronf at timeheart.net <mailto:ronf at timeheart.net>) wrote:
> 
>> In the case of SSH, it would actually be useful to be able to get the raw “r” and “s” values generated when performing the DSA signing operation, as the signing operation performed in SSH (as defined in RFC 4253) for DSA keys requires sending the signature as follows:
>>    Signing and verifying using this key format is done according to the
>>    Digital Signature Standard [FIPS-186-2] using the SHA-1 hash
>>    [FIPS-180-2].
>> 
>>    The resulting signature is encoded as follows:
>> 
>>       string    "ssh-dss"
>>       string    dss_signature_blob
>> 
>>    The value for 'dss_signature_blob' is encoded as a string containing
>>    r, followed by s (which are 160-bit integers, without lengths or
>>    padding, unsigned, and in network byte order).
>> So, to do this, the integer versions of “r” and “s” are needed. Today, to use PyCA, I need to call the finalize() on a DSA signer object and then run a DER decode on the returned string to get back these integers.
>> 
>> For RSA, SSH defines the signature message as:
>>    Signing and verifying using this key format is performed according to
>>    the RSASSA-PKCS1-v1_5 scheme in [RFC3447] using the SHA-1 hash.
>> 
>>    The resulting signature is encoded as follows:
>> 
>>       string    "ssh-rsa"
>>       string    rsa_signature_blob
>> 
>>    The value for 'rsa_signature_blob' is encoded as a string containing
>>    s (which is an integer, without lengths or padding, unsigned, and in
>>    network byte order).
>> In this case, I didn’t have to do any decoding of the value returned by PyCA’s RSA signer object, though, suggesting that PyCA is not returning a DER-encoded value. It’s returning the result of the RSASSA-PKCS1-V1_5-SIGN function defined in RFC 3447:
>>    RSASSA-PKCS1-V1_5-SIGN (K, M)
>> 
>>    Input:
>>    K        signer's RSA private key
>>    M        message to be signed, an octet string
>> 
>>    Output:
>>    S        signature, an octet string of length k, where k is the
>>             length in octets of the RSA modulus n
>> I was able to use this in the SSH protocol directly. This suggests that the RSA & DSA implementations are inconsistent, though, with only one of them DER encoding its result.
>> 
>> I haven’t actually implemented a version of EC signing based on PyCA yet, so I don’t know what is returned there. However, the ECDSA signature blob for ECDSA is defined as:
>> 
>>    Signatures are encoded as follows:
>> 
>>       string   "ecdsa-sha2-[identifier]"
>>       string   ecdsa_signature_blob
>> 
>>    The string [identifier] is the identifier of the elliptic curve
>>    domain parameters.  The format of this string is specified in
>>    Section 6.1 <http://tools.ietf.org/html/rfc5656#section-6.1>.  Information on the REQUIRED and RECOMMENDED sets of
>>    elliptic curve domain parameters for use with this algorithm can be
>>    found in Section 10 <http://tools.ietf.org/html/rfc5656#section-10>.
>> 
>>    The ecdsa_signature_blob value has the following specific encoding:
>> 
>>       mpint    r
>>       mpint    s
>> 
>>    The integers r and s are the output of the ECDSA algorithm.
>> 
>>    The width of the integer fields is determined by the curve being
>>    used.  Note that the integers r and s are integers modulo the order
>>    of the cryptographic subgroup, which may be larger than the size of
>>    the finite field.
>> 
>> So, once again the raw “r” and “s” integer values would be required from the signer object to be able to construct this packet.
>> 
>> Because of these differences, I think there could be value in having a signing primitive in PyCA that returned the raw values rather than returning encoded versions of the values. The exact set of values to return would vary depending on the algorithm, though. For DSA & ECDSA, this would be two integers (r & s), whereas for RSA the return value is already correct (an octet string version of the integer s).
>> 
>> 
>>> On Nov 20, 2014, at 4:21 PM, Alex Gaynor <alex.gaynor at gmail.com <mailto:alex.gaynor at gmail.com>> wrote:
>>> 
>>> The signers/verifiers for RSA and EC keys both use the signature in it's DER encoded format. Did you want to store/load that in a specific file format?
>>> 
>>> Alex
>>> 
>>> On Thu Nov 20 2014 at 3:51:45 PM Jesus Cea <jcea at jcea.es <mailto:jcea at jcea.es>> wrote:
>>> On 20/11/14 04:13, Paul Kehrer wrote:
>>> > Thanks for your interest in the project!
>>> 
>>> Thanks for replying! :).
>>> 
>>> > We have full loading support for PEM encoded asymmetric keys (both
>>> > traditional OpenSSL and PKCS8) as of 0.6. The upcoming 0.7 release
>>> > (probably in around 4 weeks) should add support for serialization back
>>> > to disk. You can view the progress of that work
>>> > here: https://github.com/pyca/cryptography/pull/1390 <https://github.com/pyca/cryptography/pull/1390>
>>> 
>>> Great!. What about digital signature serialization generated from RSA
>>> and EC keys? :-).
>>> 
>>> --
>>> Jesús Cea Avión                         _/_/      _/_/_/        _/_/_/
>>> jcea at jcea.es <mailto:jcea at jcea.es> - http://www.jcea.es/ <http://www.jcea.es/>     _/_/    _/_/  _/_/    _/_/  _/_/
>>> Twitter: @jcea                        _/_/    _/_/          _/_/_/_/_/
>>> jabber / xmpp:jcea at jabber.org <mailto:xmpp%3Ajcea at jabber.org>  _/_/  _/_/    _/_/          _/_/  _/_/
>>> "Things are not so easy"      _/_/  _/_/    _/_/  _/_/    _/_/  _/_/
>>> "My name is Dump, Core Dump"   _/_/_/        _/_/_/      _/_/  _/_/
>>> "El amor es poner tu felicidad en la felicidad de otro" - Leibniz

-- 
Ron Frederick
ronf at timeheart.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20141120/862f6141/attachment.html>