force-v4-certs and digest-algo

Len Sassaman rabbi at
Fri May 10 00:44:01 CEST 2002

On 9 May 2002, Robert J. Hansen wrote:

> Not necessarily.  The axiom which guides GnuPG is "be liberal in what
> you accept, but conservative in what you generate".  If I recall,
> RIPEMD-160 is a SHOULD, not a MUST.  It would be entirely consistent and
> RFC-conformant for GnuPG to accept RIPEMD-160 in traffic, but to only
> use SHA-1 for output.

First of all: RIPEMD-160 is neither a MUST or a SHOULD. (It's neither a
required, not suggested, algorithm in OpenPGP. Don't be surprised if
implementations do not support or understand RIPEMD-160 signatures).

Secondly, DSS is defined as requiring SHA-1. Consequently, SHA-1 has
received more attention than other 160-bit hash algorithms by
cryptographers. RIPEMD-160 is considered by many to be just as strong, but
it certainly hasn't received the same level of scrutiny.

Notice, also, that the security of PGP signatures is somewhat dependant
upon all of the hashes that the implementation allows. I draw your
attention to section 13 of RCF 2440bis05:

     * There is a somewhat-related potential security problem in
       signatures. If an attacker can find a message that hashes to the
       same hash with a different algorithm, a bogus signature
       structure can be constructed that evaluates correctly.

       For example, suppose Alice DSA signs message M using hash
       algorithm H. Suppose that Mallet finds a message M' that has the
       same hash value as M with H'. Mallet can then construct a
       signature block that verifies as Alice's signature of M' with
       H'. However, this would also constitute a weakness in either H
       or H' or both. Should this ever occur, a revision will have to
       be made to this document to revise the allowed hash algorithms.

So, if any of the hash algorithms are broken, we could be in quite a bit
of trouble. (This is my argument against adding in SHA-256, etc., until
there is a clear benefit (such as larger DSA keys) to doing so.)


More information about the Gnupg-devel mailing list