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

[Jameson "Chema" Quinn]

I have updated
http://wiki.laptop.org/go/User:Homunq/Activity_bundles_v2#Design_goals



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


Sorry, my point was not that 1.5 was good, just that you went overboard in
criticizing OpenSSL for using it. Your original critique mentioned a
specific attack, remember.


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



I get the same error on reboot. Reading that file, I see no relevant change
to the section in question. It still looks as if it has at least one, and up
to 3, MD5-only steps to me.


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

Not for v1.5, just against being too dismissive. I agree, v2.0 is the way to
go.


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


If all or most signatures have a special, one-to-one relationship with some
associated metadata, and in some cases cannot even be created by an activity
without Glucose adding that metadata, it seems to me there are several
reasons to prefer including such metadata in the same file or at least the
same directory. This is not possible with jar files, so any solution is more
or less a hack.

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


I am specifically talking about delta storage. A naive tgz causes an
obnoxiously large delta. A tarfile can have tiny deltas. I am not sure where
zip and --rsyncable lie on this continuum, and whether they are good enough.
(--rsyncable is interesting, and I was not aware of it.) I do not even know
which of those two options is better. This is a question that should be
answered empirically, with some real bundles as examples.


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


Can, yes. However, when is it worth using an established format? I would
argue that when it would be excruciating to use existing tools for that
format by hand; when most such tools are written in a language that does not
even run on your target platform; and when your special needs are large
enough  and against the grain of the format enough that using that format
makes the job harder, both in terms of initial programming effort and
upkeep; then the gain is not worth it.

Jameson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/security/attachments/20080603/4e544019/attachment-0001.htm