1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
On July 24, 2003 12:30 am, you wrote: |
5 |
|
6 |
> |
7 |
> I'd be VERY careful with this. |
8 |
> http://www.rsasecurity.com/rsalabs/faq/3-6-6.html |
9 |
|
10 |
I am familiar with this. But in practice its not an issue. |
11 |
|
12 |
Each chunk of the file would be protected by a MD5 hash and then the |
13 |
file as a whole is protected by a different MD5, any change to the data |
14 |
that passes the MD5 protecting one chunk would fail the MD5 protecting |
15 |
the file as a whole. |
16 |
|
17 |
I suspect the referenced machine would work only looking at hashes that |
18 |
belong in a reduced domain, ie the upper X bits being zero. In our |
19 |
application that is not an option. Our problem is not a birthday attack |
20 |
but rather a search for a small set of possible values. |
21 |
|
22 |
As well anyone who has the resources to spend on creating a machine such |
23 |
as the one described would have much more profitable uses for it. |
24 |
|
25 |
I am thinking of protecting each chunk with a smaller hash (say 64 bits) |
26 |
and use it just to detect transmissions errors. A full MD5 or SHA1 |
27 |
would protect the file as a whole. This would reduce the bandwidth |
28 |
requirements of the central tracker. In the event that a bad chunk |
29 |
passes the reduced hash test then the full file hash would cause the |
30 |
entire download to be rejected rather than just one chunk. So in the |
31 |
worst case a malicious user could cause a lot of failed downloads but |
32 |
no corrupted files. |
33 |
- -- |
34 |
Fred Van Andel |
35 |
fava@g.o |
36 |
GPG KeyID: 76526AD599455482 |
37 |
GPG fingerprint: 64E4 4BAB 9C99 D565 3E3C F5D0 7652 6AD5 9945 5482 |
38 |
-----BEGIN PGP SIGNATURE----- |
39 |
Version: GnuPG v1.2.2 (GNU/Linux) |
40 |
|
41 |
iD8DBQE/Hj7hdlJq1ZlFVIIRAkCCAJ9i2IxN6rSvWnHFmucimtZwMkeiggCZAUeA |
42 |
s3n6mdCInenSfgFyWegQ3uM= |
43 |
=OO70 |
44 |
-----END PGP SIGNATURE----- |
45 |
|
46 |
|
47 |
-- |
48 |
gentoo-dev@g.o mailing list |