force-v4-certs and digest-algo

[Brian M. Carlson]

On Thu, May 09, 2002 at 02:44:43PM -0700, Len Sassaman wrote:
> 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).

While this may be true, it is a de facto SHOULD, just like IDEA is.
 
> 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.

The last time I used my DSA key, other than to update its expiration date,
was over a year ago. I use my RSA key almost exclusively. When I don't, I
use my ElGamal type 20 key. (I know how you feel about ElGamal 20 keys ;-)
There is no reason that DSA couldn't use any other 160 bit hash. Nevertheless,
I *do* use SHA1 with DSA.

> 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:
<snip>

I am quite aware of the requirements for a collision-resistant hash function.
I own Applied Cryptography and have read it several times. I have also read
other works on the subject, including the definition of RIPEMD160.

-- 
Brian M. Carlson
<karlsson at hal-pc.org>
OpenPGP: 0x351336B2DCA1913A
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 528 bytes
Desc: not available
Url : /pipermail/attachments/20020510/b59c31f9/attachment.bin