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.