SHA-3 Winner Announced

An anonymous reader writes "The National Institute of Standards and Technology (NIST) has just announced the winner of the SHA-3 competition: Keccak, created by Guido Bertoni, Joan Daemen and Gilles Van Assche of STMicroelectronics and Michaël Peeters of NXP Semiconductors. 'Keccak has the added advantage of not being vulnerable in the same ways SHA-2 might be,' says NIST computer security expert Tim Polk. 'An attack that could work on SHA-2 most likely would not work on Keccak because the two algorithms are designed so differently.' For Joan Daemen it must be a 'two in a row' feeling, since he also is one of the authors of AES."

Comments

Re:Not vulnerable in the same ways?

[Anonymous Coward]

What makes you extrapolate from "It's safe against the most likely issues SHA-2 might have" to "We chose it because of that but for the rest didn't bother to study it at all?" You surely are not a cryptographer, given that you can't even spell the word.

Re:Not vulnerable in the same ways?

[rbarreira]

I did not extrapolate that, I just said that this sentence in the summary does not sound impressive. In fact it should be a given that SHA-X does not suffer from the same vulnerabilities as SHA-X-1.

Oh and thanks for the spell check.

Re:Why?

[Ash-Fox]

Who would go out of their way to use a new and bleeding edge hash function, but not employ basic best practices like salting and key stretching?

The same companies that are vulnerable to SQL injection exploits because they don't even have pen testing as part of their development cycle.

Are you targeting hash function hipsters?

I think he's targeting major corporations.

Re:I guess that means...

[lengau]

It's pretty simple to protect against that on most implementations. Since you mentioned it, let's take Windows as an example.

To protect against rainbow tables on Windows, all we need to do is generate a 16-byte salt at the time of creation of the password and prepend it to the password pre-hashing. Then we store the salt in plaintext right next to the hashed password. Suddenly, a rainbow table is useless unless you happen to have a pre-generated rainbow table for that particular salt (note that you'd have to generate 2^127 times as many rainbow tables for a 50% chance of having a table with that salt).

Not that this protects against any other attacks, but it certainly does mitigate the rainbow table threat.