RE: [Hash] Charter discussion, round 1

Russ Housley <> Mon, 20 June 2005 14:18 UTC

Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1DkN6C-0006LS-Hx; Mon, 20 Jun 2005 10:18:04 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1DkN68-0006LC-J9 for; Mon, 20 Jun 2005 10:18:02 -0400
Received: from (ietf-mx []) by (8.9.1a/8.9.1a) with ESMTP id KAA02914 for <>; Mon, 20 Jun 2005 10:17:58 -0400 (EDT)
Received: from ([]) by with smtp (Exim 4.33) id 1DkNTm-0002Y3-IO for; Mon, 20 Jun 2005 10:42:32 -0400
Received: (qmail 30272 invoked by uid 0); 20 Jun 2005 14:17:32 -0000
Received: from unknown (HELO ( by with SMTP; 20 Jun 2005 14:17:32 -0000
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Mon, 20 Jun 2005 10:04:00 -0400
To: "Jim Schaad" <>
From: Russ Housley <>
Subject: RE: [Hash] Charter discussion, round 1
In-Reply-To: <>
References: <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Score: 0.2 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
X-Mailman-Version: 2.1.5
Precedence: list
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>


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

As we have already seen posted here, this is the approach being used in 
ECDSA.  Also, NIST is working on a document in this area.  I hope that John 
Kelsey will finish the document before the -00 cutoff, but that seem 
unlikely at this point.

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

I do not see any disagreement here ...

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

I would like to see more discussion of this point on this mail list and ant 
the BoF.  You might be able to convince me that we should include Phase 1 
and Phase 2 in the first version if the charter.

> > >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
>I agree it might have a huge impact on some protocols as well.

I believe that the complexity should be less than adding support for a new 
hash/signature pair.  This should be fairly straightforward if the 
implementation has any kind of a crypto API.  The biggest ripple would seem 
to be looking into the algorithm identifier parameters.  Previously, these 
were always absent or NULL, so a new bit of code will be needed here.


Hash mailing list