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
|