Re: WG Last Call: SHA-224

[Paul Hoffman / IMC <phoffman@xxxxxxx>]

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