[pycrypto] the sad state of pycrypto

[Paul Hoffman]

On Sun, Nov 9, 2008 at 8:31 AM, Dwayne C. Litzenberger <dlitz at dlitz.net> wrote:
> Really?  Many developers still use MD5 in new applications.

MD5 is still perfectly usable in applications that do not rely on the
collision resistance and only need 128 bits of preimage resistance.
For example, HMAC-MD5 has been proven to be secure even is the
collision resistance is near zero. A hashed signature algorithm can
use MD5 with no problems.

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

If someone knows enough about MD5 to know that it is faster than
SHA-1, or that it is more portable than SHA-1, knows about its
properties enough to use it.

If you really want the library to be in nanny mode, simply rename the
function from "MD5" to something like "idontwantyoutouseMD5". This is
a serious suggestion. Self-documenting function names are surprisingly
useful.

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

That is not my line of reasoning. RandomPool was unsafe at any speed.
MD5 is safe for many purposes.

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

Some pedants would not slice and dice it that way.

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

I see nothing in the current version of the Wikipedia page that says
that, and I have never heard of any such encumbrances. If there were,
the NSA would be amazingly remiss in filing an IPR statement with the
IETF for the family as a whole but not those members.

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

I am not a proponent of either function, but I can channel those who
are. SHA-224 is designed to have "matched impedance" with TripleDES,
which has 112 bits of strength. Similarly, SHA-384 is matched to
AES-196. I find the impedance idea goofy, but some folks like it.