What about MD5 hashing the body of the message...

[Russ Allbery]

Ian Freislich <iang at uunet.co.za> writes:

> In the same way the number of MD5 hashes generated before you get a
> clash (the same hash for differing input) is significantly less than
> 2^128 which is the largest number that may be represented by the MD5
> digest.  The likelihood that MD5 will produce that same hash for
> diffrent inputs increases as the size of the input data decreases.  It
> is also fairly easy given an MD5 hash to generate some data that will
> produce the same hash.

> The application of this information is more relevant to INN's history
> file than to the proposed 'X-Body-MD5: ' type header problem since news
> admins are not likely to forge the body of a message, and then they
> would be able to forge the MD5 hash for the body, and it is fairly easy
> to forge a news article any way.

> My concern is that (last time I looked, anyway) the MessageID was hashed
> using MD5 to give a key for history lookup and insertion.  I'm not sure
> if this is still the case, but given the volume of news and the small
> size of MessageIDs it is extremely likely that duplicate keys will be
> generated for different MessageIDs.

It's worse than that; we don't even use the entire MD5 checksum.  (We will
after I finish putting an API around the history format.  Must find more
coding time.)  But we don't care about MD5 being unique forever, just for
about fourteen days, which isn't as hard.

> Our resident crypto fanatic suggests that SHA-1 be used in place of MD5,
> or better still, two different hasing algorithms are used on the same
> data to produce a compsite hash since it is very unlikely that the data
> will have the same 'birthday attack' vulnerability yielding the same
> composite hash from the two different hasing algorithms.

The problem with switching to SHA-1 is that it's slower.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>