RE: [Hash] Charter discussion, round 1

Russ Housley <housley@vigilsec.com> Thu, 16 June 2005 14:39 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DivWG-0005oG-2w; Thu, 16 Jun 2005 10:39:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DivWC-0005mS-LK for hash@megatron.ietf.org; Thu, 16 Jun 2005 10:38:59 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27377 for <hash@ietf.org>; Thu, 16 Jun 2005 10:38:51 -0400 (EDT)
Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Divt6-00040W-7a for hash@ietf.org; Thu, 16 Jun 2005 11:02:37 -0400
Received: (qmail 17574 invoked by uid 0); 16 Jun 2005 14:37:38 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.17.75) by woodstock.binhost.com with SMTP; 16 Jun 2005 14:37:38 -0000
Message-Id: <6.2.1.2.2.20050616093927.0660b700@mail.binhost.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Thu, 16 Jun 2005 10:30:42 -0400
To: Jim Schaad <ietf@augustcellars.com>
From: Russ Housley <housley@vigilsec.com>
Subject: RE: [Hash] Charter discussion, round 1
In-Reply-To: <20050614224156.A506B830E6@smtp2.pacifier.net>
References: <p06210210bed50746f518@[10.20.30.249]> <20050614224156.A506B830E6@smtp2.pacifier.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.2 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Cc: hash@ietf.org
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

Jim:

>1. Is this new hash function we are considering in phase 1 going to be the
>same length as SHA-1 or not?  This would appear to be implied by the goals.
>Would replacement of SHA-1 with SHA-256 intact be considered as reasonable
>in the first phase?

This has already been discussed.  Below I propose some words in the charter 
to capture the discussion.

>2. Can we do a reasonable job with phase 1 without having atleast some idea
>of what would be required from phase 2, even if it is not a full set of
>requirements so that we can evaluate phase 1 againist some type of critera.
>Do we then want to start phase 2 (even if it is not completed) right away?

I do not think so.  I think we understand the needs for signatures, which 
is the primary issue for phase 1.

>3.  I think that adding explicit deliverables for phase 2 could wait, I
>think it must wait until a re-charter for phase 3.

Are you saying that we can do a good job on Phase 2 even if the 
participation from the international crypto community is low?

>4.  If a new hash function is recommended by this group, will it also be
>responible to deal with any new signature algorithms and so forth that come
>out of this decision?  For example, DSA is fixed on using SHA-1 and would
>need changes to adapt to any new hash algorithm be it a trucated or a seeded
>hash algorithm.

If you are talking about the assignment of algorithm identifiers, I am not 
really concerned about who does it.

A new hash function should not have deep ripples into the signature 
algorithms.  It may have an impact on protocols to carry parameters.

Russ

= = = = = =

Here is the proposed rewording of the charter discussion of phase 1:

The first phase of the working group will specify one or more standards-
track mechanism replace or strengthen SHA-1.  Two classes of signature
algorithm need to be considered.  In support of RSA, there is no
advantage to reducing the size of a longer hash function output; the
RSA modulus size will easily accomodate large hash function output
values.  However, in support of DSA and ECDSA, the hash function output
size nees to match the subgroup size.

The irst phase will consider alt least two approches to strengthen
one-way hash functions:

   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, 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.  


_______________________________________________
Hash mailing list
Hash@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/hash