1 |
On Tuesday 24 August 2004 20:23, Chris Gianelloni wrote: |
2 |
> ...except in our case we're giving any possible attacker the "original |
3 |
> message" in the original tarball/ebuild/Manifest/whatever... They do |
4 |
> not have to work from the arbitrary hash, at all. |
5 |
|
6 |
As far as I understand what was shown against SHA, they have an attack that |
7 |
allows them to produce hash collisions, but they have to be able to change |
8 |
both texts. ie. they can produce two texts which have the same hash by |
9 |
generating both texts together. What they can't do is copy an existing file |
10 |
and then alter it to generate the same hash. (disclaimer - I haven't rtfp, |
11 |
please correct me here if I'm wrong!) |
12 |
|
13 |
In the gentoo case, this means an attacker could generate a hash collision |
14 |
only if they have the ability to change the tarball/ebuild/patch before it is |
15 |
hashed by a gentoo developer. The easiest way to exploit this would be as a |
16 |
gentoo developer. I could add some trivial patch to glibc and generate it so |
17 |
that it collides with some backdoor code, and then cvs commit it. Normal |
18 |
people see this patch and it looks ok, but I can now do a man-in-the-middle |
19 |
attack and replace that file with my backdoor on any gentoo box. Interesting |
20 |
huh? You could do the same thing with user submitted patches, as long as they |
21 |
get added unaltered. |
22 |
|
23 |
Anyway, the attacks so far have only been against md5, sha0, and 40 round |
24 |
sha1. Full sha1 is still secure, so that is what we should be using. |
25 |
|
26 |
-- |
27 |
gentoo-dev@g.o mailing list |