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

[Andrey Jivsov <[e-mail]>]

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
>
> http://tools.ietf.org/html/draft-hoffman-schneier-4270bis
>
> 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.