[PYTHON-CRYPTO] aes library

[Bram Cohen]

Paul Rubin wrote:

>     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.

I've been waffling on the utility of CFB. I just did a 'vote' of mode
popularity by asking google -

"CBC mode"      11100
"counter mode"   6250
"ECB mode"       4390
"CFB mode"       2760
"OFB Mode"       1980

The clear winners in terms of popularity are CBC and counter, and ECB
needs to be included for completeness. In search results, there are lots
of mentions of the problems with CFB and suggestions for all sorts
of funky variants of it. Also, while the API I suggested for using CFB
is clearly the only reasonable one, it hardly gets any mention in the
press, as people seem to greatly favor the moronic practice of doing a
reduced block size for *every* encryption, as opposed to the reasonable
but still funky practice of adjusting the block size dynamically to suit
how the data is coming in.

So I think I'll dump CFB. OFB is so simple though that I'm in favor of
keeping it - it has the property that multiple messages can be encrypted
using the same key but doesn't have the padding problems of CBC.

>     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?

That's a reasonable padding algorithm, but it's far from the only one in
use. Like I said, I'm not designing this API to provide a single handy
encryption function for non-cryptographers to use (although one could
certainly be written on top of it.) I'm designing it to make
interoperation with other protocols possible in pure Python.

>     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.

The docs seem to imply big endian but don't talk about it in a coherent
manner, I guess one has to run the actual test vectors to find out.

> 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.

How about crypt/crypter?

> Endianness should be specified in the object constructor, not on each
> crypto operation.

Done.

I'll post an updated version of the API later.

-Bram Cohen

"Markets can remain irrational longer than you can remain solvent"
                                        -- John Maynard Keynes