Ulf Möller wrote:
The security notes still don't mention that there is a cryptographic
flaw in v4 signatures. This needs to be fixed, or if there are good
reasons for not fixing it, it must at least be explained in the
document.
The problem is that we currently allow a choice of hash algorithms with
DSA signatures. Because there is no room in the DSA inputs to specify
the hash algorithm, it is possible to do a hash substitution attack.
This is why the DSS specifies that the hash must be SHA-1.
We allow other hashes with a size of 160 bits, as described in section
5.2.2:
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.
The only other hashes listed in RFC 2440 which have this size are
RIPEMD-160 and HAVAL. These are thought to be strong hashes, like SHA-1,
hence there is no actual cryptographic weakness in RFC-2440.
This issue is discussed in section 13, Security Considerations:
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. These same considerations about the quality of the hash
algorithm apply to Elgamal signatures.
In my opinion this does address the issue raised above.
Hal