[PYTHON-CRYPTO] Near-term projects for pycrypto
Paul Rubin
phr-pycrypt at nightsong.com
Tue Nov 20 03:56:33 CET 2001
Here are some things I'd like to do with the pycrypto code.
Reactions?
How about saying what the goals of pycrypto are, before going into
specific changes? But I'll react based on the idea that it's a
general purpose crypto lib.
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.
This depends on how many people are using the old version. If many, then
preserve compatibility. I'm not using the old version so I don't care :).
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.
If the pycrypto implementations are better (e.g., faster), then keep them.
Otherwise drop them.
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.
Unless there's a specific reason to supports weird feedback modes, drop them.
Support CBC mode, resumably and with PKCS5 padding.
4) Remove the export/not-for-export cruft.
If you're outside the US, sure. If in the US, I don't know.
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.
OK.
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.
If IDEA is kept for the sake of PGP 2.x interoperation, then MD5 also
has to be kept (at least in the interface--the python implementation
is fine for that). In principle though I support dropping unneeded
and/or patented algorithms. Keep DES, 3DES, and maybe RC4. Add AES,
and maybe SHA256 and SHA512. Drop the rest.
OTOH I'd like to propose supporting SHA in output feedback mode as a
stream cipher. The reason is that it can be implemented efficiently
in pure Python using the built-in sha library. My own crypto lib uses
it for that reason.
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.
Public key should stay. Its definition and implementation should follow
IEEE P1363.
Also, a Yarrow-like PRNG should be added.
More information about the python-crypto
mailing list