[PATCH] MD2 for libgcrypt

[Daniel Kahn Gillmor]

On 07/20/2010 11:54 AM, Jeff Johnson wrote:
> 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.

so, if we can avoid legal encumbrances, and given that we already
support extremely weak digests like CRC32, why not merge in MD2, given
that there is obvious demand for it (the "clockwork")?

If the answer is "no, we will never have MD2 in gcrypt, ever", then that
should be documented as well.  The current docs look like it's just not
implemented yet.

> 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.

I wasn't aware that RPM actually offered a crypto primitive library.  if
that library also includes ciphers and asymmetric crypto, all under a
reasonable license, i'd consider it very attractive indeed.

Is this in librpm or something?

> 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.

I don't understand this remark, sorry.  I don't have a "collect them
all" mentality about algorithms.  But i would expect a suite of
cryptographic primitives to want to provide reasonable coverage of
commonly requested algorithms.  If we were interested in only providing
the most secure algorithms, we'd have dropped MD5 and maybe even SHA1 by
now.  That wouldn't make for a very useful crypto library, and people
would not want to use it.

I'm *not* arguing for accepting non-root certificates made over MD2
digesets at higher layers than gcrypt.  I'm just arguing for reasonable
inclusion of commonly requested algorithms in a toolkit of those algorithms.

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

The Monkeysphere project treats X.509 certificates as basically
meaningless packaging around RSA public key material, and looks up
certifications over the same key material in the OpenPGP web of trust
instead.  While OpenPGP has its problems, it resolves some of the major
problems of X.509.  In particular, it resolves X.509's requirement of a
single-certifier, which i think is at the root of much of the
institutionalized insecurity.

We're probably getting OT for this list -- if you want to discuss ideas
like this about how to move forward, i invite you to join the
monkeysphere mailing list and IRC channel.  Details can be found at:

  http://web.monkeysphere.info/community

Thanks for the discussion,

	--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/2b58f89f/attachment.pgp>