[PYTHON-CRYPTO] aes library

[Paul Rubin]

[Bram]

    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.

You have to understand, CFB (especially with reduced block sizes)
generally is used for communications systems and not for something
like files.  Adjusting the block size dynamically wouldn't make sense,
partly because the data usually comes at a constant rate, partly
because you'd need some kind of synchronization mechanism to let the
other end know how many encryptions you'd just done.  Remember that
doing eight 1-bit CFB operations is NOT the same as doing one 8-bit
CFB operation and if you don't tell the receiver what you've done,
it won't be able to decode the ciphertext.  Setting the feedback
size in the cipher object constructor is the right way to do it.

If you're going to support all the other modes, omitting CFB is weird.
A typical use of CFB might be something like an encrypted walkie
talkie using a CVSD speech codec (i.e. a 1-bit speech coding scheme).
You'd use 1-bit CFB to encrypt the voice stream and drive the radio
modulator with the ciphertext at maybe 16 kbps.  Because it's CVSD you
don't have to worry about speech frames, and because of the 1-bit CFB,
if you get data errors or the radio signal drops out for a second, you
don't have to worry about resynchronization--CFB automatically
resynchronizes itself after 1 encryption block (< 10 msec at 16 kbps).
You do a lot more encryption operations than your data seems to need,
but you get simplicity that isn't provided by any of the other modes.
So there really isn't any substitute for CFB in these situations.

I also think CBC MAC's should be supported, as mentioned before.  Note
that you want to encrypt and authenticate a message, you must NOT use
the same key for the encryption and the MAC.

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

I don't understand why you want to call it something different.
Encrypt/decrypt is fine even if they both do the same thing.  Suppose
you're writing a modular arithmetic package that supports addition and
subtraction in base 5, base 7, base 10, etc.  As it happens, addition
and subtraction in base 2 are the same thing--does that mean your
package shouldn't support both operations in base 2?  It's not a big
deal but I'd rather use encrypt/decrypt consistently.  Even in CTR
mode, in a variant with an integrity check, encrypt and decrypt won't
do the same thing.

[Eric]

    I would agree with this entirely. It seems to me that the
    algorithm should just implement ECB mode and then the modes of
    operation should be handled elsewhere. We could then use mix-ins
    or Factory classes to generate the actual cipher instance we want.

What's "elsewhere"?  I think it's better to submit just one extension
module rather than a mess of them.  The modes of operation should be
included in the extension module because implementing them in Python
is slow.

    I know you are only talking of implementing AES but we should try to be
    forward looking in doing this ... and I want to be able to easliy plug-in
    different algorithms.

What algorithms do you want to use, other than AES?  I'm not asking
for a list of all algorithms that sound interesting, I'm asking which
ones you ACTUALLY want to use.  The same logic applies to modes of
operation--I'm still having trouble understanding why we want to
support all these modes.

    The same applies for the padding methods. If the algorithm forces the
    padding method it will almost certainly never support the one I need
    in a hurry.

Which padding methods do you want to use, other than PKCS5?

[Phr]

I'd like to propose adding a cryptographic PRNG interface to the
module, or alternatively making a separate module with a CPRNG.
Either way, it's needed.  It's nice if it's in the same module with
AES since then the AES functions can use it to generate random keys
and IV's.  Implentation:

  - On Linux/xBSD, read random data from /dev/urandom
  - On Windows, call CAPI CryptGenRandom
  - On Solaris and similar, call the OpenSSL EGD (entropy gathering
    daemon) interface.  The user must install this separately.
  - On other systems, punt.  Don't try to provide a portable entropy
    source.  That's too tricky.