SHA-3 Second Round Candidates Released

Jeremy A. Hansen writes "NIST just announced their selections for algorithms going to the second round of the SHA-3 competition. Quoting: 'NIST received 64 SHA-3 candidate hash function submissions and accepted 51 first round candidates as meeting our minimum acceptance criteria. We have now selected 14 second round candidates to continue in the competition. Information about the second round candidate algorithms will be available here. We were pleased by the amount and quality of the cryptanalysis we received on the first round candidates, and more than a little amazed by the ingenuity of some of the attacks. ... In selecting this set of second round candidates we tried to include only algorithms that we thought had a chance of being selected as SHA-3. We were willing to extrapolate higher performance for conservative designs with apparently large safety factors, but comparatively unforgiving of aggressive designs that were broken, or nearly broken during the course of the review. We were more willing to accept disquieting properties of the hash function if the designer had apparently anticipated them, than if they were discovered during the review period, even if there were apparent fixes. We were generally alarmed by attacks on compression functions that seemed unanticipated by the submitters.'"

Re:Where's Whirlpool?

[compro01]

It appears that whirlpool was never submitted to the competition.

Re:I was a little worried

[Skuto]

>The thing I like about Skein is its tree mode.

Pretty much every hash in the competition can work in tree mode. Not all submitters defined a tree mode, but that shouldn't stop NIST from defining a good one.

There are better performers than Skein, so unless those are all seriously weakened I doubt it can win. Skein looks good on high end hardware, and not so good on anything else (compared to some other top competitors).

Re:MD6

[Dj]

It was withdrawn from the contest [h-online.com]

Re:I was a little worried

[letsief]

In a practical sense, yes, but the generic preimage attacks against the 512-bit variant of CubeHash work better as the "b" parameter increases. It's still well above the birthday bound, so maybe people shouldn't care. But, it does mean CubeHash16/32-512 "only" provides 384 bits of preimage resistance. That's probably beyond theoretical computation limits for the universe, so I think there's a pretty good argument we shouldn't care. At the same time, all the attacks, and preimage attacks in particular, we're likely to see on 512-bit variants are likely to be well beyond anything that could seen as remotely practical.