spf-discuss
[Top] [All Lists]

MD5 HMAC HASH - 64 or 128 bits?

2004-02-10 20:42:40
On Tue, 2004-02-10 at 17:54, Daniel Roethlisberger wrote:
I think we could get away with less than a full MD5 HMAC hash (22
octets, in your `optimized' base64). Let's say we cut this in half. We
just use the first 64 bits of the hash. Now say we fully consider the
birthday bound, even though it is not really applicable. But we are
conservative. So we get a collision probability of around 2^32. 

This could work, however we seem to be taking flakk as is it using the
entire MD5 HMAC hash, although granted those making the fuss aren't
aware of what they are talking about, and are completely ignoring the
environment and reasons for the hash it seems.  I'm sure Shevek will see
this when he gets up.  I'm about an hour or so away from posting the
libsrs library, I will add a function if I can to use this alternate
lower form of encryption just for fun and see where we go.

Or in
other words, an attacker needs to throw 4 billion messages at your
mailserver for a 50% chance of getting a single lousy message through.
And he will not know if he succeeded.

This isn't the case.  All they need is one message and they can start a
brute force against the hash on a single machine or distributed
computing setup and hammer away at it without sending emails.

That being said, its still an incredible number of calculations to
perform just to spam for a few hours?  What if the MTA in question is
using alternating secrets?  I'm fairly confident that whats existing is
sufficient, even to the point of considering what has been proposed
above.

I think that's more than good enough, and I'd use even shorter cookies
in practice. Think economics, not security systems.

Any way to stay under that 64 char limit is going to make SRS look
better, although after researching it appears violating that limit
wouldn't have much of an impact, as most clients seems to dynamically
allocate the local-part.  However this doesn't mean we should
intentionally break it, but it does gives us some room to breathe.

I would suggest that the final SRS specification should not define the
length of the cookie, nor the exact algorithm, so deployed
implementations can choose their own tradeoff between security and
address length.

Agreed, however, it needs to stay within a certain range of methods in
order to stay sane.  We can't have people deciding they wish to use some
random form and then having every other MTA out there unable to do
anything with their hash.

I'm of the opinion that choice is a good thing, but not lots of choice. 
I think 2, or 3 algorithms would suffice very nicely, perhaps each one
having its "benefit" and "drawback" so one can chose one that suits
their needs best and not worry about it wreaking havoc.

There's one detail to note, this depends to some degree on the
assumption that an attacker has no way of knowing whether a message was
valid or not, ie. messages with invalid cookies must be silently
dropped, not bounced.

I see no reason to not include such functionality.  I would be all for
just killing any bounce that didn't validate (provided I was HOSTB). 
I'm not currently aware of a reason for you to do otherwise?  Does
anyone have a stance on this?

Cheers,

James

-- 
James Couzens,
Programmer

Current projects:
http://libspf.org