Re: WG Last Call: SHA-224

[Russ Housley <[e-mail]>]

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
>