On Tue, Nov 1, 2011 at 9:30 AM, Marsh Ray marsh@extendedsubset.com wrote:
I too have been following the development of SHA-3 and will toss in my 2c here.
Hi Marsh! You made several good points, a few of which I quoted below. Your points make me think, speaking loosely, that SHA-3 will turn out to be the best function to use due to reasons of popularity or bureaucratic fiat. Perhaps someday the chips you buy will come with SHA-3 circuits built-in but not SHA-2, and perhaps people will start looking at you funny if you use SHA-2 when everyone else is using SHA-3. These may be good reasons—perhaps better reasons that the moderate performance issues I previously mentioned or the completely indefensible vague unease I've expressed about SHA-3 being too new.
You did make one small technical mistake though:
SHA-3 is also being developed with attention to the amount of circuitry ("die area") needed to implement it in hardware. So it's possible that hardware acceleration will appear for SHA-3 sooner/instead of SHA-2.
Although the SHA-3 designers have indeed tried to optimize for that, I think SHA-256 is actually still better. See Fig. 17 of http://eprint.iacr.org/2009/510.pdf .
Below my signature is just me quoting a few of the points you made. :-)
Regards,
Zooko
Agreed, SHA-3 will fix some problems. Some of these things we've been working around so long that they seem normal.
…
There's sometimes also a benefit of being with the current NIST recommendation. I suspect more users will migrate off of SHA-1 to SHA-3 than they will to SHA-2.
…
NIST may eventually 'deprecate' SHA-2 in favor of SHA-3 due to just the length extension issue. Which is not to say that I think there's a real problem using SHA-2 correctly, only that you may end up having to explain repeatedly why it's not a problem.