[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