Re: WG Last Call: SHA-224

[Russ Housley <housley@xxxxxxxxxxxx>]

Paul:

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.

I would be willing to add a paragraph to the security considerations that 
point out the equal computational cost for SHA-256 if that would make you 
feel better.

Russ

At 10:52 AM 3/28/2004 -0800, Paul Hoffman / IMC wrote:

> At 4:14 PM -0500 3/26/04, Tim Polk wrote:
> > This specification will provide a stable reference for the SHA-224 
> > algorithm, which is needed by several IETF specifications.
>
> In searching the Internet Drafts directory, only four documents even 
> mention SHA-224:
>
> eastlake-xmldsig-uri: uses it as part of an exhaustive list, not a requirement
>
> pkix-rsa-pkalgs: uses it as part of an exhaustive list, not a requirement
>
> pkix-sha224: the document in question
>
> smime-cms-rsa-kem: uses it but does not justify why it needs it instead of 
> SHA-256
>
> The train may have left the station on this one, but it is really pretty 
> silly. The only possible use is in severely bandwidth-restricted 
> environments where an extra 32 bytes is important. None of the documents 
> above discuss any such environments.
>
> It is silly to say that SHA-256 doesn't "match" 112 bits of encryption 
> strength. There is no disadvantage to having more bits of randomness, 
> particularly because TripleDES doesn't use 112-bit blocks.
>
> This document would be well-served to have an additional paragraph 
> explaining that systems that use TripleDES and need a matching hash 
> algorithm SHOULD use SHA-256, not SHA-224, unless they are in severely 
> bandwidth-restricted environments.
>
> --Paul Hoffman, Director
> --Internet Mail Consortium