On Oct 6, 2013, at 11:41 PM, John Kelsey wrote:
> ...They're making this argument by pointing out that you could simply stick
> the fixed extra padding bits on the end of a message you processed with the
> original Keccak spec, and you would get the same result as what they are
> doing. So if there is any problem introduced by sticking those extra bits at
> the end of the message before doing the old padding scheme, an attacker could
> have caused that same problem on the original Keccak by just sticking those
> extra bits on the end of messages before processing them with Keccak.
This style of argument makes sense for encryption functions, where it's a
chosen plaintext attack, since the goal is to determine the key. But it makes
no sense for a hash function: If the attacker can specify something about the
input, he ... knows something about the input! You need to argue that he knows
*no more than that* after looking at the output than he did before.
While both Ben and I are convinced that in fact the suffix can't "affect
security", the *specific wording* doesn't really give an argument for why.
-- Jerry
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
