<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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:<div class=""><pre style="word-wrap: break-word; white-space: pre-wrap;" class=""> 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).
</pre><div class="">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.</div><div class=""><br class=""></div><div class="">For RSA, SSH defines the signature message as:</div><div class=""><pre style="word-wrap: break-word; white-space: pre-wrap;" class=""> 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).
</pre></div><div class="">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:</div><div class=""><pre style="word-wrap: break-word; white-space: pre-wrap;" class=""> 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</pre></div><div class="">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.</div><div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class=""><pre class="newpage" style="font-size: 1em; margin-top: 0px; margin-bottom: 0px; page-break-before: always;"> 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
<a href="http://tools.ietf.org/html/rfc5656#section-6.1" class="">Section 6.1</a>. Information on the REQUIRED and RECOMMENDED sets of
elliptic curve domain parameters for use with this algorithm can be
found in <a href="http://tools.ietf.org/html/rfc5656#section-10" class="">Section 10</a>.
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.
</pre></div><div class=""><br class=""></div><div class="">So, once again the raw “r” and “s” integer values would be required from the signer object to be able to construct this packet.</div><div class=""><br class=""></div><div class="">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).</div><div class=""><br class=""></div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Nov 20, 2014, at 4:21 PM, Alex Gaynor <<a href="mailto:alex.gaynor@gmail.com" class="">alex.gaynor@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">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?<br class=""><div class=""><br class=""></div><div class="">Alex</div><br class=""><div class="gmail_quote">On Thu Nov 20 2014 at 3:51:45 PM Jesus Cea <<a href="mailto:jcea@jcea.es" class="">jcea@jcea.es</a>> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 20/11/14 04:13, Paul Kehrer wrote:<br class="">
> Thanks for your interest in the project!<br class="">
<br class="">
Thanks for replying! :).<br class="">
<br class="">
> We have full loading support for PEM encoded asymmetric keys (both<br class="">
> traditional OpenSSL and PKCS8) as of 0.6. The upcoming 0.7 release<br class="">
> (probably in around 4 weeks) should add support for serialization back<br class="">
> to disk. You can view the progress of that work<br class="">
> here: <a href="https://github.com/pyca/cryptography/pull/1390" target="_blank" class="">https://github.com/pyca/<u class=""></u>cryptography/pull/1390</a><br class="">
<br class="">
Great!. What about digital signature serialization generated from RSA<br class="">
and EC keys? :-).<br class="">
<br class="">
--<br class="">
Jesús Cea Avión _/_/ _/_/_/ _/_/_/<br class="">
<a href="mailto:jcea@jcea.es" target="_blank" class="">jcea@jcea.es</a> - <a href="http://www.jcea.es/" target="_blank" class="">http://www.jcea.es/</a> _/_/ _/_/ _/_/ _/_/ _/_/<br class="">
Twitter: @jcea _/_/ _/_/ _/_/_/_/_/<br class="">
jabber / <a href="mailto:xmpp%3Ajcea@jabber.org" target="_blank" class="">xmpp:jcea@jabber.org</a> _/_/ _/_/ _/_/ _/_/ _/_/<br class="">
"Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/<br class="">
"My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/<br class="">
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz</blockquote></div></div></blockquote></div><div apple-content-edited="true" class="">
<span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px;"><div class="">-- </div><div class="">Ron Frederick</div><div class=""><a href="mailto:ronf@timeheart.net" class="">ronf@timeheart.net</a></div><div class=""><br class=""></div></span><br class="Apple-interchange-newline">
</div>
<br class=""></div></body></html>