On Tue, Jun 15, 2010 at 9:49 AM, Antoine Pitrou <report@bugs.python.org> wrote:
>
> Antoine Pitrou <pitrou@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.

I'm not clear on how a crypto library is supposed to detect insecure
use short of simply not allowing suspicious things. Maybe you have
some ideas there?

As for building-block type systems, like I say they have their place,
particularly where interoperating with existing systems is a concern,
and I don't want to come across as though I don't respect projects
like M2Crypto- I just think that most developers don't need that
level of complexity and aren't prepared to invest the time to learn
how to get what they want out of it. That's where something like
evpy shines.

> Do note that the docs can be as educating as needed; they can include
> suggestions, warnings and even small recipes.

I'm reasonably sure that there aren't enough docs in the world to
stop people from using OpenSSL to live dangerously. Evpy you
could get people not to be completely stupid with, at least a large
portion of the time.

> 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.

I would be enormously surprised if a weakness in AES-192 was found that
weakened it to the point where it would actually constitute bad advice,
assuming that you made all the other right decisions. Having said that, it
might be a good idea to put a version switch in that allowed you to specify
compatibility modes, just in case.

Geremy Condra