Subject: Re: WG Last Call: SHA-224

From: "todd glassey" <[email-masked]>
Date: Thu, 1 Apr 2004 08:56:44 -0800

So then why complicate the world with another standard... why not just add
to the SHA256 spec a subsection on 224 usage? and then its not a separate
document at all...

Todd

----- Original Message ----- 
From: "Paul Hoffman / IMC" <[email-masked]>
To: "Russ Housley" <[email-masked]>; "Tim Polk" <[email-masked]>;
<[email-masked]>
Sent: Monday, March 29, 2004 7:41 AM
Subject: Re: WG Last Call: SHA-224

>
> At 10:25 AM -0500 3/29/04, Russ Housley wrote:
> >Paul:
> >
> >>At 8:21 AM -0500 3/29/04, Russ Housley wrote:
> >>>I understand that the computation expense is the same as SHA-256.
> >>>However, as you point out, there are times that a shorter hash
> >>>value is desirable.
> >>
> >>Do we agree that the only times where it is desirable is in
> >>severely bandwidth-restricted environments? Or am I missing some
> >>other scenario?
> >
> >It is also useful is you want all of the algorithms in a cipher
> >suite to offer the same strength.  I remember a SAAG discussion that
> >this was called "impedance match," but I do not particularly like
> >that term.
>
> This is all the more reason to put material in the document that
> tells protocol designers what the design goals for SHA-224 are. Such
> wording should explicitly say that SHA-224 SHOULD NOT be used with
> AES-128 or other asymmetric ciphers that have greater than 112 bits
> of strength.
>
> The reason I am hammering on this is that it is somewhat absurd to
> purposely reduce the strength of one of the algorithms in a cipher
> suite just so it "matches". For example, assume that someone this
> year discovers a trivial method for reducing the effective strength
> of TripleDES from 112 to 108 bits. Clearly, no one is going to stop
> using TripleDES or a suite that uses TripleDES. But, using the logic
> that prompted the creation of SHA-224, we will need a new RFC that
> specifies SHA-216 by shaving off eight more bits from the SHA-256
> result.
>
> Instead of this progression, we should be giving protocol designers
> advice that says "it is fine to use a hash algorithm that produces
> more bits than are needed to 'match' the symmetric key strength".
>
> --Paul Hoffman, Director
> --Internet Mail Consortium
>

---

From: [email-masked]
Date: Fri, 23 Apr 2004 16:18:24 -0400

This message closes working group last call for "A 224-bit One-way Hash 
Function: SHA-224".  I have reviewed the comments on the list since 26 March 
(when Last Call was initiated.)  No technical issues are unresolved, so I am 
forwarding the document to the ADs for progression to RFC status.  As 
suggested by the authors, we are requesting Informational Track for this 
specification. This document is currently available at 

   http://www.ietf.org/internet-drafts/draft-ietf-pkix-sha224-01.txt.

This specification will provide a stable reference for the SHA-224 
algorithm, which is needed by several IETF specifications.  At least two 
independent implementations exist and agree on the test vectors in this 
document.