[Hash] Hash BoF

Russ Housley <housley@vigilsec.com> Thu, 09 June 2005 19:29 UTC

Received: from localhost.localdomain ([] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgSiS-0002e6-VN; Thu, 09 Jun 2005 15:29:24 -0400
Received: from odin.ietf.org ([] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgSiR-0002e1-IE for hash@megatron.ietf.org; Thu, 09 Jun 2005 15:29:23 -0400
Received: from ietf-mx.ietf.org (ietf-mx []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08023 for <hash@ietf.org>; Thu, 9 Jun 2005 15:29:21 -0400 (EDT)
Received: from woodstock.binhost.com ([]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DgT3w-0004em-U5 for hash@ietf.org; Thu, 09 Jun 2005 15:51:38 -0400
Received: (qmail 4902 invoked by uid 0); 9 Jun 2005 19:29:12 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) ( by woodstock.binhost.com with SMTP; 9 Jun 2005 19:29:12 -0000
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Thu, 09 Jun 2005 15:28:58 -0400
To: hash@ietf.org
From: Russ Housley <housley@vigilsec.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.2 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Subject: [Hash] Hash BoF
X-BeenThere: hash@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: hash.lists.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/hash>, <mailto:hash-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/hash>
List-Post: <mailto:hash@lists.ietf.org>
List-Help: <mailto:hash-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/hash>, <mailto:hash-request@lists.ietf.org?subject=subscribe>
Sender: hash-bounces@lists.ietf.org
Errors-To: hash-bounces@lists.ietf.org

There are now 41 members on this mail list.  That seems like enough to get 
the discussion going.

I have attached the proposed charter for the Hash WG.

I have asked Paul Hoffman to act as chair for the Hash BoF in Paris.  He 
has agreed.  So, now I will let Paul lead a discussion about this proposed 

   Russ Housley
   IETF Security Area Director

= = = = = = = = = =

One-way Hash Function BoF (hash)

Security Area Director:
      Sam Hartman <hartmans-ietf@mit.edu>
      Russ Housley <housley@vigilsec.com>

Security Area Advisor:
      Russ Housley <housley@vigilsec.com>

Mailing Lists:
      General Discussion: hash@ietf.org
      To Subscribe:       https://www1.ietf.org/mailman/listinfo/hash
      Archive:            http://www.ietf.org/mail-archive/web/hash/index.html

Description of Proposed Working Group:

Recently, a team of researchers reported that the SHA-1 one-way hash
function offers significantly less collision resistance than could be
expected from a cryptographic hash function with an output of 160 bits.
This result has inspired significant research activities in government
and academia.  Additional information regarding the security of current
one-way hash functions, as well as proposals for new one-way hash
functions, are expected.  The proposed working group responds to the
current state of research in this area.  However, additional research is
likely to provide new insights as the working group progresses.

A three-phase approach is envisioned.  The second and third phases will
be pursued only if it is clear that the international cryptographic
community is actively participating in the working group.

The first phase of the working group will specify one or more standards-
track mechanism replace or strengthen SHA-1.  At least two approaches
will be considered:

   1) Truncate a larger one-way hash function output so that it can be
      used as a secure replacement of a shorter one-way hash function
      output.  For example, as an alternative to SHA-1, the truncation
      mechanism could be used create a 160-bit result from the output of
      the SHA-256 one-way hash function.

   2) Including a random value in the hash function computation. The
      random block used is transferred as a parameter in the algorithm
      identifier.  This approach is sometimes called a "salted" or
      "randomized" hash function.

The first phase may also consider other potential solutions, and one or
more standards-track mechanism will be selected.

The second phase will consider the suitability of one-way hash
functions for use with IETF protocols.  These requirements will be
published as one or more BCP documents which specify the features
and characteristics for standards-track one-way hash functions.  The
BCP documents will also identify information that must be included in
any request for a hash function to be approved on the standards track.

The third phase will identify one or more standards-track one-way hash
functions that fulfill the requirements stated in the BCP documents
developed in phase two.  Guidance will also be developed to assist
protocol developers in the selection among the standards-track one-way
hash functions.

Goals and Milestones:

September 2005:  Charter to authorize phase one.
October 2005:    Submit initial draft of truncation mechanism.
February 2006:   WG Last Call on truncation mechanism.
April 2006:      Submit truncation mechanism as Proposed Standard.
June 2006:       Recharter to authorize phase two. 

Hash mailing list