Suggested changes for DSA2, take 2

David Shaw <dshaw@jabberwocky.com> Sun, 26 March 2006 16:47 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNYOv-0000yp-0k for openpgp-archive@lists.ietf.org; Sun, 26 Mar 2006 11:47:37 -0500
Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FNYOu-00074p-Jb for openpgp-archive@lists.ietf.org; Sun, 26 Mar 2006 11:47:37 -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 k2QGNnln032358; Sun, 26 Mar 2006 09:23:49 -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 k2QGNn1j032357; Sun, 26 Mar 2006 09:23:49 -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 k2QGNnQF032351 for <ietf-openpgp@imc.org>; Sun, 26 Mar 2006 09:23:49 -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 k2QGNlk12030 for <ietf-openpgp@imc.org>; Sun, 26 Mar 2006 11:23:47 -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 k2QGNi9P019499 for <ietf-openpgp@imc.org>; Sun, 26 Mar 2006 11:23:44 -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 k2QGNfxK022185 for <ietf-openpgp@imc.org>; Sun, 26 Mar 2006 11:23:41 -0500
Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id k2QGNfch022184 for ietf-openpgp@imc.org; Sun, 26 Mar 2006 11:23:41 -0500
Date: Sun, 26 Mar 2006 11:23:41 -0500
From: David Shaw <dshaw@jabberwocky.com>
To: ietf-openpgp@imc.org
Subject: Suggested changes for DSA2, take 2
Message-ID: <20060326162341.GE30637@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: f66b12316365a3fe519e75911daf28a8

Here is some revised suggested DSA2 language, taking Hal's comments
into account and adding some extra polish.  While I agree with his
suggestion to reorganize the signature sections, I'm reluctant to get
into that in this mail as I think that getting general consensus on
DSA2 language would be easier if the two weren't combined.  I'd be
happy to take it up separately though.

==================================

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 to or larger than
    the size of q, the group generated by the DSA key's generator
    value.  If the chosen hash is larger than the size of q, the hash
    result is truncated to fit by taking a number of leftmost bits
    equal to the number of bits in q.  This (possibly truncated) hash
    function result is treated as a number and used directly in the
    DSA signature algorithm.

==================================

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
    be an even multiple of 64 bits long.  The Digital Signature
    Standard (DSS) 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

    Implementations SHOULD use one of the above key and q size pairs
    when generating DSA keys.  For full DSS compliance, one of the
    specified SHA hashes must be used as well.

    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.

The intent here is to say we really want you to use these p/q sizes,
and if you want to be DSS-compliant, you need to use these hashes too.
I removed the bit about how other key sizes, q sizes, and hashes were
legal as it really just restates the same thing again.

==================================

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.  An implementation should
       take care which hash algorithms are used with DSA.  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.

==================================

David