block ciphers

[Trevor Perrin]

Paul Rubin wrote:
> [...]
> PEP 272 has an API for both block and stream ciphers, and the block
> cipher API is kind of cumbersome.

In what way?  It seems to me quite simple:

>>> from Crypto.Cipher import AES
>>>
>>> context = AES.new(key, AES.MODE_CBC, iv)
>>> ciphertext = context.encrypt(plaintext)
>>
>>> context = AES.new(key, AES.MODE_CBC, iv)
>>> plaintext = context.decrypt(ciphertext)

A couple of the keyword arguments could be changed ('rounds', and
'counter'), and the IV should probably be writeable as well as readable
(which is how PyCrypto, which implements this PEP, actually works).

Other than that, I've been using this API (and wrapping a few other
cipher libraries with it), and I find it about as close to transparent
and painless as you can get!


> I did some work a while back on
> defining a new block cipher API and posted some about it back then.
> I've been meaning to get that code out of mothballs and propose a new
> PEP.  A sample implementation is at 
> 
>   http://www.nightsong.com/phr/crypto/blockcipher.tgz

I'd be happy with that too, but it seems a smidgen less simple, at least
for the user:

>>> from blockcipher import CBC
>>> import AES
>>>
>>> context = CBC(AES.ecb(key), 'e', iv)
>>> ciphertext = context.update(plaintext)


More importantly though, PEP 272 is already implemented (in PyCrypto),
and it's been in use awhile so people (like me) have code built around
it, and experience with it.

Again, I'd be happy with either, but PEP 272 / PyCrypto seems the
leading horse in this race.


[Trevor]
>>So is this totally out of the question?  Or would it be worth
>>pursuing, through a PEP, or patch, or discussion on python-dev?
> 
> 
> I'm not sure exactly what you're asking.

Me neither, exactly... ;-)  I'm just trying to gauge the interest or
resistance to this, and see if there's any way I could help.


Trevor