Suggested changes for DSA2, take 3
David Shaw <dshaw@jabberwocky.com> Mon, 27 March 2006 15:58 UTC
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNu6e-0001Xi-EX for openpgp-archive@lists.ietf.org; Mon, 27 Mar 2006 10:58:12 -0500
Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNu6e-0004MT-13 for openpgp-archive@lists.ietf.org; Mon, 27 Mar 2006 10:58:12 -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 k2RFVPqc093064; Mon, 27 Mar 2006 08:31:25 -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 k2RFVP8N093063; Mon, 27 Mar 2006 08:31:25 -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 foobar.cs.jhu.edu (foobar.cs.jhu.edu [128.220.13.173]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k2RFVO6D093057 for <ietf-openpgp@imc.org>; Mon, 27 Mar 2006 08:31:24 -0700 (MST) (envelope-from dshaw@jabberwocky.com)
Received: from walrus.hsd1.ma.comcast.net (walrus.hsd1.ma.comcast.net [24.60.132.70]) by foobar.cs.jhu.edu (8.11.6/8.11.6) with ESMTP id k2RFVNk17528 for <ietf-openpgp@imc.org>; Mon, 27 Mar 2006 10:31:23 -0500
Received: from grover.jabberwocky.com ([172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.13.6/8.13.5) with ESMTP id k2RFVOF8014146 for <ietf-openpgp@imc.org>; Mon, 27 Mar 2006 10:31:24 -0500
Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id k2RFVHoU025589 for <ietf-openpgp@imc.org>; Mon, 27 Mar 2006 10:31:17 -0500
Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id k2RFVHIx025588 for ietf-openpgp@imc.org; Mon, 27 Mar 2006 10:31:17 -0500
Date: Mon, 27 Mar 2006 10:31:17 -0500
From: David Shaw <dshaw@jabberwocky.com>
To: ietf-openpgp@imc.org
Subject: Suggested changes for DSA2, take 3
Message-ID: <20060327153117.GA25534@jabberwocky.com>
Mail-Followup-To: ietf-openpgp@imc.org
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
User-Agent: Mutt/1.5.11
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: a2c12dacc0736f14d6b540e805505a86
Here is round three with suggested changes from Hal and Ben. ================================== Section 5.2.2 (Version 3 Signature Packet Format) says: DSA signatures MUST use hashes with a size of 160 bits, to match q, the size of the group generated by the DSA key's generator value. The hash function result is treated as a 160 bit number and used directly in the DSA signature algorithm. change to: DSA signatures MUST use hashes that are equal in size to the number of bits of q, the group generated by the DSA key's generator value. If the output size of the chosen hash is larger than the number of bits of q, the hash result is truncated to fit by taking the number of leftmost bits equal to the number of bits of q. This (possibly truncated) hash function result is treated as a number and used directly in the DSA signature algorithm. Changes from both Hal and Ben. ================================== Section 12.5. (DSA) says: An implementation SHOULD NOT implement DSA keys of size less than 1024 bits. Note that present DSA is limited to a maximum of 1024 bit keys, which are recommended for long-term use. Also, DSA keys MUST be an even multiple of 64 bits long. change to: An implementation SHOULD NOT implement DSA keys of size less than 1024 bits or with a q size of less than 160 bits. DSA keys MUST also be an even multiple of 64 bits long. The Digital Signature Standard (DSS) [FIPS186] specifies that DSA be used in one of the following ways: * 1024-bit key, 160-bit q, SHA-1, SHA-224, SHA-256, SHA-384 or SHA-512 hash * 2048-bit key, 224-bit q, SHA-224, SHA-256, SHA-384 or SHA-512 hash * 2048-bit key, 256-bit q, SHA-256, SHA-384 or SHA-512 hash * 3072-bit key, 256-bit q, SHA-256, SHA-384 or SHA-512 hash The above key and q size pairs were chosen to best balance the strength of the key with the strength of the hash. Implementations SHOULD use one of the above key and q size pairs when generating DSA keys. If DSS compliance is desired, one of the specified SHA hashes must be used as well. [FIPS186] is the ultimate authority on DSS, and should be consulted for all questions of DSS compliance. Note that earlier versions of this standard only allowed a 160-bit q with no truncation allowed, so earlier implementations may not be able to handle signatures with a different q size or a truncated hash. Added a reminder why we really, really want people to use one of the four DSS p/q pairs, plus a change with regards to referring people to FIPS186 for the DSS spec. DSS has other requirements besides the four p/q sizes and list of SHA hashes, and the original language implied that using the right size and right hash was enough for DSS compliance. ================================== Section 13. (Security Considerations) says: * The DSA algorithm will work with any 160-bit hash, but it is sensitive to the quality of the hash algorithm, if the hash algorithm is broken, it can leak the secret key. The Digital Signature Standard (DSS) specifies that DSA be used with SHA-1. RIPEMD-160 is considered by many cryptographers to be as strong. An implementation should take care which hash algorithms are used with DSA, as a weak hash can not only allow a signature to be forged, but could leak the secret key. change to: * The DSA algorithm will work with any hash, but is sensitive to the quality of the hash algorithm. Verifiers should be aware that even if the signer used a strong hash, an attacker could have modified the signature to use a weak one. Only signatures using acceptably strong hash algorithms should be accepted as valid. Change from Hal. ================================== David
- Suggested changes for DSA2, take 3 David Shaw