# Any point in waiting for the SHA-3 standard?

The Wikipedia article on SHA-3 says that Keccak has been chosen but the standard hasn't been issued. Does this matter?

That is, can we just assume it's going to be as specified by the submitters (specifically for SHA-3-256 it's the Keccak-f-1600 permutation, in a sponge construction with r=1088 and c=512 and the pad10*1 rule)? Or might NIST wind up tweaking something, meaning we might have to re-hash a bunch of things if we made this assumption -- which, depending on application, could be inconvenient.

(EDIT: of course, waiting is also inconvenient, thus there is a risk-benefit question here -- again, depending on application.)

-
Why would you not wait? Sha-2 is secure by all measures and has had a lot more attention than Keccak. I wouldn't recommend anyone use Keccak even if the standard came out yesterday. Give it a few more years. In the mean time, design all software and protocols such that they are hash function agnostic. That way you can easily switch in the future if it becomes necessary. –  mikeazo Apr 10 '13 at 0:10
@mikeazo: sha-2 is on the table, but for some applications hash pluralism is not an option. –  Random Oracle Apr 10 '13 at 16:14
Keep in mind that SHA-3 is not intended as a replacement for SHA-2, but as an alternative. There is no reason to prefer SHA-3 over SHA-2 at this point unless you're targetting low-end hardware (where SHA-3 can be implemented more efficiently). See What is SHA-3 and why did we change it?. –  Gilles Apr 10 '13 at 17:57

a. We plan to allow the collision and preimage resistance to be the same for SHA3, since that fits with the notion of a single security level, and since that will substantially improve hashing performance. That is, for a security level of 256 bits, we can accept a capacity of 512 bits, representing both collision and preimage attacks of $2 ^ {256}$ work.