Re: [Emacs-diffs] trunk r115420: Use libcrypto's checksum implementations if available, for speed.

[Ted Zlatanov]

On Tue, 10 Dec 2013 09:55:15 -0800 Paul Eggert <address@hidden> wrote: 

PE> Ted Zlatanov wrote:
>> Stefan's objection is not to the default or to the licensing but to the
>> code complexity and growth.

PE> I thought that the objection was to the dependency.  If it's to complexity,
PE> then this depends on whether one is worried about overall complexity
PE> (Emacs + gnulib + libcrypto) or about complexity of Emacs maintenance alone.
PE> If the former, obviously including libcrypto complicates things.
PE> If the latter, it'll complicate Emacs proper slightly to make it harder
PE> for builders to configure Emacs to use libcrypto; obviously no big deal,
PE> if that's the way we want to go.

I'll let Stefan answer; I just mentioned my impression.  See the
discussion I linked earlier for his original responses.

>> what's the rationale for depending on
>> libcrypto (Apache licensed AFAICT) when, as we've mentioned here, GnuTLS
>> (through libnettle+libhogweed) offers very similar facilities from a GNU
>> project?

PE> Performance is the only reason for depending on libcrypto.
PE> Until recently libcrypto was quite a bit faster, but
PE> a few days ago (prompted by the recent gnulib change!) libnettle's
PE> performance was improved on x86-64 (the platform I typically use)
PE> and now libnettle is now 15% slower than libcrypto on Intel,
PE> 20% faster on AMD.  See Niels Möller note in
PE> <http://lists.gnu.org/archive/html/bug-gnulib/2013-12/msg00030.html>.

That's good news! :)

PE> I don't know GnuTLS and nettle well.  Does GnuTLS expose MD5, SHA256, etc.
PE> hash functions as part of its API?  If so, presumably there'd be little
PE> objection to having Emacs use those, as Emacs already depends on GnuTLS.
PE> If not, then Stefan has already objected to depending on libnettle directly,
PE> for reasons I don't understand; also, Eric Blake has mentioned
PE> certification-based objections to direct use of libnettle as opposed
PE> to indirect use via GnuTLS; see
PE> <http://lists.gnu.org/archive/html/bug-gnulib/2013-12/msg00034.html>.

OK, so libnettle+libhogweed expose all the hash, HMAC, and cipher
functionality you'll need.  SHA-*, AES*, RSA, DSA... too many to list.
I got to RSA and DSA when I heard from Stefan, so I stopped at that
point, but the symmetric ciphers, hashing, and HMAC functionality is
integrated.  You can see my patch at the URL of the original discussion
I posted.

The GnuTLS passthrough functions are fairly new.  See the tables in
http://gnutls.org/manual/html_node/Using-GnuTLS-as-a-cryptographic-library.html
for the full list of supported functionality.  I think they support
enough to get us going.

Ted