[Cryptography-dev] keys and signatures import/export

[Ron Frederick]

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> 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/f370e2a4/attachment.html>