geremy condra <debat...@gmail.com> added the comment: On Thu, Jun 17, 2010 at 8:01 PM, Heikki Toivonen <rep...@bugs.python.org> wrote: > > Heikki Toivonen <hjtoi-bugzi...@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 <rep...@bugs.python.org> <http://bugs.python.org/issue8998> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
