On 5 October 2013 20:18, james hughes <hugh...@mac.com> wrote: > On Oct 5, 2013, at 12:00 PM, John Kelsey <crypto....@gmail.com> wrote: > >> http://keccak.noekeon.org/yes_this_is_keccak.html > > From the authors: "NIST's current proposal for SHA-3 is a subset of the > Keccak family", "one can generate the test vectors for that proposal using > the Kecca kreference code." and this "shows that the [SHA-3] cannot contain > internal changes to the algorithm." > > The process of setting the parameters is an important step in > standardization. NIST has done this and the authors state that this has not > crippled the algorithm. > > I bet this revelation does not make it to Slashdot… > > Can we put this to bed now?
I have to take issue with this: "The security is not reduced by adding these suffixes, as this is only restricting the input space compared to the original Keccak. If there is no security problem on Keccak(M), there is no security problem on Keccak(M|suffix), as the latter is included in the former." I could equally argue, to take an extreme example: "The security is not reduced by adding these suffixes, as this is only restricting the input space compared to the original Keccak. If there is no security problem on Keccak(M), there is no security problem on Keccak(preimages of Keccak(42)), as the latter is included in the former." In other words, I have to also make an argument about the nature of the suffix and how it can't have been chosen s.t. it influences the output in a useful way. I suspect I should agree with the conclusion, but I can't agree with the reasoning. _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography