James Couzens <jcouzens(_at_)obscurity(_dot_)org> [2004-02-10/19:42]:
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.
This is a different attack -- not cookie forgery but finding the secret
(the HMAC key). For finding the key by brute force, it does not matter
whether the address contains just 64 bits of the hash, or all of it.
Although there are many keys which will yeld the same cookie (hash
prefix) for any given address data, finding such a key (collision) does
not help the spammer in finding valid cookies for other address data
(this is a basic property of cryptographical hashes).
In other words, by only using a part of the hash, we make the "brute
force a valid cookie" attack easier, but not the "brute force the key"
attack. The former is an online attack, whilst the latter can be done
offline (though only in part if we are using not the full hash). The
former yelds only a single valid cookie (which will expire again after
some days).
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.
By design, there's nothing any other MTA out there can do with their
hash anyway, unless the MTA knows the secret. So there's no operability
point in specifying a range of algorithms. The only requirement is that
the cookie can be unambigously parsed within the SRS syntax.
Of course it might still be a good idea to have some recommendations so
people don't use silly things like 1 byte checksums as cookie.
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.
I would say, recommend using a HMAC, but have people use their favourite
hash function. It does not matter whether they use MD5, SHA-1, SHA-256
or something else.
For the address length / security tradeoff, the obvious solution is to
recommend to only use a prefix of a certain length. (choosing some
secret bytes like the 3rd, 7th and 13th has been proposed on this list
before, but that does not increase security any further)
Cheers
Dan
--
Daniel Roethlisberger <daniel(_at_)roe(_dot_)ch>
OpenPGP key id 0x804A06B1 (1024/4096 DSA/ElGamal)
144D 6A5E 0C88 E5D7 0775 FCFD 3974 0E98 804A 06B1
!->