[pycrypto] Library design philosophy
Dwayne C. Litzenberger
dlitz at dlitz.net
Mon Apr 13 22:14:43 CST 2009
On Mon, Apr 13, 2009 at 02:54:42PM +0200, Legrandin wrote:
>> Well ... you can have your opinion if I (a random user) can have mine ;-)
>I was just throwing my stone into the water... :-)
It's good to see this mailing list buzzing. :-)
>> Some advantages of pycrypto are that it is small, has a simple pythonic
>> API, and don't have any external dependencies. It is not a incomplete
>> wrapper of a huge and complex API (such as the openssl API).
>Agreed, even though it is not clear to me whether you refer to any
>existing wrapper. M2crypto seems pretty good for instance.
M2crypto's API is neither simple nor Pythonic, and it depends on OpenSSL.
OpenSSL's license is, if I remember correctly, incompatible with the GPL
thanks to its advertising clause.
>> Pure python implementations _could_ be added, but they would probably
>> not really be usable. Users getting this slow fallback would probably be
>> annoyed or complain about the performance instead of fixing the problem
>> by installing the right compiled version.
>I saw several times remarks to urge "normal" users not to use pycryto directly
>(e.g. RSA schoolbook encryption), but to rely on savier, higher-level code.
>From that I infer that pycrypto targets "advanced" users, the kind that already
>knows how to deal with performance trade-offs, and do not need to be patronized.
People who build and install PyCrypto (packagers, vendors, Gentoo users...)
do not necessarily understand cryptography.
>Note that we should also define what "too slow" means, 2x? 20x? 50x? What
>would be an acceptable slow-down, provided that we know that by the time
>performance has become a problem, the *advanced* user would have already
>switched to an optimized library/wrapper?
"Too slow" means slow enough to seriously impact software that uses
PyCrypto to do *bulk* encryption/hashing, such as:
- Paramiko (SSH/SFTP implementation) - http://www.lag.net/paramiko/
- Twisted Conch (SSH/SFTP implementation) -
- BitTornado - http://www.bittornado.com/
- DebTorrent - http://debtorrent.alioth.debian.org/
- bzr (via Paramiko) - http://bazaar-vcs.org/
- Launchpad.net (via bzr) - http://launchpad.net/
- sshproxy (via Paramiko) - http://sshproxy-project.org/
- releaseforge (via Paramiko) - http://releaseforge.sourceforge.net/
- Zope3 (via Twisted Conch) - http://www.zope.org/
- gecrypt - http://www.dlitz.net/software/gecrypt/
- PySFTPd (via Paramiko) - http://www.dlitz.net/software/pysftpd/
- python-pbkdf2 - http://www.dlitz.net/software/python-pbkdf2/
"Too slow" also means slow enough to cause users to choose weaker
algorithms or security parameters. For example, if users routinely choose
1024-bit RSA keys (or SHA1/MD5 hashes) over strong alternatives for
performance reasons, then the library they're using is too slow.
>> (Note: I don't understand your comments about being scriptable and a
>> command-line crypto workbench. That seems to be features related to
>> using Python, independent of which crypto library you use.)
>I don't use often pycrpto for full-blown applications. Instead, I make several
>small proof-of-concepts prototypes that help in setting up the final (C-based!)
>crypto module of the real application.
PyCrypto still has lots of room for improvement, but people can and do
already use it in real applications. I would love to reduce the amount of
C code in PyCrypto (especially where it's ugly and/or
ambiguously-licensed), but I don't see the build-dependency on a C compiler
going away any time soon.
Dwayne C. Litzenberger <dlitz at dlitz.net>
Key-signing key - 19E1 1FE8 B3CF F273 ED17 4A24 928C EC13 39C2 5CF7
More information about the pycrypto