Thoughts on MD6 Withdrawel
Last week, Ron Rivest sent mail to the NIST SHA-3 competition mailing list. In it, he makes a number of interesting points on behalf of his MD6 colleagues. The email starts off by saying:
“We suggest that MD6 is not yet ready for the next SHA-3 round…the submitted algorithm MD6 would need significant speed-up in order to match the SHA-2 speeds on the standard reference platforms [a NIST requirement].”
Their motivation for withdrawing MD6 seems to stem from a concern that the competition should focus on finding a provably secure hash function rather than focus on performance as a more important criteria:
“The MD6 submitters feel that it is extremely important that the final SHA-3 algorithm be provably resistant to differential attacks. Indeed, it is the surprising power of differential attacks that stimulated the entire SHA-3 competition.”
The problem is that the MD6 team feels that they cannot reduce the rounds in the algorithm to meet the performance demand and simultaneously keep the provable level of security:
“Thus, while MD6 appears to be a robust and secure cryptographic hash algorithm, and has much merit for multi-core processors, our inability to provide a proof of security for a reduced-round (and possibly tweaked) version of MD6 against differential attacks suggests that MD6 is not ready for consideration
for the next SHA-3 round.”
This kind of performance vs. security tradeoff seems central to an information assurance argument. For high assurance apps, I might be very willing to have a slower but more secure hash.
It is a shame that people won’t get to bang on this particular candidate more as part of the official competition, and I think it suggests that NIST should be converging on a suite of hash functions rather than a one-size-fits-all winner. Why does there have to be one overall winner here? Hashes are used in a variety of contexts, and it seems to me that we are going to wind up with “design by compromise” (pun intended).
This seems like yet another fundamental difference from the AES competition. It is fine to have one symmetric key cipher (very specific purpose), but declaring that there is one answer for hashes…seems a bit short-sighted.
Why does having just one standard hash algorithm help? “Helps…” what (or who) do what?
Although having a single general-purpose hashing ‘solution’ (eeek) appeals to me at a high level in terms of having a single best well-understood standard, I think the community has made a mistake in viewing this competition through the experience of the AES lens.
I lurk on the NIST mailing list for this effort, and from my dipping a toe into the message stream now and then, there seems to exist a great deal of mystique and general disagreement among the experts on just what properties a crypto-strength hash should have. And from what I can tell, the disagreement does not seem to mimic traditional minor squabbles, but rather fundamental disagreement as to what is important — and a large part of this disagreement stems from wildly differing use cases for a hash: one-way mapping? HMAC? PRNG? Crypto algorithm building block? Long term integrity check?
Consider also that having a single winner mandated for all government interaction leaves the whole system without a ready backup should a hole be found in the winning candidate….
