[OLPC Security] [Techteam] Crypto export and python-crypto

[C. Scott Ananian]

On Tue, Jun 3, 2008 at 1:55 PM, Jameson Chema Quinn
<jquinn at cs.oberlin.edu> wrote:
> On Tue, Jun 3, 2008 at 8:41 AM, C. Scott Ananian <cscott at laptop.org> wrote:
>>
>> On Tue, Jun 3, 2008 at 9:30 AM, Jameson Chema Quinn
>> <jquinn at cs.oberlin.edu> wrote:
>> > 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.
>>
>> Exactly because we already have two, we should avoid having *three*!
>>
>> It would be better to patch one of these so we only have *one*.  (And
>> what are the two formats you are referring to?)
>
>  http://wiki.laptop.org/go/Firmware_Key_and_Signature_Formats
> and
> http://wiki.laptop.org/go/Contents_manifest_specification

That is a *manifest* specification and a *signature* specification,
not two signature specifications.

>> > The OpenPGP attack you mention has to do with encryption, not
>> > signatures.
>>
>> Please read page 25 of
>> ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1.pdf.  Although
>> there is (yet) no practical attack, it (like MD5) is not recommended
>> for new applications.
>
> 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.

Like the theoretical future attacks on MD5.  This isn't really worth
discussion.  If RSA suggests that new applications don't use v1.5,
you're not going to convince me I should use it.

>> > 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
>>
>> You are wrong.
>> http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#Digital%20Signatures
>
> My reading of this is that there are three stages to a signature.
> 1. manifest file: each subfile is signed by an arbitrary set of hashes
> including md5
> 2. .sf file: an arbitrary subset of the files in manifest. Each entry in the
> manifest, including hashes, is signed by md5 alone.
> 3. digital signature: an RSA (+md5), DSA, or PGP signature on the .sf file.
>
> 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 meet-in-the-middle attack 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.


I gave you the wrong URL.  Let's reboot with
http://java.sun.com/javase/6/docs/technotes/guides/jar/index.html

which correctly deprecates the MD5-ish-ness of earlier specs.

(And don't you find it ironic that you're arguing for SHA against MD5
here, but for v1.5 RSA signatures against v2.0 above?)

> (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.)

Why does this have to be part of the JAR file format?  Isn't this a
function of rainbow?
The JAR file has a collection of signatures.  Determining whether this
is a *sufficient* collection of signatures is not something that JAR
should be doing.  That is application-level semantics.  I content that
there is nothing OLPC-specific about a collection of files and
signatures.

>> > user; they interact poorly with differential versioning storage; and
>> > they do
>>
>> They in fact interact quite well.  See
>> http://wiki.laptop.org/go/XO_updater#Application_updater
>
> 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.)

Zip files can, of course, be stored with uncompressed entries.  On
disk format does not need to match distribution format.  Delta storage
on the file system (or journal) makes most of what you seem to be
claiming irrelevant. Perhaps you need to study the internal structure
of ZIP more closely?  (While you are at it, studying how rsync works
will help you understand how compression and delta storage interact;
in particular look at the --rsyncable option to gzip.)

> 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.

Yes.  Rebooting to
http://wiki.laptop.org/go/User:Homunq/Activity_bundles_v2, there is no
use case or rationale, just a long list of required files.  And the
second sentence on that page is false.  I'd recommend *starting* with
the rationale, getting it discussed properly, and *then* working out
the on-disk structure.  [Again, I claim that there are no requirements
on the on-disk structure which JAR can not provide.]

Also, you seem to be trying to argue for a particular security model
(what Bitfrost should check, who it should trust, what files need to
be authenticated, etc) at the same time you are making detailed file
system layout decisions and then arguing for certain compression
formats on vague efficiency grounds.  Separating these is the first
step in constructing a readable specification.  Minimizing each
section is the second step. =)
 --scott

-- 
 ( http://cscott.net/ )