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

Reply via email to