In
<Pine(_dot_)LNX(_dot_)4(_dot_)53(_dot_)0402111200390(_dot_)29116(_at_)astray(_dot_)com>
Shevek <spf(_at_)anarres(_dot_)org> writes:
* The SRS crypto is fine.
I see no problems with it also...
* The vulnerability in MD5 is theoretical. However...
ok.
* Government departments have been told not to use MD5, therefore we must
not use it if we want acceptance.
I can see not using MD5 as a secure hash, but for generating a token?
I don't see a problem with acceptance
* Shortening the hash will weaken the algorithm proportionately.
Yes, but this is not a problem.
* Being case insensitive will weaken the algorithm by 40%, as expected.
I will consider case insensitivity to be an option.
No, case insensitivity should be a requirement. The MTA that creates
the SRS has no control over where the key eventually gets relayed to.
The outcomes will be the following:
* Crypto algorithms to become pluggable.
good
* HMAC/SHA1 to become the configurable default.
I think this is overkill. In particular, I think a much larger
problem with acceptance of SRS is the cpu requirements to verify the
validity of an SRS address. You don't want to bog down an MTA by
simply sending lots of SRS checks, this would be a DoS attack.
Remember that there are many MTAs that allow you do do a "sender
verify callback", which means that they will connect back to the
sender and verify that the envelope-from is acceptable.
* Case sensitive to be the configurable default. (Is this OK?)
I don't think so.
* Cutting the hash is possible, but will not be recommended.
Shorter is better if it reduces the chance of going beyond the 64 byte
limit.
-wayne