This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author debatem1
Recipients daniel.urban, debatem1, eric.araujo, exarkun, gdamjan, giampaolo.rodola, gregory.p.smith, heikki, jsamuel, loewis, mcrute, pitrou
Date 2010-06-18.03:49:28
SpamBayes Score 2.7041737e-05
Marked as misclassified No
Message-id <AANLkTin6oIbeFNFeOO6q30fFQhMRrrzjb1BjcFKlL1Sn@mail.gmail.com>
In-reply-to <1276830100.14.0.212836058317.issue8998@psf.upfronthosting.co.za>
Content
On Thu, Jun 17, 2010 at 8:01 PM, Heikki Toivonen <report@bugs.python.org> wrote:
>
> Heikki Toivonen <hjtoi-bugzilla@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
History
Date User Action Args
2010-06-18 03:49:31debatem1setrecipients: + debatem1, loewis, gregory.p.smith, exarkun, pitrou, giampaolo.rodola, gdamjan, heikki, eric.araujo, daniel.urban, mcrute, jsamuel
2010-06-18 03:49:29debatem1linkissue8998 messages
2010-06-18 03:49:28debatem1create