Re: NIST publishes new DSA draft

Ben Laurie <ben@algroup.co.uk> Wed, 15 March 2006 14:43 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJXDs-0005j3-Te for openpgp-archive@lists.ietf.org; Wed, 15 Mar 2006 09:43:36 -0500
Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJXDr-0003Fa-Fv for openpgp-archive@lists.ietf.org; Wed, 15 Mar 2006 09:43:36 -0500
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2FEK3NV051322; Wed, 15 Mar 2006 07:20:03 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k2FEK3Tc051321; Wed, 15 Mar 2006 07:20:03 -0700 (MST) (envelope-from owner-ietf-openpgp@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f
Received: from mail.links.org (mail.links.org [217.155.92.109]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2FEK1Dv051314 for <ietf-openpgp@imc.org>; Wed, 15 Mar 2006 07:20:02 -0700 (MST) (envelope-from ben@algroup.co.uk)
Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id F2ED333C1C; Wed, 15 Mar 2006 14:20:00 +0000 (GMT)
Message-ID: <44182299.2010507@algroup.co.uk>
Date: Wed, 15 Mar 2006 14:20:09 +0000
From: Ben Laurie <ben@algroup.co.uk>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Hal Finney <hal@finney.org>
CC: dshaw@jabberwocky.com, ietf-openpgp@imc.org
Subject: Re: NIST publishes new DSA draft
References: <20060314194447.4D59A57FB0@finney.org>
In-Reply-To: <20060314194447.4D59A57FB0@finney.org>
X-Enigmail-Version: 0.93.0.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-openpgp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:ietf-openpgp-request@imc.org?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>
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.

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