Re: NIST publishes new DSA draft

[Ben Laurie <ben@xxxxxxxxxxxxx>]

Hal Finney wrote:
> 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.

I'm in favour of making these changes now rather than waiting for the
next version.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff