> To create a collision is non-trivial and would also drastically > change the filesizes. > > Sorry, > davidu
You're (maybe) right but lets take a look at this file: ftp://ftp.openbsd.org/pub/OpenBSD/snapshots/i386/MD5 There's no entry for the Size... Btw: Because another guy told me to buy a CD: I do But what's about ARCHs wich ar enot on the CD? And yes: Adding another Checksum wouldn't prevent an Attacker to recrete these files and replace them. But the chance isn't very high that an attackler could own 3 or 4 different Servers in different networks at the same time. So every user would be able to compare the Checksums with checksums stored in a file on another server. Using RMD160 and SHA1 too would prevent the fatc that it is currently possible to create a working collision (every Admin of every Mirror could do that even it's hard.). I think if you would simple add also RMD160 and SHA1 Checksums its much harder to create a matching collision for all algorithms. Kind regards, Sebastian > On Jul 24, 2005, at 11:22 AM, [EMAIL PROTECTED] wrote: > >>> On 7/24/05, [EMAIL PROTECTED] >>> <[EMAIL PROTECTED]> >>> wrote: >>> >>>> MD5 isn't realy that secure and so I would like to have a rmd160 and >>>> sha1 >>>> Checksum-file to ensure that I downloaded original stuff. >>>> >>> >>> Changing the algorithm (or adding another, for that matter) will not >>> provide greater proof of authenticity. >>> >>> Without some form of signature placed on them, hash values do not >>> provide authenticity. All a check will tell you is whether the hash >>> values match. Altering or recreating hash values is trivial, whether >>> you use MD5 or any other algorithm. IIRC, MD5 is vulnerable to >>> crafted >>> input to the extent that it's possible to create collisions. >>> >>> To provide MessedWithOpenBSD, one would need to compromise the >>> distribution system. Supposing such a thing happened, the attacker >>> would have little trouble creating new checksum files. Given matching >>> checksums, you won't detect anything wrong with the distribution set >>> at the install stage.. >>> >>> >>> Changing or adding algorithms is not an adequate solution to your >>> worries. Signatures may be, once it's clear whose signature to trust >>> and how to get that (group of) person(s) to sign off on everything on >>> the FTP servers. For those interested, the people on the >>> [EMAIL PROTECTED] list discussed this area during the last few >>> days >>> (for a project named BPG, the BSD Privacy Guard). >>> >>> Cheers, >>> >>> Rogier >>> >> >> It's more the fact that somebody could modify the archiv but the >> MD5-Checksum would be the same. That's no "fiction" nor an "illusion". >> But I can't exspect that e.g. Theo knows every Serveradmin of every >> Mirror-Server. So if a Administrator of a Mirror-Server would >> modify the >> package during a MD5-Collusion the MD5-Hash would be still the same >> but >> the content would have been changed. >> >> A digital signature would be the best solution but the easiest way >> is to >> create also rmd160 and sha1 checksums. Sure that's no protection >> against >> modification but it would allow everybody here to compare the >> checksums >> from a mirror with e.g. the checksums on the main FTP-Server. >> >> So it's possible to create a collusion for MD5 but it's much harder to >> create a collusion for MDA and RMD160 and SHA1. >> >> Kind regard, >> Sebastian >> >> >> !DSPAM:42e3de0e288871067321449!
