Python Cryptography Toolkit

Design Goals

The Python cryptography toolkit is intended to provide a reliable and
stable base for writing Python programs that require cryptographic
functions.

A central goal has been to provide a simple, consistent interface for
similar classes of algorithms. For example, all block cipher objects
have the same methods and return values, and support the same feedback
modes. Hash functions have a different interface, but it too is
consistent over all the hash functions available. Some of these
interfaces have been codified as Python Enhancement Proposal
documents, as PEP 247, "API for Cryptographic Hash Functions", and
PEP 272, "API for Block Encryption Algorithms".

This is intended to make it easy to replace old algorithms with newer,
more secure ones. If you're given a bit of portably-written Python
code that uses the DES encryption algorithm, you should be able to use
AES instead by simply changing from Crypto.Cipher import DES to
from Crypto.Cipher import AES, and changing all references to
DES.new() to AES.new(). It's also fairly simple to
write your own modules that mimic this interface, thus letting you use
combinations or permutations of algorithms.

Some modules are implemented in C for performance; others are written
in Python for ease of modification. Generally, low-level functions
like ciphers and hash functions are written in C, while less
speed-critical functions have been written in Python. This division
may change in future releases. When speeds are quoted in this
document, they were measured on a 500 MHz Pentium II running Linux.
The exact speeds will obviously vary with different machines,
different compilers, and the phase of the moon, but they provide a
crude basis for comparison. Currently the cryptographic
implementations are acceptably fast, but not spectacularly good. I
welcome any suggestions or patches for faster code.

I have placed the code under no restrictions; you can redistribute the
code freely or commercially, in its original form or with any
modifications you make, subject to whatever local laws may apply in your
jurisdiction. Note that you still have to come to some agreement with
the holders of any patented algorithms you're using. If you're
intensively using these modules, please tell me about it; there's little
incentive for me to work on this package if I don't know of anyone using
it.

I also make no guarantees as to the usefulness, correctness, or legality
of these modules, nor does their inclusion constitute an endorsement of
their effectiveness. Many cryptographic algorithms are patented;
inclusion in this package does not necessarily mean you are allowed to
incorporate them in a product and sell it. Some of these algorithms may
have been cryptanalyzed, and may no longer be secure. While I will
include commentary on the relative security of the algorithms in the
sections entitled "Security Notes", there may be more recent analyses
I'm not aware of. (Or maybe I'm just clueless.) If you're implementing
an important system, don't just grab things out of a toolbox and put
them together; do some research first. On the other hand, if you're
just interested in keeping your co-workers or your relatives out of your
files, any of the components here could be used.

This document is very much a work in progress. If you have any
questions, comments, complaints, or suggestions, please send them to me.