[PYTHON-CRYPTO] aes library

[Bram Cohen]

Paul Rubin wrote:

> I strongly prefer separate objects per mode.  Mixing modes probably
> leads to security failures.

True enough. Separate modes it is.

> The idea isn't to re-use iv's, but rather, to be able to encrypt a
> single message in multiple pieces if for some reason you don't want
> to keep the cipher object open between pieces.  Normally you wouldn't
> use these.

One can simply create a new cipher object in that case.

> Also, is anyone here on Python-dev?  We should send them an email
> asking what kind of module they'd accept.  I propose something along
> these lines:
>
>    1) We think the "Cryptographic Services" part of the library should
>       include a good encryption algorithm to go along with MD5 and
>       SHA.  The rotor module is of questionable security and should be
>       deprecated.  So we'd like to submit a module that does
>       encryption based on AES, for inclusion in future Python
>       releases.
>
>       It would have an easy-to-use interface like the rotor module,
>       and also provide an API that allowed more fine-grained control
>       of the algorithm (modes of operation, etc.) for users who want
>       that.  This module would be written in portable C.

That's emphasizing it's replacing of rotor rather that it's utility as a
library, which I think is more important. I have no sense of which is more
likely to sell.

>    4) We'd like to know the opinion of the Python maintainers about
>       this stuff: how big an issue is OS dependence for #3?  Should we
>       make separate modules for AES, DES, and CPRNG, or combine them all
>       into one?  Is it ok if the AES/DES modules have a number of modes
>       and entry points that will interest only advanced users?

The AES calls could easily be used as part of libraries called by
non-'advanced' users. They make it so that crypto stuff in general can be
in pure Python.

Bryan Mongeau wrote:
> > Have you tested your thread racing implementation much?  How do the
> > results look?
>
> Well, it tops out at ~300 bytes/sec on my 800 and is solidly
> indeterministic.

That makes it a good punt, but it's still a punt - a system could easily
be rebooted and give the same 'random' values twice in a row. Best to use
the system-specific source of 'real' random numbers whenever possible.

Eric Johnson wrote:
> I have yet to use AES. I use DES and DES3 daily. The banking industry
> uses DES/DES3.

Ah, we have reason to include that then.

> I have had to use and implement PKCS#5 padding once (for a project 5
> years ago). The padding methods I use daily are from ISO/IEC 9797-1.

Where is that documented? We can easily add it as another padding number.

> I have never used any modes of operation other than ECB and CBC.

Okay then, no counter mode for the DES module.

I'm not sure what to do with the DES/3DES distinction in the API. There
are a few possibilities -

have all calls have a flag to indicate des/3des

have parallel calls for des/3des

have different modules for des/3des

> I think secure randoms, hash functions (RIPEMD160 etc) and PK stuff
> should be in different modules. MACcing should be in the block cipher
> module.

That's my feeling as well, based on how other modules are organised,
specifically sha and md5 being in their own modules.

> I want Factory methods so I can easily use algorithms (mainly for
> authentication) that cannot be made public due to NDAs and don't have to
> rewrite my code all the time.

That can easily be implemented as a higher layer of abstraction in pure
Python.

I sincerely hope that NDA's aren't the banking industry's way of not
admitting that they're using 1DES.

Okay, here's the latest version of the API, I think it's
non-asymptotically approaching being finished -

ECB(key)
    encrypt(str)
    decrypt(str)

ECB is simple, straightforward, and non-controversial. I think we have
consensus that this is the right way to do it.

CTR(key, pos = 0, bigendian = 1)
    encrypt(str)
    decrypt(str)
    setpos(pos)
    getpos()
    scan(amount)

I realized that having non-incremental calls to CTR is a bit silly, so
this is the simplified version. The only call here I'm a bit unsure about
is scan() - it's the same as encrypt(chr(0) * amount) - I'm not sure if
it's needed, and if it is, I don't know if I like the name.

CBC(key)
    encrypt(str, iv, padding = 1)
    decrypt(str, iv, padding = 1)
    encrypter(iv)
    decrypter(iv)

The tricky bit here is padding, it can have one of these values -

0 - none
1 - PKCS#5
2 - ISO 9797-1

I'm not sure which is the default value and whether there should be any
more padding modes in the first version. I'm also not sure which one
should be the default.

The objects returned by encrypter() and decrypter() have the following
mehtods -

update(str)
finish(padding = 1)
amount_buffered()

I prefer finish() instead of final() unless there's something else which
uses final.

-Bram Cohen

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