<br><br><div class="gmail_quote">On Mon, Jun 2, 2008 at 3:26 PM, C. Scott Ananian <<a href="mailto:cscott@laptop.org" target="_blank">cscott@laptop.org</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
In email, Morgan writes:<br>
> Jameson Chema Quinn is basing his crypto code for bundle signing on python-crypto: <a href="http://www.amk.ca/python/code/crypto.html" target="_blank">http://www.amk.ca/python/code/crypto.html</a><br>
<br>
I personally would prefer that crypto code be based on the same<br>
algorithms and formats we use elsewhere, as documented at:<br>
<a href="http://wiki.laptop.org/go/Firmware_Key_and_Signature_Formats#Antitheft.2FActivation_Lease" target="_blank">http://wiki.laptop.org/go/Firmware_Key_and_Signature_Formats#Antitheft.2FActivation_Lease</a><br>
</blockquote><div><br>On algorithms, I fully agree. Signatures, for instance, should be based on pkcs1v2.1.<br><br>On formats, I agree in principle. But as your own email points out, there are already two different signature formats invented for the XO, because of specifics about what is to be signed. If these do not work for my needs, I do not see why I should not invent another.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
I took great care to ensure that the every bit in the format is<br>
documented, and traceable in most cases to best practices outlined in<br>
a standards document. This is in marked contrast to places where<br>
you'll find handwaving about "an RSA signature" (say) when there are<br>
multiple ways to use RSA to generate a signature, many of them in fact<br>
terribly bad. (For example, OpenPGP uses an RSA signature scheme<br>
vulnerable to an adaptive chosen ciphertext attack, and the known<br>
covert channels in DSA signatures became very problematic in the<br>
recent Debian/OpenSSL issues.)</blockquote><div> <br>The OpenPGP attack you mention has to do with encryption, not signatures. (And it leaks a tiny fraction of plaintext for 2^16 encryption operations per block). Signatures, becauses they cannot fail partially like this, are inherently more secure than encryption; a mistake like this in a signature would just reduce the exponent on the difficulty of forgery by a small amount, making no practical difference.<br>
</div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
Python bindings are at<br>
<a href="http://dev.laptop.org/git?p=bios-crypto;a=summary" target="_blank">http://dev.laptop.org/git?p=bios-crypto;a=summary</a> and are available in<br>
the olpccontents RPM on the XO.</blockquote><div><br>Now you're talking. I will still have to embed these signatures in a format to fit my purposes, but it appears I can use this code instead of pycrypto. <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
Avoiding the need to declare additional crypto code for export is a<br>
pleasant side effect of using the existing audited codebase; Michael<br>
can tell you the extent to which that is (or is not) necessary in the<br>
case of python-crypto. I don't see anything in python-crypto which is<br>
not included in bios-crypto; most of what python-crypto provides is<br>
either out-of-date (should not be used in new applications) or<br>
duplicates functionality already provided by the standard python<br>
libraries (<a href="http://docs.python.org/lib/crypto.html" target="_blank">http://docs.python.org/lib/crypto.html</a>).</blockquote><div><br>The standard libraries provide only hash functionality. Pycrypto provides symmetric and public-key ciphers. I think it would be good in the long term to have good python bindings for these latter functions - but since with what you've given me I don't need that, I will let that lie. (Openpgp may be the right solution here).<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
Security-sensitive code should also be reviewed on the security list.<br>
>From a software engineering standpoint, I'd be much happier if we just<br>
decided to use JAR files<br>
<a href="http://en.wikipedia.org/wiki/JAR_%28file_format%29" target="_blank">http://en.wikipedia.org/wiki/JAR_(file_format)</a> which already have a<br>
well-defined signature mechanism, instead of designing our own bespoke<br>
thing yet again (see<br>
<a href="http://wiki.laptop.org/go/User:Homunq/Activity_bundles_v2" target="_blank">http://wiki.laptop.org/go/User:Homunq/Activity_bundles_v2</a> and<br>
<a href="http://wiki.laptop.org/go/Contents_manifest_specification" target="_blank">http://wiki.laptop.org/go/Contents_manifest_specification</a> ).<br>
--scott<br>
<font color="#888888"></font></blockquote><div><br>I did look at JAR files, and decided that their format lacked some desirable features. They are based on md5 hashes, which are close to broken; they do not allow for granting privileges to secondary keys, which means that Glucose can't take any of the key management burden off the shoulders of the user; they interact poorly with differential versioning storage; and they do not allow for unsigned content in a signed bundle, which makes localization more of a pain. Any one of those problems I could have lived with, the three together seem to me like a good enough reason for changing a format. And once you make any change, you break existing tools, so there is no reason to the format partially.<br>
<br>The contents manifest specification does not fit my needs either.<br><br>Thanks for responding, I hope to continue the dialog,<br>Jameson Quinn<br></div></div><br>