Re: NIST publishes new DSA draft

[[e-mail] ("Hal Finney")]

David Shaw writes:
> In the OpenPGP context, probably the most interesting bit is that the
> 160-bit hash limit has been removed.  The sizes supported are:
>
> * 1024-bit key, 160-bit hash (the current DSA)
> * 2048-bit key, 224-bit hash (presumably aimed at SHA-224)
> * 2048-bit key, 256-bit hash (presumably aimed at SHA-256)
> * 3072-bit key, 256-bit hash (presumably aimed at SHA-256)
>
> It also adds the concept of using a larger hash than will fit by
> taking the leftmost bits.

The main question is whether we want to change the current draft to make
these changes.  That would probably require backing it out of "last
call" status.  Personally I think this makes sense.  There is no one
waiting urgently for this draft to be finalized AFAIK.  The alternative
will be to immediately amend the RFC with another RFC.  But for the sake
of future implementors I think it would be better to wait a few months
more and put it all into one draft.

In two places in RFC2440-bis, we mention that DSA signatures must use
a 160 bit hash.  The main one is in section 5.2.2, Version 3 Signature
Packet Format.  This is not a good location as it is not information
that is specific to V3 signature packets.  It applies to V4 signatures
as well.  This information should probably be in 5.5.2 on public key
packet formats, or at least should be repeated in 5.2.3 for V4 sigs.

It is also mentioned in section 13, Security Considerations, where we
state explicitly that RIPEMD-160 can be used, but that "DSS" as compared
to "DSA" requires SHA-1.

One of the implications of the changes in the new draft is that 1024 bit
DSA keys can use SHA-256 (truncated to 160 bits).  We should probably
allow that as an alternative to SHA-1, although it raises backwards
compatibility issues.

For 2048 bit keys they allow either 224 or 256 bit hashes.  This also
means allowing a subgroup "q" size of either 224 or 256 bits, I think.
The hash then must either match "q" or be larger, in which case it is
left-truncated.

We do not have an algorithm ID for SHA-224.  SHA-224 is the same
algorithm as SHA-256 but uses different initial values internally,
and then truncates the result to 224 bits.  I don't see any advantage
in this case to using SHA-224 over using SHA-256 truncated to 224 bits.
However we might want to add an ID for it in case an implementor wanted
to follow the new DSS spec very closely.

The simplest change we could make would be to allow that DSA keys can
use modulus "p" and subgroup "q" values of the specified sizes, based
on the table above.  Hashes should be equal in size or larger than the
"q" size.  Hashes larger than the "q" size should be left-truncated.
Then we could note that for DSS compliance the hashes must be taken from
the SHA family, either SHA-1 or one of the larger SHA's.

We might want to think about making SHA-256 be another MUST algorithm.
The only MUST hash now is SHA-1.  Making SHA-256 be a MUST would make
these new key sizes be more useful, and also give us an easier fallback
if SHA-1 should be broken.

I also think we should change the names of SHA256 etc to use dashes
as in SHA-256; those are the official names.

Hal Finney