Subject: Suggested changes for DSA2, take 4

From: David Shaw <[email-masked]>
Date: Wed, 29 Mar 2006 11:37:56 -0500

Here is round four.  Only little fiddle changes at this point.

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

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.

No change.

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

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 a multiple of 64 bits, and the q size MUST be a multiple
    of 8 bits.  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 MUST that the q size is a multiple of 8.  I don't think any of
us want to deal with hashes that don't end on a byte boundary.

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

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.

Also add:

     * As OpenPGP combines many different asymmetric, symmetric, and
       hash algorithms, each with different measures of strength, care
       should be taken that the weakest element of an OpenPGP message
       is still sufficiently strong for the purpose at hand.  While
       consensus about the the strength of a given algorithm may
       evolve, at publication time, NIST Special Publication 800-57
       [SP800-57] recommended the following list of equivalent
       strengths:

       Asymmetric  |  Hash  |  Symmetric
       key size    |  size  |  key size
       ------------+--------+-----------
          1024        160         80
	  2048        224        112
	  3072        256        128
	  7680        384        192
	 15360        512        256

Added the key size reminder.

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

David

---

From: Ben Laurie <[email-masked]>
Date: Wed, 29 Mar 2006 18:28:57 +0100

> Here is round four.  Only little fiddle changes at this point.

Slightly late to the party here, but I should note that hash truncation
is not an operation that is thoroughly approved of. In particular I
would worry that if it is permitted a cunning attacker might be able to
choose a new q s.t. the signature still validated on a much shorter
version of the hash, and thus show a valid signature on the wrong
document. I would therefore suggest that we do _not_ permit arbitrary
truncation of hashes.

Secondly, q is not a group, it is a prime.

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