Antoine Pitrou <pit...@free.fr> added the comment: Le mardi 15 juin 2010 à 14:49 +0000, geremy condra a écrit : > The goals of the library are simplicity and ease of use. I've > frequently found that out of fear of making incorrect choices, people > will simply decide not to use crypto at all, or that they make > incredibly stupid choices like using RSA without padding. I'd be > willing to add in the option to alter those options via keyword > arguments if it became a major point of contention, but in general I > think its better for those who "just want to encrypt something" to > have a lot of those decisions made for them. The specific decision > you're talking about was made because while AES-256 has a bigger > number at the end, its key schedule appears weaker in light of recent > attacks.
While it's fine to perhaps detect and warn about insecure use, I don't think the API should be too directive (for inclusion in the stdlib anyway). Most (if not all) stdlib modules don't impose any specific policy but instead provide building blocks for users to address their specific needs. Directive APIs should probably be left to third-party libraries (which can of course build on the primitives provided by the stdlib). Also, some uses of crypto functions can be to interoperate with existing cryptographic protocols, and for that you need a fine-grained control over algorithmic options. Do note that the docs can be as educating as needed; they can include suggestions, warnings and even small recipes. As for default argument values, the problem is that we're then stuck with them (for compatibility). It means that if e.g. AES-192 gets compromised, Python will promote an API which by default is insecure and dangerous to use. Again, giving equal access to various ciphers and then providing guidance in the documentation would be a better compromise. ---------- _______________________________________ 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
