[PATCH] MD2 for libgcrypt

[Stephan Mueller]

Am Dienstag 20 Juli 2010, um 07:53:14 schrieb 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.

I meant to say that we have to live with Verisign CA certificates as we cannot 
change them. But I would not want to suggest using MD2 for anything else.
> 
> 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).

Sounds good.

I just rechecked all the Verisign certs: what I said initially was not 
correct. Only some of the root CA certificates, but no intermediate CA 
certificate rely on MD2. The intemediate certificates use SHA1, MD5.
> 
> > 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.

You rely on the CA for establishing trust into the certificates you obtain 
from other (potentically unknown) users.
> 
> > 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?

Considering CRC32 which is generally available, I would then also not suggest 
treating MD2 special just because it happens to be weak.
> 
> > 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.

Is it necessary that the rights have to go to FSF? There is only one 
additional file that has a special copyright. A lot of open source projects 
have different licensing terms for different parts.

The code is (L)GPL2 as outlined in the header of the file which again is taken 
verbatim from NSS.

Ciao
Stephan
> 
> 	--dkg



Ciao
Stephan