ietf-mailsig
[Top] [All Lists]

Hash BoF (fwd)

2005-06-02 14:27:14


Probably of interest here, considering how every proposal here is using SHA1.

---------- Forwarded message ----------
Date: Thu, 02 Jun 2005 17:20:13 -0400
From: Russ Housley <housley(_at_)vigilsec(_dot_)com>
To: cfrg(_at_)ietf(_dot_)org
Subject: [Cfrg] Hash BoF

This is a brief note to let the members of the CFRG know about the Hash BoF that will take place in Paris at IETF 63. We have a mailing list, and we respectfully ask for people to join that lsit for any discussion.

Thanks,
  Russ Housley
  IETF Security Area Director

= = = = = = = = = =

One-way Hash Function BoF (hash)

Security Area Director:
     Sam Hartman <hartmans-ietf(_at_)mit(_dot_)edu>
     Russ Housley <housley(_at_)vigilsec(_dot_)com>

Security Area Advisor:
     Russ Housley <housley(_at_)vigilsec(_dot_)com>

Mailing Lists:
     General Discussion: hash(_at_)ietf(_dot_)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.


_______________________________________________
Cfrg mailing list
Cfrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/cfrg


<Prev in Thread] Current Thread [Next in Thread>
  • Hash BoF (fwd), william(at)elan.net <=