CRYPTO2004 Rump Session Presentations, was Re: A collision in MD5'

james hughes hughejp at mac.com
Tue Aug 17 02:37:03 EDT 2004


Hello:

This is Jim Hughes, General Chair of CRYPTO2002. There are three 
significant Rump session papers on hash collisions that will be 
presented, including an update on this one (and about 40 other short 
papers on other aspects of cryptography). As the session firms up, more 
information it will be posted at

	http://www.iacr.org/conferences/crypto2004/rump.html

Barring technical or other difficulties, if you want to hear this from 
the horses mouth, the CRYPTO2004 Rump Session will be webcast at 7pm 
pacific Tuesday Aug 17 for as long as it takes. You may join us 
virtually using the following links (depending on the readers).

Internet Explorer
	http://128.111.55.99/crypto.htm	

Microsoft media server
	mms://128.111.55.99/crypt

The players (for MS and Mac) are available from
	http://www.microsoft.com/windows/windowsmedia/players.aspx

I assume MS clients will be able to cope. I know that my MacOSX machine 
with Windows Media Player can use the mms: link. I welcome feedback 
from anyone using other readers on other platforms like Linux.

The server is currently up and running and is broadcasting a dark, 
empty, and silent hall. This should be more interesting after sunup 
Tuesday Santa Barbara time. You may expect sound near to the start 
time.

This is our the conferences first webcast, and I hope that it works for 
you. If there are problems, I will apologize in advance.

Thanks

jim




On Aug 16, 2004, at 9:02 PM, Eric Rescorla wrote:

> I've now successfully reproduced the MD5 collision result. Basically
> there are some endianness problems.
>
> The first problem is the input vectors. They're given as hex words, but
> MD5 is defined in terms of bitstrings. Because MD5 is little-endian, 
> you
> need to reverse the written byte order to generate the input data. A
> related problem is that some of the words are given as only 7 hex
> digits. Assuming that they have a leading zero fixes that
> problem. Unfortunately, this still doesn't give you the right hash
> value.
>
> The second problem, which was found by Steve Burnett from Voltage
> Security, is that they authors aren't really computing MD5. The
> algorithm is initialized with a certain internal state, called an
> Initialization Vector (IV). This vector is given in the MD5 RFC as:
>
> word A: 01 23 45 67
> word B: 89 ab cd ef
> word C: fe dc ba 98
> word D: 76 54 32 10
>
> but this is little-endian format. So, the actual initialization values
> should be 0x67452301, etc...
>
> The authors use the values directly, so they use: 0x01234567,
> etc... Obviously, this gives you the wrong hash value. If you use these
> wrong IVs, you get a collision... though strangely with a different 
> hash
> value than the authors provide. Steve and I have independently gotten
> the same result, though of course we could have made mistakes...
>
> So, this looks like it isn't actually a collision in MD5, but rather in
> some other algorithm, MD5'. However, there's nothing special about the
> MD5 IV, so I'd be surprised if the result couldn't be extended to real
> MD5.
>
> -Ekr
>
> ---------------------------------------------------------------------
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to 
> majordomo at metzdowd.com

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list