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

Eric Rescorla <ekr@rtfm.com> Mon, 10 May 2010 17:16 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B14CF3A6A2D for <tls@core3.amsl.com>; Mon, 10 May 2010 10:16:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.759
X-Spam-Level:
X-Spam-Status: No, score=-0.759 tagged_above=-999 required=5 tests=[AWL=0.467, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, SARE_OBFU_ALL=0.751]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUFPGO9Oi381 for <tls@core3.amsl.com>; Mon, 10 May 2010 10:16:36 -0700 (PDT)
Received: from mail-yw0-f173.google.com (mail-yw0-f173.google.com [209.85.211.173]) by core3.amsl.com (Postfix) with ESMTP id 40E253A6A11 for <tls@ietf.org>; Mon, 10 May 2010 10:15:50 -0700 (PDT)
Received: by ywh3 with SMTP id 3so1109141ywh.31 for <tls@ietf.org>; Mon, 10 May 2010 10:15:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.91.161.22 with SMTP id n22mr2279893ago.91.1273511736560; Mon, 10 May 2010 10:15:36 -0700 (PDT)
Received: by 10.90.25.1 with HTTP; Mon, 10 May 2010 10:15:36 -0700 (PDT)
In-Reply-To: <C80DB5EC.A556%uri@ll.mit.edu>
References: <AANLkTilIrrrmoq9Ji0ZA0SVfStSuUBIxPqtTmBYNTiQT@mail.gmail.com> <C80DB5EC.A556%uri@ll.mit.edu>
Date: Mon, 10 May 2010 10:15:36 -0700
Message-ID: <AANLkTilxAop3SLbt0UY1XISpGPcFjQZTlaAMs72DEEbJ@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
To: "Blumenthal, Uri - 0668 - MITLL" <uri@ll.mit.edu>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] SHA-1 vs. FNV-1
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 May 2010 17:16:37 -0000

On Mon, May 10, 2010 at 10:09 AM, Blumenthal, Uri - 0668 - MITLL
<uri@ll.mit.edu> wrote:
> On 5/10/10  12:58 , "Eric Rescorla" <ekr@rtfm.com> wrote:
>> On Mon, May 10, 2010 at 9:55 AM, Blumenthal, Uri - 0668 - MITLL
>> <uri@ll.mit.edu> wrote:
>>> I see absolutely no need to justify use of non-crypto algorithms for
>>> non-crypto purposes. "It's faster" would be all I'd care to say on the
>>> subject.
>>
>> The requirement is to explain why this is a non-crypto purpose. That's
>> where the analysis comes in.
>
> If there's even a hint that the usage could relate to security mechanisms -
> doesn't it mean that SHA-1 MUST be forbidden, and at least SHA256 should be
> mandated instead?
>
> We seem to be juggling with this back and forth:

You misunderstand me. The argument for not using SHA-1 (apparently) is
that people feel the need to then explain why it's safe to use here. My
point is that this explanation needs to exist in any case and so we might
as well use the common hash, namely SHA-1.


> - either this is security-related - then SHA-1 is not suitable and MUST be
> replaced with a currently-approved SECURE hash algorithm such as SHA256, or

No, this isn't the case.


> - it is not security-related - then SHA-1 is too slow and SHOULD be replaced
> with a faster algorithm.

The claim that SHA-1 is too slow to hash a tiny piece of data which would need
to be hashed multiple times in the handshake computation doesn't strike
me as even remotely plausible.

-Ekr