Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

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

share|improve this question
5  
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
1  
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
add comment

1 Answer 1

up vote 10 down vote accepted

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.

share|improve this answer
    
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. –  sellibitze Aug 28 '13 at 13:28
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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