[PYTHON-CRYPTO] aes library

[Bram Cohen]

Paul Rubin wrote:

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

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 also think CBC MAC's should be supported, as mentioned before.

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

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

Okay, okay. Encrypt/decrypt it is.

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

Yes, that's my reasoning as well.

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

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.

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

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

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

write(s) - adds the string s to the stream

read(amount = None) - reads amount bytes of plaintext/ciphertext. reads
however much is possible if no amount is set.

amount_read() - the number of bytes which have been read so far

amount_ready() - the number of bytes which are ready to be read

amount_buffered() - the difference between the number of bytes written and
    the number of bytes read so far. In counter mode this will always be
    the same as amount_ready()

My reasoning is that this will get rid of a lot of unnecessary data
copies, and also simplify using it quite a bit, since there won't have to
be a lot of taking the output of the processor and shoving it into a
cStringIO.

Note that with this API, PKCS#5 is ridiculously easy to implement -

d = enc.amount_buffered() - enc.amount_ready()
if d == 0:
    d = 16
enc.write(chr(d) * d)

and then you can read whatever's left out of enc.

What does everyone think?

-Bram Cohen

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