[issue8998] add crypto routines to stdlib

Gregory P. Smith report at bugs.python.org
Sun Sep 19 08:11:45 CEST 2010


Gregory P. Smith <greg at 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 <report at bugs.python.org> wrote:

>
> lorph <lorph1 at 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 <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________
-------------- next part --------------
<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&#39;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&#39;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">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
lorph &lt;<a href="mailto:lorph1 at gmail.com">lorph1 at gmail.com</a>&gt; added the comment:<br>
<div class="im"><br>
&gt; 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&#39;t plausible, but I couldn&#39;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 &quot;most&quot; cases but there are many cases where it does.  Run your own microbenchmarks on various hardware if you&#39;re curious (&quot;openssl speed algorithmname&quot; 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&#39;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&#39;re curious but please make any responses to that outside of this bug.</div>

<div><br></div><div>-gps</div></div>


More information about the Python-bugs-list mailing list