This bug has turned into a bikeshed.
Lets stop that please.
I _DON'T_ care about performance when it comes to someone submitting an actual working implementation of a crypto library for inclusion with the standard library. The first priority needs to be a useful stable API.
After that is settled, implementations backed by whatever libraries can be written by anyone who wants to contribute them. Lets not stop that from happening by arguing about who's library is a prettier color. The first one may well be implemented in Python itself as a for all I care.
On Sat, Sep 18, 2010 at 3:54 PM, lorph
<report@bugs.python.org> wrote:
lorph <lorph1@gmail.com> added the comment:
> OpenSSL outperforms libtomcrypt by a significant factor (easily 2x) in most cases.
Gregory, do you have any evidence to substantiate this claim? Not that it isn't plausible, but I couldn't find any benchmarks, and here the author of libtomcrypt finds it to be 40% faster than OpenSSL concerning RSA operations.
I should not have said "most" cases but there are many cases where it does. Run your own microbenchmarks on various hardware if you're curious ("openssl speed algorithmname" on the command line is an existing openssl benchmark). 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
http://software.intel.com/en-us/articles/intel-advanced-encryption-standard-aes-instructions-set/ are not likely to be part of libtomcrypt, nor should they ever be part of code included with and distributed as part of Python. That should come from a dynamic library that is part of the OS. That may be NSS, that may be OpenSSL, that may be any number of other things. Its beyond the scope of this bug.
I'm sorry for bringing the performance angle up even if it motivate me to make hashlib happen.
-gps