I just sent this message to cscott privately by mistake.<br><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Jameson Chema Quinn</b> <<a href="mailto:jquinn@cs.oberlin.edu">jquinn@cs.oberlin.edu</a>><br>
Date: Tue, Jun 3, 2008 at 11:54 AM<br>Subject: Re: [OLPC Security] [Techteam] Crypto export and python-crypto<br>To: "C. Scott Ananian" <<a href="mailto:cscott@laptop.org">cscott@laptop.org</a>><br><br><br>
Thanks again for responding; while I still disagree, I am definitely learning from this conversation.<br><br><div class="gmail_quote"><div class="Ih2E3d">On Tue, Jun 3, 2008 at 8:41 AM, 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;"><div>On Tue, Jun 3, 2008 at 9:30 AM, Jameson Chema Quinn<br>
<<a href="mailto:jquinn@cs.oberlin.edu" target="_blank">jquinn@cs.oberlin.edu</a>> wrote:<br>
> On formats, I agree in principle. But as your own email points out, there<br>
> are already two different signature formats invented for the XO, because of<br>
> specifics about what is to be signed. If these do not work for my needs, I<br>
> do not see why I should not invent another.<br>
<br>
</div>Exactly because we already have two, we should avoid having *three*!<br>
<br>
It would be better to patch one of these so we only have *one*. (And<br>
what are the two formats you are referring to?)<br>
<div></div></blockquote></div><div><br><div class="Ih2E3d"> <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</a><br>
</div>
and<br><a href="http://wiki.laptop.org/go/Contents_manifest_specification" target="_blank">http://wiki.laptop.org/go/Contents_manifest_specification</a><br><br><br></div><div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><br>
> The OpenPGP attack you mention has to do with encryption, not signatures.<br>
<br>
</div>Please read page 25 of<br>
<a href="ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1.pdf" target="_blank">ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1.pdf</a>. Although<br>
there is (yet) no practical attack, it (like MD5) is not recommended<br>
for new applications.</blockquote></div><div><br>This is true, but totally separate from the attack you mentioned, which is in fact a practical (though limited) attack. Without reading the references, the implication is that v2.1 is better than v1.5 only in terms of its provability; not only are there no practical attacks on v1.5, there is not even any intimation of any theoretical/incomplete ones, just the theoretical possibility that such might exist.<br>
<br></div><div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<div><br>
> I did look at JAR files, and decided that their format lacked some desirable<br>
> features. They are based on md5 hashes, which are close to broken; they do<br>
<br>
</div>You are wrong. <a href="http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#Digital%20Signatures" target="_blank">http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#Digital%20Signatures</a></blockquote></div><div>
<br>
My reading of this is that there are three stages to a signature.<br>1. manifest file: each subfile is signed by an arbitrary set of hashes including md5<br>2. .sf file: an arbitrary subset of the files in manifest. Each entry in the manifest, including hashes, is signed by md5 alone.<br>
3. digital signature: an RSA (+md5), DSA, or PGP signature on the .sf file.<br> <br>Thus md5 appears 2 or 3 times in this chain, and in step 2 there are no options or redundancy. While a naive view would say that the constraints on the manifest entry format are tight enough to make it more difficult to forge a signature by breaking step 2, a <a href="http://en.wikipedia.org/wiki/Meet-in-the-middle_attack" target="_blank">meet-in-the-middle attack</a> could theoretically break it in as little as twice the time needed to break md5. Also, step 3 does not allow for a simple rsa+shaxxx signature without using pgp.<br>
<br></div><div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><a href="http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#Digital%20Signatures" target="_blank"></a><br>
<div><br>
> not allow for granting privileges to secondary keys, which means that<br>
<br>
</div>You can have any number of .SF signature files, signing any<br>
combination of the contents.</blockquote></div><div><br>You are right. So it is possible to abuse the format to allow this by signing signatures. However, the metadata on signatures must then be separate - either in separate files or as magic attributes in the manifest. This feels like an ugly hack to me.<br>
<br>(Sorry, I realize that I am not fully explaining my thoughts here, because it is beside the point. I assert that there is a way, but there is no good way, within this format, for a master key to say "Signatures from key xxx are valid, as long as their signed metadata states that they were requested by activity yyy". Explaining the details of the bad way I can imagine is unimportant; if you have a good way, let's talk about that instead.)<br>
</div><div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<div><br>
> user; they interact poorly with differential versioning storage; and they do<br>
<br>
</div>They in fact interact quite well. See<br>
<a href="http://wiki.laptop.org/go/XO_updater#Application_updater" target="_blank">http://wiki.laptop.org/go/XO_updater#Application_updater</a><br>
<div></div></blockquote></div><div><br>Ouch. This is somewhat of a monster of a year-old unimplemented specification. It definitely has its attractions, but does not address the problem I was attempting to refer to: compressed files will have much noisier diffs from version to version. On a compressing, versioning file system like jffs + olpcfs, storage should be in an uncompressed archive format like tar IMO. Note that, with Develop, there may be dozens of versions of one activity on the same machine; the redundancy between versions dominates the redundancy within a given version (and the latter is taken care of by jffs2 at the lowest level anyway.)<br>
</div><div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><br>
> not allow for unsigned content in a signed bundle, which makes localization<br>
<br>
</div>I do not believe this to be the case.<br>
<div></div></blockquote></div><div><br>You are correct, I was mistaken. <br></div><div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><br>
> more of a pain. Any one of those problems I could have lived with, the three<br>
> together seem to me like a good enough reason for changing a format. And<br>
<br>
</div>And in the absence of any of the three?<br>
<div><br>
> The contents manifest specification does not fit my needs either.<br>
<br>
</div>I'll let this pass, for now, but I explicitly designed it to fit both<br>
the OS and activity update case, so I find this statement puzzling. I<br>
think what you mean is, "it does not solve *all* my problems for me",<br>
and this is because it is not designed to. It is just one part of a<br>
solution. But I prefer the JAR file format for activities anyway, so<br>
I don't think it's worth belaboring this.</blockquote></div><div><br>Obviously, I need to state my design goals more clearly and explicitly; it is my fault you are puzzled. I will begin to compose an email to do that now, meanwhile I will send this off.<br>
<br>Jameson<br><br></div></div><br>
</div><br>