On Oct 1, 2013, at 4:48 AM, ianG <[email protected]> wrote: ... > This could be the uninformed opinion over unexpected changes. It could also > be the truth. How then to differentiate? > > Do we need to adjust the competition process for a "tweak" phase? > > Let's whiteboard. Once The One is chosen, have a single round + conference > where each of the final contestants propose their optimised version. They > then vote on the choice.
I like the general idea here, but I suspect a vote at the end of a conference isn't going to yield great results. I'd hate to see something the designers opposed get adopted because they were outvoted by (say) a larger team. > (OK, we can imagine many ways to do this ... point being that if NIST are > going to tweak the SHA3 then we need to create a way for them to do this, and > have that tweaking be under the control of the submitters, not NIST itself. > In order to maintain the faith of the result.) The Keccak designers proposed reducing the capacity. You can find public statements about this online, including in the slides on their website. Also, the capacity is a parameter defined in the standard to allow an easy to understand performance/security tradeoff. Setting c=256 gives an across the board security level of 128 bits, if you believe the underlying Keccak permutation is good. The actual technical question is whether an across the board 128 bit security level is sufficient for a hash function with a 256 bit output. This weakens the proposed SHA3-256 relative to SHA256 in preimage resistance, where SHA256 is expected to provide 256 bits of preimage resistance. If you think that 256 bit hash functions (which are normally used to achieve a 128 bit security level) should guarantee 256 bits of preimage resistance, then you should oppose the plan to reduce the capacity to 256 bits. If you think a 256 bit hash function should only promise 128 bits of security, except in specific applicaitons like keyed hashes where it has been analyzed specifically and shown to get more, then you should (at least on technical grounds) like the proposal to reduce the capacity to 256 bits for a 256-bit hash output. --John _______________________________________________ The cryptography mailing list [email protected] http://www.metzdowd.com/mailman/listinfo/cryptography
