Caveat - I have not had time to analyze SRS yet. But the issues being raised
are generic.
I can see not using MD5 as a secure hash, but for generating a token?
I don't see a problem with acceptance
MD5 has not yet been broken, but compressor function collisions have been
created using a technique that is not fully public.
The problem is that the weakness was identified ten years ago. If you use
Md5 in an algorithm the crypto protocols community immediately start
thinking 'this guy is a hick'. They also have to work out if the known
weaknesses of MD5 will affect the outcome. That is like telling a builder
that you have decided to have a house built in the US to plans in metric.
Any advantage is immediately lost by the fact that every jig and every tape
measure they normally use becomes completely useless.
Since SHA-1 is very close in design to Md5 and it is considerably stronger
you are better off using SHA-1 and throwing away additional bits. You do not
need 160 bits to deter spammers in this application. 64 bits would probably
be more than sufficient.
Think about it, are you going to commit a cluster of 16 high end
workstations for a week to work out how to spam a single recipient?
Unless you have a binding to the content etc there will be plenty of other
holes in the scheme that are easier to attack.
No, case insensitivity should be a requirement. The MTA that creates
the SRS has no control over where the key eventually gets relayed to.
Yep
The outcomes will be the following:
* Crypto algorithms to become pluggable.
good
I'll have to think on this one. Pluggable crypto is not an unalloyed good.
You can end up with downgrade attacks where you end up with your security
being set by the weakest algorithm.
* 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.
SHA1 is not much different from MD5 computationally. And it is more likely
to be on the platform as default in future. If code footprint is an issue
then SHA-1 is better. If you really get bogged doing SHA then you are going
to find it easier to get an accelerator.
* Case sensitive to be the configurable default. (Is this OK?)
I don't think so.
Remove as many configuration defaults as possible.
* 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.
See earlier discussion.