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