RE: [Hash] Charter discussion, round 1

Robert Zuccherato <robert.zuccherato@entrust.com> Thu, 16 June 2005 20:00 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj0XB-0008SY-JC; Thu, 16 Jun 2005 16:00:17 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj0XB-0008ST-2I for hash@megatron.ietf.org; Thu, 16 Jun 2005 16:00:17 -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 QAA02112 for <hash@ietf.org>; Thu, 16 Jun 2005 16:00:11 -0400 (EDT)
Received: from sottmxsecs3.entrust.com ([216.191.252.14]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dj0u5-0000hx-M9 for hash@ietf.org; Thu, 16 Jun 2005 16:24:00 -0400
Received: (qmail 27277 invoked from network); 16 Jun 2005 19:59:59 -0000
Received: from robert.zuccherato@entrust.com by sottmxsecs3.entrust.com with EntrustECS-Server-7.3.1; 16 Jun 2005 19:59:59 -0000
Received: from sottmxs00.entrust.com (10.4.61.22) by sottmxsecs3.entrust.com with SMTP; 16 Jun 2005 19:59:58 -0000
Received: by sottmxs00.entrust.com with Internet Mail Service (5.5.2657.72) id <KSX8YN8B>; Thu, 16 Jun 2005 16:00:00 -0400
Message-ID: <7A3E1242FA9989439AD1F9B2D71C287F042741AD@sottmxs05.entrust.com>
From: Robert Zuccherato <robert.zuccherato@entrust.com>
To: "'Russ Housley'" <housley@vigilsec.com>
Subject: RE: [Hash] Charter discussion, round 1
Date: Thu, 16 Jun 2005 15:59:56 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1
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>
Content-Type: multipart/mixed; boundary="===============0169956806=="
Sender: hash-bounces@lists.ietf.org
Errors-To: hash-bounces@lists.ietf.org

I think we should remove ECDSA from the justification for a truncated hash.
I'm looking at the May 18, 2005 draft which I think will be going for X9F
ballot.  It clearly states in the signature generation and verification
sections that if the hash length is greater than log_2(n) (the subgroup
size) then the leftmost log_2(n) bits of the hash function output should be
used.  Thus, they already appear to have solved this problem.  

If a similar approach was taken with DSA (which would have to be changed
anyway to use anything other than SHA-1) then much of the justification for
the definition of a truncated hash function would disappear.

	Robert Zuccherato.

> -----Original Message-----
> From: hash-bounces@lists.ietf.org 
> [mailto:hash-bounces@lists.ietf.org] On Behalf Of Russ Housley
> Sent: June 16, 2005 10:31 AM
> To: Jim Schaad
> Cc: hash@ietf.org
> Subject: RE: [Hash] Charter discussion, round 1
> = = = = = =
> 
> 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
> 
_______________________________________________
Hash mailing list
Hash@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/hash