Re: [TLS] SHA-1 vs. FNV-1

[Eric Rescorla <[e-mail]>]

On Mon, May 10, 2010 at 9:35 AM, Marsh Ray <[e-mail]> wrote:
> On 5/9/2010 4:19 PM, Blumenthal, Uri - 0668 - MITLL wrote:
>> our current
>> practice of using SHA-1 is dying just like the previous practice of
>> using MD5 (and MD4 before it) is dead. So justifying continuous use
>> of SHA-1 is improper: for security purposes it is broken, and for
>> non-security purposes it's rather slow.
>
> Well said. That is my opinion, too.
>
> To put it another way: Any argument that could be made in favor of using
> SHA-1 could be made in favor of MD5 (or even MD4). In fact, MD5 would be
> superior. It's also "in everybody's stack already" right? (Ignoring
> those for the moment those who will implement only TLS 1.2 and forward.)
> Plus, MD5 is more efficient. So anybody insisting on SHA-1 should
> justify the extra CPU usage over MD5, no?

No, that's not true. Again, SHA-1 is simply the default hash algorithm people
use at this point. Other than that, MD5 would be fine, yes.


As for "insisting", I really don't know what you mean. I'm not "insisting"
on SHA-1 any more than Stefan is "insisting" on FNV-1. This is an undecided
question in the WG and I'm stating my opinion.


> Let's not forget where this started:
>
> Additional protocol elements for dynamically negotiating among a
> extensible set of cryptographic hash functions for use where a
> cryptographic hash function was not needed anyway. Vendors would be
> expected to support some perpetual subset of them or risk
> interoperability problems (probably everyone would just end up using
> that one everywhere anyway). Servers might have to track multiple hash
> values for the same resource. Another set of parameters for attackers to
> manipulate imperfect implementations with.

I have no brief for those elements. I'm happy to simply mandate SHA-1.

> Additional explanation when a
> security review legitimately questions the use of deprecated crypto
> algorithms.

As I noted previously, that exact explanation will need to be present
to justify the use of a non-cryptographic hash.

-Ekr