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

[C. Scott Ananian]

On Tue, Jun 3, 2008 at 5:36 PM, Jameson Chema Quinn
<jquinn at cs.oberlin.edu> wrote:
>> 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.

OpenPGP, not OpenSSL.  And PKCS v2.1 was released 6 years ago; OpenPGP
still has not provided a way to use RSA-PSS.

The specific attack was on OpenSSL, where the use of DSA caused a poor
random number generator on the server to leak even a
strongly-generated private key on the client.
 http://blog.sesse.net/blog/tech/2008-05-14-17-21_some_maths.html

>> >> > features. They are based on md5 hashes, which are close to broken;
>> >> You are wrong.
[...]
>> 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.

OK, I'm spending a lot of time writing replies to you, and you're not
reading the links I'm sending you.  Please work harder if you want me
to keep responding.  Please search for 'MD5' in the spec and tell me
what it says in the last hit.  Thanks.

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

Your reasoning is poor.  You are creating your own archive format
because you don't want to create an extra file?  Geez.

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

AGAIN, PLEASE READ THE STUFF I ASK YOU TO READ BEFORE MAKING ME READ A RESPONSE!

Thank you.

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

http://www.google.com/search?q=fastjar

It is worth using existing formats even if you have to rewrite all
your tools from scratch, because the format has been used and tested
and understood by more people than just you.  In fact, formats with
multiple implementations are *preferred*, because that shows that they
are well understood.
  --scott

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