Re: [saag] Revision of "Attacks on Cryptographic Hashes in Internet Protocols"

Andrey Jivsov <> Wed, 14 November 2012 21:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6AB7C21F84E2 for <>; Wed, 14 Nov 2012 13:41:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.437
X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6WwqHG7E7QX3 for <>; Wed, 14 Nov 2012 13:41:33 -0800 (PST)
Received: from ( [IPv6:2001:558:fe2d:43:76:96:30:16]) by (Postfix) with ESMTP id D1DBC21F8490 for <>; Wed, 14 Nov 2012 13:41:33 -0800 (PST)
Received: from ([]) by with comcast id PR1c1k0071u4NiLA1ZhZ3Q; Wed, 14 Nov 2012 21:41:33 +0000
Received: from [] ([]) by with comcast id PZhY1k00A2g33ZR8hZhYgF; Wed, 14 Nov 2012 21:41:33 +0000
Message-ID: <>
Date: Wed, 14 Nov 2012 13:40:24 -0800
From: Andrey Jivsov <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1
MIME-Version: 1.0
To: IETF Security Area Advisory Group <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [saag] Revision of "Attacks on Cryptographic Hashes in Internet Protocols"
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Advisory Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 14 Nov 2012 21:41:34 -0000

On 11/08/2012 04:29 AM, Paul Hoffman wrote:
> Greetings again. Bruce Schneier and I have started an update to RFC 4270, "Attacks on Cryptographic Hashes in Internet Protocols". This revision is meant to deal with new and more devastating attacks on MD5, the fact that SHA-1 collisions will be financially feasible in the foreseeable future, and NIST's upcoming SHA-3 announcements. We expect to keep this revision process open for at least five months because NIST probably won't finalize the parameters and naming and so on for KECCAK until then; that is, we won't send this to RFC Editor until SHA-3 is finalized. Please take a look at
> Sean and Stephen have agreed that we should use the SAAG mailing list for discussing this draft.
> --Paul Hoffman

One issue stands out for me in this excellent overview: the document 
suggests the preference of SHA-2 over the SHA-3 (Keccak), as in the 
following paragraph:

>    The authors acknowledge that deprecating a hash algorithm is
>    difficult from an operational standpoint, but it needs to be done
>    eventually, and this is a good time to again make a significant push
>    to SHA-2.  When NIST finalizes the parameters and test vectors for
>    SHA-3, implementors might want to start adding SHA-3 to their
>    products.  However, the authors do not believe that any push to start
>    using SHA-3 is warranted at any time soon.

SHA-2 is well-supported today, but there are no solid reasons why SHA-3 
will not be supported equally well in the future.

AES was not the fastest algorithm in software, but look what Intel did 
to it with the AESNI. Keccak is outstanding in hardware and perhaps on 
less mainstream CPU architectures (can't beat table lookup + XOR as min. 
instruction set).

Keccak is arguably the simplest standard hash algorithm, quite 
comparable to the simplicity of MD5.

As the computing environment gets more diverse, this will increase the 
value of Keccak. I support the algorithm agility, but it's not as easy 
to accomplish for the hash algorithms than, for example, for the 
encryption preferences.

Let's say there is a protocols that is hardwired to SHA1 or MD5. Are we 
telling people thinking about its improvement to go with the SHA-2? What 
about newly designed protocols? If you are a maintainer, what would you 
prefer: worry about explaining to others that "my SHA-2 use doesn't 
depend on collision resistance and is not vulnerable to extension 
attacks", v.s. I "use SHA-3".

I suggest that the document at least softens the statements on SHA-2 
v.s. SHA-3. Ideally, I would like to see a path on which we move to the 
universally supported SHA-3 and, hopefully, the hardware manufacturers 
are comfortable to jump in.

Thank you.