In
<C6DDA43B91BFDA49AA2F1E473732113E0A1859(_at_)mou1wnexm05(_dot_)vcorp(_dot_)ad(_dot_)vrsn(_dot_)com>
"Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com> writes:
I can see not using MD5 as a secure hash, but for generating a token?
I don't see a problem with acceptance
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.
Good point.
Ok, drop MD5 from consideration and any other known weak systems.
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.
There can't be any downgrade attacks because the only part that can no
or care about the crypto system being used is the MTA generating the
SRS. In effect, the choice of crypto system is just extending the
private key size. You shouldn't leak what crypto system you have
chosen to use in your SRS system any more than you should leak any of
your private key.
* 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.
I don't think code footprint is an issue. I that saying "buy an
accelerator" for speed issues is going to be a problem.
RC4 is *very* fast. Fast implementations of RC4 are a matter of a
dozen or so lines of code. RC4 has been studied a lot and as long as
you have a reasonably large initial-value (IV) block. (Why WEP chose
to use only 3 bytes, I have no diea.) RC4 can easily generate as
large or as small of a "hash" token as you want. Accelerators are
available if you need really fast systems.
AES is also pretty fast. Accelerators are available if you need
really fast systems.
I really think speed is an issue here.
-wayne