In
<Pine(_dot_)LNX(_dot_)4(_dot_)53(_dot_)0402111647010(_dot_)29116(_at_)astray(_dot_)com>
Shevek <spf(_at_)anarres(_dot_)org> writes:
On Wed, 11 Feb 2004, wayne wrote:
In
<Pine(_dot_)LNX(_dot_)4(_dot_)53(_dot_)0402110952540(_dot_)29116(_at_)astray(_dot_)com>
Shevek <spf(_at_)anarres(_dot_)org> writes:
As Daniel Roethlisberger points out, you really don't need a complete
MD5 hash. My gut feel is that even 16 bits of the hash would prevent
any useful spoofing of the SRS system, and I think it would be very
useful to calculate a lower bound. Then, you can use base32 encoding
or something more resilient to strange MTA manglings.
I've been thinking about this a little bit.
All we need to do is make it impractical to use SRS to create open
relays, not impossible. As such, I think that 15-20 bits is probably
more than enough.
15 to 20 bits doesn't provide any pretence of security. It can probably be
cracked in a few milliseconds on an average PC. Since spammers are already
using lots of virus-infected slave machines to perform their task, this
much CPU is negligible.
I don't understand this. I'm talking about using 15-20 bits from the
hash output, not 15-20 bit private keys. I see no way a spammer could
"crack" SRS with 15-20 bits of output.
Speed is an issue in MTAs. Could we save a significant amount of CPU
time by using AES in CBC mode vs MD5? Could we use RC4?
AES is an encryption scheme, not a message authentication scheme.
All encryption systems can be converted into hash functions. Unix has
long used this method for storing secure hashes of passwords in
/etc/passwd.
-wayne