RE: [Hash] Charter discussion, round 1
"Jim Schaad" <ietf@augustcellars.com> Fri, 17 June 2005 19:18 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjMMg-0001d2-0A; Fri, 17 Jun 2005 15:18:54 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DjMMe-0001cx-K4 for hash@megatron.ietf.org; Fri, 17 Jun 2005 15:18:52 -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 PAA15509 for <hash@ietf.org>; Fri, 17 Jun 2005 15:18:50 -0400 (EDT)
Received: from smtp2.pacifier.net ([64.255.237.172]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DjMjj-00046H-Se for hash@ietf.org; Fri, 17 Jun 2005 15:42:48 -0400
Received: from romans (unknown [207.202.179.27]) by smtp2.pacifier.net (Postfix) with ESMTP id 6B39C32735; Fri, 17 Jun 2005 12:18:30 -0700 (PDT)
From: Jim Schaad <ietf@augustcellars.com>
To: 'Russ Housley' <housley@vigilsec.com>
Subject: RE: [Hash] Charter discussion, round 1
Date: Fri, 17 Jun 2005 12:20:17 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <6.2.1.2.2.20050616093927.0660b700@mail.binhost.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527
Thread-Index: AcVygVtq1+YOdbBsQ1KbO/JpRAwRjQA7e9Sg
Message-Id: <20050617191830.6B39C32735@smtp2.pacifier.net>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2
Content-Transfer-Encoding: 7bit
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
Russ, > > 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. Do we have any research available to use about the strengths of truncated hashes? > > >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. In my understanding of the world, it is in the case of signatures that the requirements placed on hash functions are the most restrictive. If we understand this set of needs then phase 2 is just a case of identifying the other places where hash functions are used and figuring out which of the signature elements still apply. Other places that hash functions are used (not all cases are applicable to the IETF and list is not complete) - - collision resistance - i.e. building a symbol table based on the hash of a symbol - low level integrity check - assumes the absence of an attacker - keyed hash function authentication > > >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? Yes I think so, we are identifying the locations where hash functions are being used or are likely to be used in IETF protocols. We are then specifying what prosperities are needed in these situations. This does not seem to be highly reliant on big research issues. > > >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. If we propose to replace SHA-1 in DSA/ECDSA then there is a big change for those signature algorithms. If we propose to replace SHA-1 for RSA v1.5 - that might be a big change, but I would say we should just jump to RSA-PSS where this is not a big issue. I agree it might have a huge impact on some protocols as well. > > 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
- Re: [Hash] Charter discussion, round 1 Eric Rescorla
- [Hash] Hash BoF Russ Housley
- [Hash] Charter discussion, round 1 Paul Hoffman
- Re: [Hash] Charter discussion, round 1 Paul Hoffman
- RE: [Hash] Charter discussion, round 1 Jim Schaad
- Re: [Hash] Charter discussion, round 1 D. J. Bernstein
- Re: [Hash] Charter discussion, round 1 EKR
- Re: [Hash] Charter discussion, round 1 Paul Hoffman
- RE: [Hash] Charter discussion, round 1 Russ Housley
- Re: [Hash] Charter discussion, round 1 Russ Housley
- Re: [Hash] Charter discussion, round 1 Paul Hoffman
- Re: [Hash] Charter discussion, round 1 Russ Housley
- Re: [Hash] Charter discussion, round 1 The Purple Streak, Hilarie Orman
- Re: [Hash] Charter discussion, round 1 Russ Housley
- RE: [Hash] Charter discussion, round 1 Jim Schaad
- RE: [Hash] Charter discussion, round 1 Russ Housley
- RE: [Hash] Charter discussion, round 1 Paul Hoffman
- Re: [Hash] Charter discussion, round 1 Ben Laurie
- Re: [Hash] Charter discussion, round 1 Russ Housley
- Re: [Hash] Charter discussion, round 1 Paul Hoffman
- Re: [Hash] Charter discussion, round 1 Ben Laurie
- Re: [Hash] Charter discussion, round 1 Paul Hoffman
- Re: [Hash] Charter discussion, round 1 Ben Laurie
- Re: [Hash] Charter discussion, round 1 Eric Rescorla