[PATCH 2 of 2] bundle2: add a part to import external bundles

[Martin Geisler]

Mike Hommey <mh at glandium.org> writes:

> On Sun, Oct 12, 2014 at 01:54:09AM +0200, Mads Kiilerich wrote:
>> 
>> Why care about md5 at all?
>> 
>> Why support multiple digests? That seems like unnecessary complexity.
>> The rest of Mercurial might be moving away from sha1 one day, but
>> then this should be handled like everything else.
>
> Because both md5 and sha1 are already weakened and they are the only
> digests we can support as long as mercurial sticks to supporting
> python 2.4. The bundles don't /need/ to contain all digest types, but
> having multiple ones when the only available ones are md5 and sha1
> kind of increases security (it's harder to create collisions for
> *both* digests at the same time)

Intuitively, that sounds correct.

However, I think there are some assumptions behind this claim that may
not apply here. One assumption is that the collisions you find for one
hash function is independent of the collisions you find for the other.
That need not be the case -- indeed, I believe it won't be the case if
you're trying to find two simultaneous collisions.


This reminds me a little about an exercise I saw as a TA for an
introductory course in cryptography. The question was if DES encrypting
a message twice would be equivalent to using a key of twice the length?

The answer is no. Given both the message and the ciphertext, you can
recover the key with just 2 * 2^56 DES invocations: you make a table
with all 2^56 possible encryptions of the the message and another table
with all 2^56 possible decryptions of the ciphertext. Finding a match
between these two tables reveals the key. This is one reason why there
is no "double DES" standard.

I know this is not the same situation, but it shows that one has to be
careful when expecting some kind of benefit from applying crypto
primitives twice.

-- 
Martin Geisler

http://google.com/+MartinGeisler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20141012/a8ef1e6a/attachment.pgp>