NIST Gives Keccak Function SHA-3 Designation
Last night, NIST announced the winner of the SHA-3 competition that began back in 2007. The algorithm being standardized is the Keccak (pronounced "catch-ack"). The function was designed by programmers from Belgium and Italy, most notably Joan Daemen who co-designed the Rijndael cipher we've come to know as AES. Keccak is not derrived from SHA-2. The advantage here is that any future attack on SHA-2 does not extend into an attack - hypothetical or manifested - on SHA-3.
The thing to keep in mind when considering this news is that SHA-3 is neither replacing a broken algorithm nor providing a one-stop-shop for protecting sensitive data. If we've learned just one thing since the advent of the GPU, it should be that hashing functions are deterministic unidirectional compression functions and not what we should think of as encryption. These things are so fast that use of a hashing function to protect your data is undone simply by exhaustively compressing comparison messages until we've found a matching hash.
Why am I on a soap box about it? Two reasons.
First, I'm already seeing people eager about "upgrading" existing security functions that currently employ SHA-2 to SHA-3. This is nonsense; SHA-3 is not quantifiably more secure than SHA-2. Please don't do this. It's a waste of your time and your employer's money.
Second - and more troubling - I've seen some folks excited about "upgrading" from bcrypt to SHA-3. This isn't nonsense, it's absurd. An algorithm like bcrypt is valueable and useful for applications like salted password storage because it is a memory-hard key derivation function. It is slow and when it comes to storing passwords, slow is secure. To the person who already knows the password, an evaluation of a few thousand milliseconds is less than a hiccup. But it renders that mode of attack wildly impractical for someone who wants to brute force your stolen password hash. The Keccak function does not compare to this; if you eschew something int he bcrypt/scrypt/PBKDF2 family for simple SHA-3, you're regressing back into GPU-assailable territory.
The round-about point I'm making here is that the NIST announcement does not radically change the landscape. If this news has you thinking about radical change in your software already, you've probably not got your feet planted firmly on the ground. Best to consider SHA-3 an option to, but not a replacement for SHA-2.
Postscript: Please tell me you're not still using SHA-1. Please, please tell me you're not still using SHA-0 or MD5.
