Shevek <spf(_at_)anarres(_dot_)org> [2004-02-11/01:15]:
There is a draft paper aavailable on that page which describes the
strategies and justification for the SRS mechanism; this is available
in PDF, PostScript and DVI formats.
At last we have some accurate docs. Great :)
I would appreciate feedback on both the documentation and the code.
I do have some feedback, and this is vaguely connected to the SHA-1 post
from earlier.
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. 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.
I think that's more than good enough, and I'd use even shorter cookies
in practice. Think economics, not security systems.
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.
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.
Comments?
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
!->