[issue8998] add crypto routines to stdlib

[geremy condra]

geremy condra <debatem1 at gmail.com> added the comment:

On Thu, Jun 17, 2010 at 8:01 PM, Heikki Toivonen <report at bugs.python.org> wrote:
>
> Heikki Toivonen <hjtoi-bugzilla at comcast.net> added the comment:
>
> More or less random opinions on things presented before:
>
>  * I prefer having secure defaults to over documentation, because, well, people don't read documentation.

Wholeheartedly agree.

>  * If not secure defaults, then pointing out in documentation the secure way AND providing examples that always show the secure way of doing things.

Not as big a fan, honestly. Most domain-specific projects can count on
those reading the documentation to have a good idea of what it is that
they actually want to do; in crypto this does not seem to be the case
very often, and that's a tricky problem to fix that in the scope of a
recipe or piece of documentation.

>  * I can't comment on aes 192 vs 256 as I have not really kept up with that, but it would be good to ask the opinion(s) of the real experts in this field before choosing the defaults/recommending them. Of course, if you can point to an article where the experts already voice their (recent) recommendations, fine.

http://eprint.iacr.org/2009/317.pdf
http://eprint.iacr.org/2009/374.pdf
http://eprint.iacr.org/2009/241.pdf

Bruce Schneier's take:
http://www.schneier.com/blog/archives/2009/07/another_new_aes.html

The only cryptosystem/padding/etc choice in evpy I'm uncomfortable
with (at the moment ;) ) is the use of ad-hoc padding rather than
OAEP, and I only do that because that's what evp does. Of course, if
you have any other concerns I'd appreciate hearing about them.

>  * When I have thought about Python crypto in the stdlib, I've considered modeling it after hashlib, so you would get cipher = cryptolib.AES(bits=192, ...) etc. (Caveat: haven't thought it through.)

I'm not opposed to this, but I suspect that focusing on what the
algorithms are for rather than what they are reduces the cognitive
load somewhat. Perhaps a two-tier api?

>  * I'd prefer if the crypto API didn't become OpenSSL specific (like the SSL one is), which would theoretically allow switching in other crypto provider(s).

I agree in theory, although I'm not sure how important this is likely
to be in practice.

>  * The library should make it easy to do the most common operations with as few steps as practically possible.
>  * It would be nice if the library could provide the means to tweak lower level things if you needed to. Unfortunately this has a tendency to get messy quick, because crypto stuff tends to have lots of options to tweak.

100% agree. If you have any ideas- or if anyone else does- on how best
to do this, I'd be very happy to discuss it.

Geremy Condra

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________