Re: WG Last Call: SHA-224

["todd glassey" <todd.glassey@xxxxxxxxxxxxxxxx>]

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" <phoffman@xxxxxxx>
To: "Russ Housley" <housley@xxxxxxxxxxxx>; "Tim Polk" <tim.polk@xxxxxxxx>;
<ietf-pkix@xxxxxxx>
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
>