7
$\begingroup$

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.)

Improve this question
$\endgroup$
3
  • 6
    $\begingroup$ 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. $\endgroup$
    – mikeazo
    Apr 10, 2013 at 0:10
  • $\begingroup$ @mikeazo: sha-2 is on the table, but for some applications hash pluralism is not an option. $\endgroup$
    – Random Oracle
    Apr 10, 2013 at 16:14
  • 1
    $\begingroup$ 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?. $\endgroup$
    – Gilles 'SO- stop being evil'
    Apr 10, 2013 at 17:57

1 Answer 1

Reset to default
10
$\begingroup$

From John Kelsey on the NIST mailing list for SHA-3 (http://cio.nist.gov/esd/emaildir/lists/hash-forum/msg02656.html if you are on it — it's password-protected):

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.

b. We plan to allow the variable-length feature of Keccak by default, since it seems like such a useful feature.

c. We are considering whether it makes sense to have many different capacities or only one or two.

So short answer, they do seem set to lower the required capacity from the initial proposal so it isn't as dog slow in software, but haven't figured out what the exact settings will be.

Improve this answer
$\endgroup$
1
  • 1
    $\begingroup$ Update: They also plan to use a slightly modified padding scheme to support Tree-Hashing as well as adding a bit of "diversification" so hashes that use the same capacity but different output lengths don't share a common prefix. This is just to mimick SHA2 and its truncated versions. The modified padding is known as Sakura as far as I know. $\endgroup$
    – sellibitze
    Aug 28, 2013 at 13:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.