[PYTHON-CRYPTO] aes library

[Bram Cohen]

Paul Rubin wrote:

> 1. I think CLE mode should be folded into CTR mode.  Just pass an
> optional arg to the CTR mode constructor specifying the endianness you
> want.

Good idea. It'll be a parameter in the next draft.

> 2. I'd like to see more justification for supporting all those modes
> than "they're in the standard".

There are applications which use them, and I'd like for it to be possible
for those applications to be written in pure Python. In particular,
BitTorrent uses counter, and I'm scratching my own itch :-). Seriously,
even without specific examples to point to, since those are the standard
modes, it's reasonable to expect that each of them will be used by at
least a few applications.

> 3. If CFB mode is supported, arbitary CFB feedback sizes should be
> supported (as long as the feedback size divides the block size).

Okay, I read over the docs and think I understand CFB mode better
now. I'll have an updated API for it in the next draft.

> 4. Making the Python app handle padding is a big slowdown when the
> messages are short.  The C library should handle padding per PKCS #5.
> If there's a standard for ciphertext stealing and other applications
> use it, then support that too.  Otherwise skip it.

That only matters for *really* short files, like less than 1k. Future
versions can have added support for padding modes in C, but 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.

-Bram Cohen

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