On Tue, 28 Apr 2009 02:09:02 +0100
Steve Freegard <st...@stevefreegard.com> wrote:
> Well in the case of an emailBL - the worst that can happen is that one
> listed md5 collides with an innocent e-mail address.  By adding in the
> string length it reduces that possibility because both colliding
> addresses would have to be exactly the same length.  I believe you'll
> find that ClamAV uses this method for it's MD5 signatures - to get a
> match it has to match the MD5 and the file size has to match.

MD5 already adds the message length (in bits, as a 64-bit integer) at
the very end of the input before the hash is finalized, so adding it
again as an ASCII representation of bytes isn't really going to improve
anything.

If you're worried about spammers gaming the hash system (e.g. using a
botnet to compute an address with a hash which collides with some
target address), you should bite the bullet and use a longer hash
(something in the SHA family, maybe?)  You could make up for the extra
hash length (in terms of DNS traffic) by using a more efficient encoding
of the hash than hex (e.g. base64 or better) with the obvious caveat
that it'd be more difficult to query.

Given that most software will need new code to support an
email-address-based BL, you should give operational concerns (e.g.
bandwidth requirements) some serious thought while you have the chance.

-- 
Ben Winslow <winsl...@pa.net>

Reply via email to