Re: NIST publishes new DSA draft

[David Shaw <[e-mail]>]

On Sun, Mar 19, 2006 at 11:51:17AM -0800, Jon Callas wrote:

> I'm happy to put in SHA-224 (meaning it's trivial work), but I don't  
> like it, myself. The reason is that SHA-224 is really a truncated  
> SHA-256. Thus, it has no advantages over SHA-256 except being smaller  
> by 32-bits with 112 bits of security. The reason it exists at all is  
> for crypto-balance with 2-key 3DES (which is not TDEA), which we  
> don't allow at all. I don't think we should have it as it goes  
> against our principles of wanting a minimum of 128-bits of security  
> in OpenPGP. (Yes, yes, I know that SHA-1 doesn't meet this either,  
> but until SHA-256, we didn't have many options. That doesn't mean the  
> principle is wrong; we *have* options.)

I understand the argument about wanting 128 bits of security, but
since the new DSA allows a 224 bit q, there just isn't room for 128
bits of security.  Whether we truncate SHA-256 and call it "truncated
SHA-256" or truncate SHA-256 and call it "SHA-224", we have to
truncate.

We support DSA now, with a note saying that if someone wants DSS, they
need to use SHA-1.  I suspect we'll end up in a similar place with
DSA2 allowing whatever key size and q size that people want to use and
a note that if they want DSS they need to use one of the four
NIST-blessed key size / q size pairs.

I lean towards adding SHA-224 as one of those four pairs has a 224-bit
q, and NIST suggests SHA-224 for this size.  It's only a lean towards
adding it as NIST also suggests truncated 256, 384, or 512 as valid
options, so 224 is not the only game in town.  (384 seems a little
silly as it would be a truncation of a truncation, but it's an
option.)  It's really a feeling that we currently support 4 out of the
5 FIPS-approved hash functions (SHA-1, 256, 384, 512), and since
supporting the 5th (224) is so trivial, we may as well be complete.

I'll defer to someone who feels more strongly about this than I do.

David