[pycrypto] Library design philosophy

[Dwayne C. Litzenberger]

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) -
         http://twistedmatrix.com/trac/wiki/TwistedConch
     - 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/
     </shameless-plugs>

"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