[147544] in cryptography@c2.net mail archive
Re: [Cryptography] Sha3
daemon@ATHENA.MIT.EDU (Jerry Leichter)
Mon Oct 7 09:57:13 2013
X-Original-To: cryptography@metzdowd.com
From: Jerry Leichter <leichter@lrw.com>
In-Reply-To: <E47EDE7A-08F6-4F3A-BDD4-7F6BCDA67F2B@gmail.com>
Date: Mon, 7 Oct 2013 05:59:37 -0400
To: John Kelsey <crypto.jmk@gmail.com>
Cc: David Johnston <dj@deadhat.com>,
"cryptography@metzdowd.com List" <cryptography@metzdowd.com>,
james hughes <hughejp@mac.com>, Ben Laurie <ben@links.org>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
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
