[pycrypto] the sad state of pycrypto

[Paul Hoffman]

Small notes.

On Sun, Nov 9, 2008 at 7:34 AM, Dwayne C. Litzenberger <dlitz at dlitz.net> wrote:
> Yeah, it's a nice architecture.  Unfortunately, it also requires that
> algorithms be hand-written in (error-prone) C, so I want to keep the amount
> of C code in PyCrypto to a minimum.

That seems like a good choice. Those of us who want crypto code that
comes from C have many other ways of getting it.

> My thoughts mirror the ideas presented in D. J. Bernstein's paper, "Some
> thoughts on security after ten years of qmail 1.0"
> <http://cr.yp.to/qmail/qmailsec-20071101.pdf>.  I encourage everyone here to
> read it, if you have not already.

A strong "me too" on having everyone read that paper.

> Which algorithms are you referring to?  Just MD2?  I'm willing to drop MD2
> if there are no objections.  I'm not going to be removing MD5 or SHA-1 any
> time soon; They're just wrappers around the Python standard library anyway.

The idea of dropping support for "weak" algorithms is silly. No
developer looks through the list of algorithms in a library and say
"I'll pick, um, er, that one" without knowing what it is. There is no
security problem with a library having weak algorithms, only with
clueless people using them without understanding the consequences.
Old, weak hash algorithms are still needed for validating old
signatures and certificates.

>> With respect to the recommendations of the NIST and others I propose to
>> offer the following algorithm additionally and directly over the distributed
>> library interface: SHA-224, SHA-256 (C file is allready included), SHA-384,
>> SHA-512, RIPEMD-128, RIPEMD-160, RIPEMD-256, RIPEMD-320, Tiger and
>> WHIRLPOOL.

Just a note on that sentence: NIST only recommends the members of the
SHA family; all the rest are recommended by "and others".

> My understanding is that SHA-224 and SHA-384 are encumbered by software
> patents

The entire SHA-2 family is encumbered by a patent (US 6,829,355) that
is licensed royalty-free (see
<https://datatracker.ietf.org/ipr/858/>). It applies to SHA-256 and
SHA-512 as well.

> and provide no performance advantages over SHA-256 and SHA-512,
> respectively.

Quite true.