[pycrypto] On the future of new ciphers/hashes in PyCrypto

Dwayne C. Litzenberger dlitz at dlitz.net
Mon Aug 2 19:46:37 CST 2010

Hi folks!

Going through the bug tracker and the mailing list, a lot of the requests 
are to add new algorithms (Camellia, SHA512, TEA, PKCS#1/OAEP, PBKDF2), or 
to make changes to the existing implementations (timing attack 
countermeasures for the AES module, better prime generation for RSA).

They're all good ideas, but I don't have the time or the expertise needed 
to review C implementations of low-level crypto primitives, and frankly, I 
have better things to do.

Python does not need its own custom AES implementation.  Neither do Java, 
Ruby, Perl, JavaScript, PHP, Go, C++, D, Clojure, Haskell.  It's a waste of 
volunteer time, it's bad engineering, and it means that the FOSS community 
ends up repeating the same mistakes over and over, year after year, every 
time a new language comes out.

I'm putting a stop to it.  I'm declaring a permanent feature freeze on the 
C implementations of <Crypto.Cipher.*> and <Crypto.Hash.*>.  New algortihms   
will be added only by calling out to existing libraries.  PyCrypto 
development will be focused on the API.

I haven't yet figured out exactly how this is going to look.  I'm thinking 
of some kind of pluggable backends, sort of like how Java or CryptoAPI, but 
with as little API complexity as possible.  Ideas are welcome.

- Dwayne

Dwayne C. Litzenberger <dlitz at dlitz.net>
   OpenPGP: 19E1 1FE8 B3CF F273 ED17  4A24 928C EC13 39C2 5CF7

More information about the pycrypto mailing list