Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Has anyone found two files with different sizes and same MD5 sum?

4 views
Skip to first unread message

Ramon F Herrera

unread,
Feb 12, 2009, 8:04:31 PM2/12/09
to

I suppose it is theoretically possible to have two different files
with the same MD5 sum?

TIA,

-Ramon

1PW

unread,
Feb 12, 2009, 8:32:26 PM2/12/09
to
On 02/12/2009 05:04 PM, Ramon F Herrera sent:

Hello Ramon:

It is much more than theoretically possible. An academic group has
proven that md5 based CA certificates can be forged. Albeit using a
very sophisticated hardware setup of 200 PS3 Playstations and
specialized software. Google it to read more.

Pete
--
1PW @?6A62?FEH9:DE=6o2@=]4@> [r4o7t]

1PW

unread,
Feb 12, 2009, 9:04:39 PM2/12/09
to
On 02/12/2009 05:32 PM, 1PW sent:

If you like this sort of thing this is a good read:

<http://www.win.tue.nl/hashclash/rogue-ca/>

David E. Ross

unread,
Feb 20, 2009, 8:54:40 PM2/20/09
to

Yes. However, it is more likely to occur if the situation is contrived.
That is, someone has made an effort to create a file with the same hash
as an existing file. It is unlikely (but not impossible) to occur
through mere coincidence.

Even if MD5 is "broken", it is still quite useful for checking that an
accidental modification or corruption of a file has not occurred. I
create a hash for a very large file before sending it to another
computer. I also send a file containing that hash. At the destination
computer, I again compute the hash and compare it with the hash from the
source computer. (For an extremely large file, I use SHA1 instead of
MD5. This also is a valid use of SHA1 even if it too were "broken".)

--

David E. Ross
<http://www.rossde.com/>.

Don't ask "Why is there road rage?" Instead, ask
"Why NOT Road Rage?" or "Why Is There No Such
Thing as Fast Enough?"
<http://www.rossde.com/roadrage.html>

1PW

unread,
Feb 20, 2009, 9:52:39 PM2/20/09
to
On 02/20/2009 05:54 PM, David E. Ross sent:

> On 2/12/2009 5:04 PM, Ramon F Herrera wrote:
>> I suppose it is theoretically possible to have two different files
>> with the same MD5 sum?
>>
>> TIA,
>>
>> -Ramon
>>
>
> Yes. However, it is more likely to occur if the situation is contrived.
> That is, someone has made an effort to create a file with the same hash
> as an existing file. It is unlikely (but not impossible) to occur
> through mere coincidence.
>
> Even if MD5 is "broken", it is still quite useful for checking that an
> accidental modification or corruption of a file has not occurred. I
> create a hash for a very large file before sending it to another
> computer. I also send a file containing that hash. At the destination
> computer, I again compute the hash and compare it with the hash from the
> source computer. (For an extremely large file, I use SHA1 instead of
> MD5. This also is a valid use of SHA1 even if it too were "broken".)

Hello David:

You've stolen my heart. So few vendors take the trouble to post their
MD5/SHA-1 hashes. It takes a few more moments /now/ saving much time later.

Thank you!

Pete

dekaden|Z

unread,
May 30, 2009, 7:18:42 AM5/30/09
to
David E. Ross schrieb:

> On 2/12/2009 5:04 PM, Ramon F Herrera wrote:
>> I suppose it is theoretically possible to have two different files
>> with the same MD5 sum?
>>
>> TIA,
>>
>> -Ramon
>>
>
> Yes. However, it is more likely to occur if the situation is contrived.
> That is, someone has made an effort to create a file with the same hash
> as an existing file. It is unlikely (but not impossible) to occur
> through mere coincidence.
>
> Even if MD5 is "broken", it is still quite useful for checking that an
> accidental modification or corruption of a file has not occurred. I
> create a hash for a very large file before sending it to another
> computer. I also send a file containing that hash. At the destination
> computer, I again compute the hash and compare it with the hash from the
> source computer. (For an extremely large file, I use SHA1 instead of
> MD5. This also is a valid use of SHA1 even if it too were "broken".)

If you merely want to check for accidental (unintended) corruption (i.
e. transfer or drive errors), just use crc32 or similar. you don't need
ccryptographic hashes for that and therefore it consumes significantly
less resources.

1PW

unread,
May 30, 2009, 12:30:52 PM5/30/09
to

I know this thread is three months old. If one downloads SlavaSoft's
freeware HashCalc 2.02, they may have all the most popular hashes in a
few seconds... CRC32, MD5, SHA-1, etc.

<http://www.slavasoft.com/hashcalc/index.htm>

Works with Linux through Wine too.

Regards,

Jorgen Grahn

unread,
Jan 12, 2010, 3:51:04 PM1/12/10
to
On Sat, 2009-05-30, 1PW wrote:
> dekaden|Z wrote:
...

>> If you merely want to check for accidental (unintended) corruption (i.
>> e. transfer or drive errors), just use crc32 or similar. you don't need
>> cryptographic hashes for that and therefore it consumes significantly
>> less resources.

Sure, but MD5 is almost for free too on decently recent systems.
If you check a file on disk, I/O will be the bottleneck.

CRC-32 is also just 32 bits and (I'd suppose) unsuitable for some
other non-cryptographic uses, like for finding duplicate files by
finding duplicate hashes. http://en.wikipedia.org/wiki/Birthday_problem

> I know this thread is three months old. If one downloads SlavaSoft's
> freeware HashCalc 2.02, they may have all the most popular hashes in a
> few seconds... CRC32, MD5, SHA-1, etc.
>
> <http://www.slavasoft.com/hashcalc/index.htm>
>
> Works with Linux through Wine too.

Good, free implementations of those checksums are preinstalled on
every Linux machine, so running this one in Wine emulation would be a
very strange thing to do.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

unruh

unread,
Jan 12, 2010, 6:12:53 PM1/12/10
to
["Followup-To:" header set to alt.security.pgp.]

On 2010-01-12, Jorgen Grahn <grahn...@snipabacken.se> wrote:
> On Sat, 2009-05-30, 1PW wrote:
>> dekaden|Z wrote:
> ...
>>> If you merely want to check for accidental (unintended) corruption (i.
>>> e. transfer or drive errors), just use crc32 or similar. you don't need
>>> cryptographic hashes for that and therefore it consumes significantly
>>> less resources.
>
> Sure, but MD5 is almost for free too on decently recent systems.
> If you check a file on disk, I/O will be the bottleneck.
>
> CRC-32 is also just 32 bits and (I'd suppose) unsuitable for some
> other non-cryptographic uses, like for finding duplicate files by
> finding duplicate hashes. http://en.wikipedia.org/wiki/Birthday_problem

Oh, nuts. for any given file it is the full 32 bits. The 16 bits is if
you search through a whole bunch of hashes and want to check any two of
them have the same hash. In using a has for testing if it is corrupted,
it is the 32 bits that are important. That is 1/4000000000. I am willing
to check in more detail ( eg use a more complex hash) once in a billion
times.

0 new messages