[PYTHON-CRYPTO] aes library

[Paul Rubin]

    Ah, I see. That ain't never gonna perform well implemented in python.

    I see your point about completeness though. How about I drop OFB as well,
    so we just have ECB, CBC, and counter?

I won't miss OFB.  CBC should stay since it's what most systems use
for encrypting multiple messages without needing to re-key between them.
ECB should stay in case the application wants to synthesize other stuff
with it.  Do you really need CTR?  Is there a good reason BitTorrent
doesn't use CBC?

    Isn't CBC MAC trivial to build when you have CBC?

Sort of, but if the plaintext is big, you end up allocating a lot of
memory for the ciphertext just to discard it.  Also, you want separate
calls to compute and verify MAC's, to have an interface that can still
work in systems with more key management (e.g. key objects that are
allowed to check signatures but not to sign things).  I guess this
isn't a big deal though and maybe it just clutters up the module, so
we can leave it out.

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

    There may be a call for 3DES at some point in the future. I think
    we could just make a 3DES module with the same API as aes though.

If we want 3DES, I'm leaning towards wanting in the same module as
AES.  For some reason I'd thought of a module as being compiled from a
single .c file, but of course it isn't.  So unless we really want to
support a wide variety of ciphers for interoperability purposes, we
can implement 3DES and AES and call it quits.  (If we want a lot of
ciphers we probably also want all the operation modes, etc.)

Internally, of course, there should be some consistent interface to
block ciphers, so that the operation modes would be implemented just
once instead of multiple times.

    > I'd like to propose adding a cryptographic PRNG interface to the
    > module, or alternatively making a separate module with a CPRNG.

    I think this is very warranted, but should be in a separate module.

I now tend to prefer having it in the same module as AES, for the same
reason as above, but I can go either way.

    I'm considering making the API have actual processing objects, rather than
    functions, which have the following methods -

So if you wanted to encrypt a string, would you say

  ciphertext = enc.read(enc.write(plaintext))

This all seems a little too abstract for me.  However, if such an
abstraction is really wanted, it should implement the Python i/o
stream interface so you can print to it and stuff like that.