[PATCH] MD2 for libgcrypt
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Tue Jul 20 07:53:14 CEST 2010
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
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.
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 892 bytes
Desc: OpenPGP digital signature
More information about the Gcrypt-devel