[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <200504081720.j38HK8xB017136@turing-police.cc.vt.edu>
Date: Fri Apr 8 18:20:17 2005
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks@...edu)
Subject: Re: Case ID 51560370 - Notice of
ClaimedInfringement
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050408/fc1af93e/attachment.bin
Powered by blists - more mailing lists