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

[Legrandin]

I think it is worth making a distinction between primitives and protocols.

The few ciphers/hashes that currently exist in pycrypto suffice for
most needs one may have, and
I agree that adding more won't help in 99% of the applications (even
though it may look good
on a fact sheet) whereas a low-level cipher zoo is hard to maintain.

Having said that, one of beauties of pycrypto is the fact that is
self-contained and does not require
to be combined with further packages. A pluggable system - although
elegant - would become
less practical and possibly not very considered as a feature. If one
day one could prove that pycrypto is
indeed missing a primitive used by some real, widespread systems
(maybe ECC?) that cannot be sanely
replaced by AES/TDES/SHA, I would even urge to still have a C
implementation included from some
good patent-free library (e.g. tomcrypt) and shipped. So much time saved...

Protocols are another beast though: key derivation/management/exchange
schemes, wrappers,
message authentication codes, etc etc are in most cases independent of
the underlying cipher/hash
primitive and can be more cleanly and quickly implemented/tested in a
high-level language like Python
with little performance penalty. PKCS#1 and PBKDF2 are good examples.
Even chaining modes
for block ciphers look better in python (to me at least).I would
really prefer to have these high-level
algorithms available in the library and not through some obscure
openssl-like library coded in C...

My 2 cents... :-)

> 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