RE: [Hash] Charter discussion, round 1

[Russ Housley <[e-mail]>]

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?

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

Russ


_______________________________________________
Hash mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/hash