Message108077
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 |
|
Date |
User |
Action |
Args |
2010-06-18 03:49:31 | debatem1 | set | recipients:
+ debatem1, loewis, gregory.p.smith, exarkun, pitrou, giampaolo.rodola, gdamjan, heikki, eric.araujo, daniel.urban, mcrute, jsamuel |
2010-06-18 03:49:29 | debatem1 | link | issue8998 messages |
2010-06-18 03:49:28 | debatem1 | create | |
|