Re: NIST publishes new DSA draft

Ben Laurie <> Wed, 15 March 2006 14:43 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1FJXDs-0005j3-Te for; Wed, 15 Mar 2006 09:43:36 -0500
Received: from ([]) by with esmtp (Exim 4.43) id 1FJXDr-0003Fa-Fv for; Wed, 15 Mar 2006 09:43:36 -0500
Received: from (localhost []) by (8.13.5/8.13.5) with ESMTP id k2FEK3NV051322; Wed, 15 Mar 2006 07:20:03 -0700 (MST) (envelope-from
Received: (from majordom@localhost) by (8.13.5/8.13.5/Submit) id k2FEK3Tc051321; Wed, 15 Mar 2006 07:20:03 -0700 (MST) (envelope-from
X-Authentication-Warning: majordom set sender to using -f
Received: from ( []) by (8.13.5/8.13.5) with ESMTP id k2FEK1Dv051314 for <>; Wed, 15 Mar 2006 07:20:02 -0700 (MST) (envelope-from
Received: from [] (localhost []) by (Postfix) with ESMTP id F2ED333C1C; Wed, 15 Mar 2006 14:20:00 +0000 (GMT)
Message-ID: <>
Date: Wed, 15 Mar 2006 14:20:09 +0000
From: Ben Laurie <>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Hal Finney <>
Subject: Re: NIST publishes new DSA draft
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Precedence: bulk
List-Archive: <>
List-Unsubscribe: <>
List-ID: <>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5

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.




"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