<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="">That’d be terrific, Paul, thanks! I’ll keep an eye out for it.<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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!</div><div class=""><br class=""></div><div class="">On Nov 20, 2014, at 9:43 PM, Paul Kehrer <<a href="mailto:paul.l.kehrer@gmail.com" class="">paul.l.kehrer@gmail.com</a>> wrote:<div><blockquote type="cite" class=""><div class=""><style class="">body{font-family:Helvetica,Arial;font-size:13px}</style><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class="">We’ve got an issue filed to track adding support for (r, s) return on DSA/ECDSA (from your original email about this actually!): <a href="https://github.com/pyca/cryptography/issues/1285" class="">https://github.com/pyca/cryptography/issues/1285</a></div><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class=""><br class=""></div><div id="bloop_customfont" style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class="">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.</div> <div class=""><br class=""></div>-Paul<br class=""><p style="" class="">On November 20, 2014 at 7:33:54 PM, Ron Frederick (<a href="mailto:ronf@timeheart.net" class="">ronf@timeheart.net</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span class=""><div class=""></div>
<title class=""></title>
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:
<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 class="">
<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/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>
</span></blockquote></div></div></blockquote></div><div apple-content-edited="true" class=""><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 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>