[PYTHON-CRYPTO] aes library

Paul Rubin phr-pycrypt at nightsong.com
Sat Mar 30 06:01:23 CET 2002


    The purpose of this module is *not* to be a complete library for
    all the standard things one might want to do with aes. Rather,
    it's a bare-bones library which does just enough to make it
    possible to implement all the standard aes stuff efficiently in
    'pure' Python, with the only C calls being to this library.

If it's a bare-bones library it needn't implement all the operation
modes.  If it's going to implement them all, it should also implement
a reasonable padding mode for CBC.  "That only matters for *really*
short files, like less than 1k" shows a belief that the stuff being
encrypted will be files, but I believe it equally likely that it will
be short strings like credit card numbers or other encryption keys.

    past arguments have convinced me that noone can agree on what the
    standard common padding modes are, so I'd rather not open that can of
    worms.

This surprises me.  I thought RFC 1423 was an internet standard and
section 1.1 specifies a perfectly good padding algorithm a/k/a PKCS
#5.  I don't see any worms.  Do you know of another standard?

    The bigendian parameter determines whether encoding of the counter
    into a block to be encrypted is done big or little endian. It
    defaults to 1 (true).

The default should be chosen so that the NIST CTR mode test vectors
work consistent with ECB mode under the default.  That's probably big
endian but we should make sure.

I think CTR mode should use the same encrypt/decrypt operation names
as the other modes, even if encrypt and decrypt in CTR mode do the
same thing, instead of process/processor.  It's just less junk to
remember.  Endianness should be specified in the object constructor,
not on each crypto operation.  Why would anyone want to mix endianness
in one crypto object?





More information about the python-crypto mailing list