Gregory P. Smith <g...@krypto.org> added the comment:
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.
-gps
(comments below are to answer questions but really are not relevant to the
bug)
On Sat, Sep 18, 2010 at 3:54 PM, lorph <rep...@bugs.python.org> wrote:
>
> lorph <lor...@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.
An example benchmark of hashlib using libtomcrypt sha1 vs openssl sha1 is
here http://bugs.python.org/issue1121611#msg47779 if you're curious but
please make any responses to that outside of this bug.
-gps
----------
Added file: http://bugs.python.org/file18928/unnamed
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________<meta charset="utf-8"><div>This bug has turned into a
bikeshed.</div><div><br></div><div>Lets stop that
please.</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>-gps</div><div><br></div><div>(comments below are to answer
questions but really are not relevant to the bug)</div><br><div
class="gmail_quote">On Sat, Sep 18, 2010 at 3:54 PM, lorph <span
dir="ltr"><<a
href="mailto:rep...@bugs.python.org";>rep...@bugs.python.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc
solid;padding-left:1ex;"><br>
lorph <<a href="mailto:lor...@gmail.com";>lor...@gmail.com</a>> added the
comment:<br>
<div class="im"><br>
> OpenSSL outperforms libtomcrypt by a significant factor (easily 2x) in
most cases.<br>
<br>
</div>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.<br>
</blockquote><div><br></div><div>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 <a
href="http://software.intel.com/en-us/articles/intel-advanced-encryption-standard-aes-instructions-set/";>http://software.intel.com/en-us/articles/intel-advanced-encryption-standard-aes-instructions-set/</a>
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.</div>
<div><br></div><div>I'm sorry for bringing the performance angle up even if
it motivate me to make hashlib happen.</div><div><br></div><div>An example
benchmark of hashlib using libtomcrypt sha1 vs openssl sha1 is here <a
href="http://bugs.python.org/issue1121611#msg47779";>http://bugs.python.org/issue1121611#msg47779</a>
if you're curious but please make any responses to that outside of this
bug.</div>
<div><br></div><div>-gps</div></div>
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
