[PATCH] MD2 for libgcrypt

[Daniel Kahn Gillmor]

On 07/20/2010 01:21 AM, Stephan Mueller wrote:
> I am totally on your side. I dislike MD2 as anybody else. But I am also a 
> realist. Verisign certs are pervasive. So, we have to live with it.

if "live with it" means accepting arbitrary certifications over MD2
digests, i really think this is not acceptable.  Please don't advocate
for this.

if "live with it" means shipping full copies of a set of well-known,
widely-used verisign intermediate CA certs as root authorities, then i
don't think it's significantly worse than shipping verisign's canonical
root ca cert in the first place.  (which is not to say i advocate
relying on certifications made by Verisign).

> Of course, it would be possible to simply import the user's certs, verify them 
> manually and add the fingerprint to gpgsm's trustlist.txt manually. But 
> really, which normal user is really able to do that? Besides, wouldn't such an 
> approach defy the SMIME key management approach?

i don't know what the SMIME key management approach is.

> He did not say,

Werner, would you care to comment on-list?  Maybe if the reason for your
rejection was public, Stephan (or someone else) would modify the patch
to address it.

>  but I guess it is because of the poor reputation of MD2. 

If we're talking about gcrypt (this is the gcrypt-devel list, so i
assume we are), that wouldn't make much sense, given that there are
extremely weak digests like CRC32 included in libgcrypt.

accepting certifications over MD2 in security-sensitive libraries like
gnutls and gnupg is another matter, of course.  But as a library of
crypto-primitives that implements a range of digest functions, having an
MD2 implementation doesn't seem unreasonable.

> I 
> would have no problems when MD2 in general is somehow not fully exported via 
> the libgcrypt API for general use. All I need and all I want is MD2 for using 
> it with gpgsm for verification of existing certificates.

I would resist this on the grounds that assertions backed only by an MD2
digest are computationally suspect.  They're just too easy to
forge/replay.  Would you advocate accepting certificates made over a
CRC32 digest?  If so, why bother with certificates in the first place?

> Just in case someone asks: the entire MD2 implementation is derived straight 
> from NSS. That is why the functions MD2_* and md2_compress have a different 
> indentation style than the rest of libgcrypt. I deliberately did not change 
> that to keep a one-to-one copy from NSS. libgcrypt-specific additions are 
> clearly visible at the end of the C file and the massaging of the other 
> function's input parameters.

Given this background (and the probably-low likelihood that the NSS
authors are willing to assign copyright to the FSF), i wonder if
Werner's concerns are licensing concerns.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 892 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20100720/883a25a5/attachment.pgp>