[PATCH] MD2 for libgcrypt

[Jeff Johnson]

On Jul 20, 2010, at 11:15 AM, Daniel Kahn Gillmor wrote:

> On 07/20/2010 03:11 AM, Werner Koch wrote:
>> For one the legal state of the algorithm is not clear: It is likely that
>> it has been taken from the RFC which has a non-commercial clause.  In
>> this regard it is similar to arcfour.  The GNU project is very
>> cautiousness on these issues and thus we would need to clear the legal
>> state first (meaning long dicussions with RSA Inc).  I don't think this
>> is justified.  And of course we need a copyright assignment and code
>> which is clearly not based on rfc 1319.
> 
> Maybe the docs could indicate this somehow?  currently the manual [0]
> only says:
> 
> GCRY_MD_MD2
>    This is an reserved identifier for MD-2; there is no implementation
> yet. This algorithm has severe weaknesses and should not be used.
> 
> an additional concise note about the specific legal encumbrances you're
> worried about might save other implementors time in the future (and
> might lead to a resolution of those legal concerns).
> 

Documenting doesn't resolve the issue. As already reported, RFE for
MD2 -> libgcrypt comes along regular as clockwork every few years 
with sound reasons supporting every possible POV.

>> The other reasons is that I don't want to keep those old certificates
>> alive.
> 
> I agree with you here.  but that's not an argument for not including MD2
> in libgcrypt.  libgcrypt provides cryptographic primitives, not X.509
> business.  the more crypto primitives it can offer, the more attractive
> it is as a library.
> 

Well I can give you the counter example that proves the rule that
	more primitives != more attractive.

RPM includes >100 hashes, with test vectors, for all possible NIST SHA3
selections. That doesn't make RPM any more attractive than any other
crypto library.

Hint: Try baseball card collecting instead. Unlike crypto hashes,
you get to shuffle or sell the collection whenever you wish, and
baseball cards come with pictures and batting averages that are
easier to reason with than "secure" metrics.

>> A counterpoint would be that the whole X.509 PKI business is entirely
>> broken and does not provide any security at all.
> 
> agreed, sadly.
> 

Also agreed. But X.509 is most definitely something that cannot be just ignored.

On a more optimistic forward looking note:
	What is the better answer if X.509 is sadly pathetic?

73 de Jeff