On Fri, 08 Apr 2005 12:50:24 EDT, Jason said: > I think that entirely depends on the format the file is distributed in. > You could take a zipfile and pad it in non critical areas to change the > MD5 without creating a substantial difference in the deliverable > content. You could do the same with gzip or bzip formatted files. You > could also pad any embedded jpeg images to engineer a collision. There > are quite a few opportunities where this method could be used to twiddle > the new MD5 without materially changing the content.
It's easy to tweak a file and get a different MD5. That's why Tripwire works. > Software that is ~150M in size, it gets redistributed as a new file that > is 160M is size but has a collision with your software which is also > 160M in size. I imagine there would be some computational time involved > to find the appropriate collision but a lot less computational time than > finding a perfect match to the original. You're missing the point. Let's say we have a file A that's 150M in size, and a file B that's 160M in size. File B is *not* under our control, and has a known fixed MD5 hash. It's easy to take file A, and create 2 files C and D from it that happen to have the same MD5 hash as each other. What is *NOT* easy is creating a file E that has the same hash as A or B.
pgpOR74rKyUFy.pgp
Description: PGP signature
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
