[PYTHON-CRYPTO] Near-term projects for pycrypto

[Andrew Kuchling]

Here are some things I'd like to do with the pycrypto code.
Reactions?

1) Break backward compatibility.  The interfaces were invented around
1995, back when I was younger and dumber.  I'd like to clean them up,
cruelly breaking backward compatibility where necessary, and release
the new code as version 2.0 to signal the magnitude of the changes.
While we have the chance, we can also drop useless code, rename
packages and classes, or whatever.

2) Is there any point in keeping the implementations of MD5 and SHA if
Python comes with them?  We could just change Crypto/Hash/MD5.py to
just 'from md5 import *', and ditto for Crypto/Hash/SHA.py.

3) Get rid of the clumsily generated source files and just keep
everything straightforward.  For hash modules, this would be
straightforward.  However, I don't know how to fix block encryption
modules properly.  The original purpose of autogenerating everything
was to re-use the tricky and error-prone code for the various feedback
modes, while hopefully avoiding the overhead of doing a C function
call on every block.

Maybe the C function overhead isn't worth saving.  If so, then perhaps
we could write a single C file that implemented the feedback modes as
a library.  Individual encryption modules would then define a function
to encrypt a single block, another for decrypting a single block, and
then pass these functions to the code in the library.  (We'd have to
finalize a block encryption API to do that, hopefully defining it in
the Block Encryption PEP at the same time.)

4) Remove the export/not-for-export cruft.

5) Modernize the code to current standards (Distutils installation,
docstrings, naming conventions).  We might rename the package from
'Crypto' to 'crypto', or some other name.

6) Discard some of the more obscure algorithms (HAVAL, Diamond,
Skipjack, maybe CAST, RC5 and IDEA, too) and add AES, adopting the
principle of well-tested and commonly used algorithms, not every
single one that gets invented.

7) Public-key stuff: should it remain in this package, or should it be
scrapped and the scope restricted to hashing and block encryption?
Public-key is much harder to define and implement, so I think
splitting it out into a separate distribution is the right thing to
do.

--amk