[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