[Hash] Beginning work on truncation and salting

Paul Hoffman <paul.hoffman@vpnc.org> Wed, 06 July 2005 15:43 UTC

Received: from localhost.localdomain ([] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqC45-00076c-6F; Wed, 06 Jul 2005 11:43:57 -0400
Received: from odin.ietf.org ([] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqC43-00074y-D6 for hash@megatron.ietf.org; Wed, 06 Jul 2005 11:43:55 -0400
Received: from ietf-mx.ietf.org (ietf-mx []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12172 for <hash@ietf.org>; Wed, 6 Jul 2005 11:43:53 -0400 (EDT)
Received: from above.proper.com ([]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DqCRN-00024I-Tj for hash@ietf.org; Wed, 06 Jul 2005 12:08:02 -0400
Received: from [] (dsl2-63-249-92-231.cruzio.com []) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j66Fe0lM072791 for <hash@ietf.org>; Wed, 6 Jul 2005 08:40:02 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: <p062309c8bef1a8eda3be@[]>
Date: Wed, 6 Jul 2005 08:39:31 -0700
To: Hash WG <hash@ietf.org>
From: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb
Subject: [Hash] Beginning work on truncation and salting
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

Our tentative charter has the following two issues for work:

The DSA signature algorithm requires a hash function whose output is 160
bits.  The working group will consider at least two approaches to
strengthen one-way hash functions for use in DSA:

   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

   2) Including a random value in the hash function computation.  The
      random value used is transferred at appropriate points in the
      protocol (ideally once for each use of the hash function).  This
      approach is sometimes called a "salted" or "randomized" hash

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

This would be a good time to start looking at Internet Drafts and 
external references to both issues. In specific:

- Are there papers that focus on truncation? Are there explanations 
or proofs that show that simple truncation is sufficient? Or that it 
definitely is not sufficient?

- There are probably many methods for including random values in 
hashes. The one I know of in the IETF is 
<http://www.ietf.org/internet-drafts/draft-irtf-cfrg-rhash-00.txt> by 
Shai Halevi and Hugo Krawczyk. Are there others? If so, what are the 
similarities and differences?

- Moving a bit into our longer-term work, where is the strengthening 
actually needed? Is it needed in protocols that rely on the 
preimaging and second-preimagin strength of a hash, or only in 
protocols that rely on the collision resistance?

- What other topics are relevant to this first part of our work?

--Paul Hoffman, Director
--VPN Consortium

Hash mailing list