[PATCH] MD2 for libgcrypt

Stephan Mueller smueller at chronox.de
Tue Jul 20 07:21:33 CEST 2010


Am Montag 19 Juli 2010, um 21:11:23 schrieb Daniel Kahn Gillmor:
> On 07/19/2010 02:15 PM, Stephan Mueller wrote:
> > Both, there is the root cert (and I concur with your assessment), but
> > there are also intermediate certs with MD2 too.
> 
> intermediate certs using MD2 should themselves be considered broken, as
> certifications from root CAs over MD2 are susceptible to a preimage attack:
> 
>   http://en.wikipedia.org/wiki/MD2_%28cryptography%29#Security
> 
> It would be a bad thing to accept intermediate certificates over the
> network that were certified with MD2.
> 
> If you're talking about shipping certs of known intermediate authorities
> as part of a package of trusted authorities, then those are actually
> equivalent to root authorities, not intermediate authorities (even if
> their own certs are not self-signed).

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.

I personally made the effort to integrate MD2 to switch back to my favorite 
MUA which happens to use gpgsm. But still, I have to be able to handle 
certificates signed with Verisign's CA.

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?
> 
> > Well, Werner already told me that he is not integrating the patches.
> > However, as the patches only enable the signature verification of an
> > already existing signature, I cannot fully understand the decision.
> 
> Are the patches rejected due to poor implementation?  due to licensing
> reasons?  or due to a desire to not ship the MD2 functionality in
> libgcrypt?  or due to some other reason?
> 
> sorry for having to ask, but i never saw a response on the list, so i'm
> in the dark.

He did not say, but I guess it is because of the poor reputation of MD2. 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.

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.

Ciao
Stephan
> 
> 	--dkg




More information about the Gcrypt-devel mailing list