[issue8998] add crypto routines to stdlib

[geremy condra]

geremy condra <debatem1 at gmail.com> added the comment:

On Mon, Sep 20, 2010 at 3:44 PM, lorph <report at bugs.python.org> wrote:
>
> lorph <lorph1 at gmail.com> added the comment:
>
>> Do you think that if OpenSSL provided its own implementation of strlen(), every text that mentions strlen() needs to acknowledge OpenSSL? Do you realize how ridiculous that is?
>
> If that text is deemed to be advertising by Eric Young and a court of law, then absolutely yes. The license is short, clear, and does not make any exceptions for features that you might deem to be commonplace.
>
> http://www.openssl.org/source/license.html
>
> I also agree that this is ridiculous, but believing something is ridiculous does not make it any less real as Barnes and Nobles learned the hard way by using Amazon's one-click patent.

I get called paranoid a lot, but I don't find this terribly
convincing. Having said that, I'm happy to have your help in making
sure that the interface we create is agnostic with respect to openssl,
libtomcrypt, NSS, etc. That would mean that if Eric Young did decide
to try and force his hand we would be able to switch away the very
next day with no muss and no fuss. Are you willing to provide that
help?

>> The important thing to realize is that libtomcrypt is
> intentionally written in very portable C.  That is great but it leaves a lot on the table. Optimizations for various platforms to take advantage of enhanced instruction sets such as SSE2 and explicit hardware crypto acceleration instructions such as [...] are not likely to be part of libtomcrypt,
>
> A quick glance at libtomcrypt tells me otherwise. It is portable C, but it still has inline assembler. It has optimizations using SSE2, x86, x86_64, and PPC32. Even though it might not have that new Intel AES instruction yet, this is the same argument people had for using GMP for python's integers.

I'm not worried about speed. In fact, if fast means "vulnerable to
side-channel cryptanalysis" I'm firmly opposed to it, and I don't know
if that's the case here. OpenSSL has at least been subject to
significant attention in that regard.

> If there is a problem with multiple libraries, I'd like to reiterate my support for migrating to NSS.

I'm happy to do this work if you (or someone else) will step forward
and help me identify and fix compatibility concerns. Otherwise, this
is just a waste of time all around.

Geremy Condra

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________