From: Chris Haynes [mailto:chris(_at_)harvington(_dot_)org(_dot_)uk]
Sent: Wednesday, August 17, 2005 4:27 AM
<...>
I understand MD-5 has been shown to have serious flaws,
cryptographically-speaking. I've seen a quote from its author,
Ron Rivest (URL below) , advising people not to use it any more.
There has recently been published a paper suggesting that SHA-1 also,
theoretically, has a similar collision susceptibility. The same
article says that NIST have declared that they are generating a plan
to phase out SHA-1 in favour of SHA-256 over the next few years
because of this risk.
http://www.networkmagazine.com/shared/article/showArticle.jhtml?articleId=47
903171
MD-5 does have serious troubles, but SHA-1 suffers to a lesser extent. For
the time being, I am comfortable with either for email password
challenge/response and for message body hashes to detect replay. The
difficulty of creating a collision with an offline chosen text attack for
SHA-1 is still formidable. Since both SES and DKIM signatures are
time-limited, I don't think this is a serious issue _today_. As CPU's get
faster, it does become an issue, so transitioning to SHA-256 does make some
sense.
<...>
BTW, (& slightly OT), the performance of Sun's Java 1.5 implementation
of digests on my 4 GHz Athlon with 256Kbyte message size is:
Throughput
Mbytes/sec
MD5 28,9
SHA-1 19,2
SHA-256 13,3
SHA-512 8,5
Anyone know how these rates relate to the arrival rate of mail messages on
a
large production server? I'm curious as to the impact of schemes like DK
& SES
which sometimes form / check digests of almost everything. Maybe off-list
responses would be fair to SPF.
This seems reasonable, but realize this is in Java and is probably not
optimized to the extent that a good C compiler would do. Even at the
19.2MBytes/sec for SHA-1, that corresponds to 154Mbits/second, plus
overhead. For a 1Gbit line, you would expect to have a few MTA's attached,
so with some optimization, I don't think this would be the system
bottleneck.
As far as DKIM, the body hash they calculate is not their biggest
computational load. It is verifying the signature. Since CPU's are getting
faster, it is no longer prudent to use short RSA keys, as DK proponents have
previously suggested. Cracking a domain's key is the ultimate breach.
People really should be using 2Kbit keys today, and 4Kbit keys in a few
years. Signatures from those keys are expensive to validate.
The current SHA-1 weakness affects neither SES nor SRS signatures as they
don't use SHA-1, but HMAC-SHA1. The HMAC structure makes the underlying
hash much more resistant to pre-image problems. In the case of HMAC-SHA1,
you also need to guess a 256-bit key. Generating any number of hash
collisions based on the truncated hash outputs attackers have access to is
extremely unlikely to let them guess the key within the signature lifetime.
I can't say for sure, but I suspect that HMAC-SHA1 will still be good enough
for this purpose for many years to come, though we may need to use a few
more result bits than we previously thought. Otherwise, it's pretty trivial
to switch over to HMAC-SHA256, since only the sender needs to know the
algorithm.
--
Seth Goodman