[pycrypto] the sad state of pycrypto
Dwayne C. Litzenberger
dlitz at dlitz.net
Sun Nov 9 10:31:40 CST 2008
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
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
>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
>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 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
Size: 197 bytes
Desc: Digital signature
Url : http://lists.dlitz.net/pipermail/pycrypto/attachments/20081109/270515a1/attachment.pgp
More information about the pycrypto