block ciphers

[Trevor Perrin]

(I know this has come up before, but the previous discussions I could
find seemed inconclusive, so I hope people don't mind...)


Q: How about adding block ciphers to Python 2.4?

PEP 272 defines an API, and there's an excellent library that implements
it [1]. It would be very little work to copy the AES and DES3 modules
into stdlib (perhaps in a 'ciphers' package).

As far as legal issues, US Export is no problem - you just email in a
notice [2]. A few countries have import issues, though I believe
they're widely disregarded (the windows installer comes with SSL; has
anyone complained?). Furthermore, it would be easy to provide a
no-crypto distribution.

It's hard to distribute pure-python crypto software without this. You
have to include or reference 3rd-party extension modules, which some
users won't want to install, some will have trouble installing (like
Windows users without a compiler), and some won't be able to install
(Jython or IronPython users, for example).

So is this totally out of the question? Or would it be worth pursuing,
through a PEP, or patch, or discussion on python-dev?


Trevor


[1] http://www.amk.ca/python/code/crypto.html
[2] http://www.bxa.doc.gov/Encryption/PubAvailEncSourceCodeNofify.html

 

[Paul Rubin]

Q: How about adding block ciphers to Python 2.4?

PEP 272 defines an API, and there's an excellent library that
implements it [1]. It would be very little work to copy the AES and
DES3 modules into stdlib (perhaps in a 'ciphers' package).

PEP 272 has an API for both block and stream ciphers, and the block
cipher API is kind of cumbersome. 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

but there are some things about it that I want to change. I recently
used it to write a pure-Python script that decrypts PGP files, if
that's of any interest too.

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.

 

[Trevor Perrin]

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

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:


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]

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

 

[Nick Efford]

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.

I would definitely like to see better crypto in the standard library.


N.

 

[Ed Suominen]

I would definitely like to see better crypto in the standard library.


N.

Agreed. See http://privaria.org for an example of what I might do with it.