RE: [Hash] Charter discussion, round 1

[Russ Housley <[e-mail]>]

Robert:

Thanks for letting me know about the built-in truncation.

See the proposed charter discussion for phase one below.

Russ

= = = = = = =

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 accommodate large hash function output
values.  However, in support of DSA, the hash function output size
needs to match the subgroup size.

The first phase will consider alt least two approaches 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.


At 03:59 PM 6/16/2005, Robert Zuccherato wrote:

I think we should remove ECDSA from the justification for a truncated hash.  I'm looking at the May 18, 2005 draft which I think will be going for X9F ballot.  It clearly states in the signature generation and verification sections that if the hash length is greater than log_2(n) (the subgroup size) then the leftmost log_2(n) bits of the hash function output should be used.  Thus, they already appear to have solved this problem. 

If a similar approach was taken with DSA (which would have to be changed anyway to use anything other than SHA-1) then much of the justification for the definition of a truncated hash function would disappear.

        Robert Zuccherato.

> -----Original Message-----
> From: [e-mail]
> [ mailto:[e-mail]] On Behalf Of Russ Housley
> Sent: June 16, 2005 10:31 AM
> To: Jim Schaad
> Cc: [e-mail]
> Subject: RE: [Hash] Charter discussion, round 1
> = = = = = =
>
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/hash" rel="nofollow"> https://www1.ietf.org/mailman/listinfo/hash
>

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