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