Subject: RE: [Hash] Charter discussion, round 1

From: Robert Zuccherato <[email-masked]>
Date: Thu, 16 Jun 2005 15:59:56 -0400

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Russ Housley
> Sent: June 16, 2005 10:31 AM
> To: Jim Schaad
> Cc: [email-masked]
> 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/hash
> 
_______________________________________________
Hash mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/hash

---

From: Russ Housley <[email-masked]>
Date: Thu, 16 Jun 2005 16:10:21 -0400

Robert:

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

See the proposed charter discussion for phase one below.

Russ

= = = = = = =

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

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

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.

[
mailto:[email-masked]] On Behalf Of Russ Housley

>       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

>       random block used
is transferred as a parameter in the algorithm

>       identifier.
This approach is sometimes called a "salted" or

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 21 Jun 2005 17:03:15 -0700

At 3:59 PM -0400 6/16/05, Robert Zuccherato wrote:
>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 

Do we have any information on whether or not the same truncation 
approach is being taken on DSA as ECDSA? That would have a fairly 
significant affect on our charter items. If it isn't being taken, 
finding out why would also be helpful.

--Paul Hoffman, Director
--VPN Consortium