[pycrypto] the sad state of pycrypto

[Dwayne C. Litzenberger]

On Sun, Nov 09, 2008 at 07:54:22AM -0800, Paul Hoffman wrote:
>> 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.

Really?  Many developers still use MD5 in new applications.

Overly optimistic developers (or their micro-managing bosses) routinely 
make design choices favouring speed or portability over security, and it's 
the _users_ who suffer the consequences.  Following your line of reasoning, 
there was nothing wrong with RandomPool; It was simply being misused---by 
practically everyone.  I disagree, and RandomPool is now deprecated.

Many airplane crashes can be written off as "pilot error", but often there 
are other factors involved, and investigators owe it to the _passengers_ to 
discover those factors and take steps to avoid similar situations in the 
future.  The same thing applied to crypto libraries.

>Old, weak hash algorithms are still needed for validating old signatures 
>and certificates.

Agreed.  Even if the MD5 or SHA-1 libraries weren't wrappers around the 
Python standard library, I still would not remove them, since that would 
break nearly every program that uses PyCrypto, I would think.  Having said 
that, does anybody using PyCrypto actually need MD2, specifically?  Having 
less code makes PyCrypto more maintainable, and I'm not opposed to removing 
what is basically "dead code".

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

Thank you for clarifying that point.

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

If it's licensed to everyone on an automatic, royalty-free basis, then it's 
not _encumbered_ by a patent, just _covered_ by a patent.  Practically 
everything is covered by patents.  What I am concerned about is people 
actually getting sued (especially successfully) for patent infringement.

My understanding was that SHA-224 and SHA-384 had additional patent 
encumbrances that are did not apply to SHA-256 and SHA-512.  That 
understanding probably came from Wikipedia, and it may be incorrect.

In any case, SHA-224 and SHA-384 are just weakened versions of SHA-256 and 
SHA-512, so I'm not inclined to add them without good reason.

Thanks for the feedback,
  - Dwayne

-- 
Dwayne C. Litzenberger <dlitz at dlitz.net>
  Key-signing key   - 19E1 1FE8 B3CF F273 ED17  4A24 928C EC13 39C2 5CF7
  Annual key (2008) - 4B2A FD82 FC7D 9E38 38D9  179F 1C11 B877 E780 4B45
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.dlitz.net/pipermail/pycrypto/attachments/20081109/270515a1/attachment.pgp