Re: Wherein I argue for the inclusion of libnettle in Emacs 24.5

[Ted Zlatanov <tzz@lifelogs.com>]

On Tue, 04 Feb 2014 13:46:35 -0800 Paul Eggert <eggert@cs.ucla.edu> wrote: 

PE> On 02/04/2014 12:11 PM, Ted Zlatanov wrote:
>> Well, here's the rejection letter:
>> http://permalink.gmane.org/gmane.emacs.devel/163980
>> 
>> As I said then, feel free to add your vote of support.

PE> I don't see his email as rejecting entirely the idea of having Emacs C
PE> code invoke GnuTLS functionsthat it doesn't already invoke.  It's more
PE> that it's a negative (a tighter coupling between Emacs and GnuTLS),
PE> that could be overcome by other positives (more functionality that's
PE> actually useful).

Yes, the thread went on from there (see
http://comments.gmane.org/gmane.emacs.devel/163906 for the start of it).

PE> Do you have some clear and convincing use-cases?  That seemed to be
PE> his first objection.

I wrote plenty in the thread.  I got no votes of support and Stefan
thought my use cases were too abstract.  Now Lars has stated a specific
use case, which will perhaps convince more people.

PE> For example, would it help the performance of secure-hash considerably
PE> if it used the GnuTLS API to do checksums?  If we did that in Gnulib,
PE> the maintenance overhead to Emacs proper would be essentially zero,
PE> and the integration hassles for Emacs users would be no greater than
PE> they are now (since Emacs already uses GnuTLS if available).  For
PE> which real-life use-cases would this help?

It could help that libnettle and libhogweed have some well-optimized
hashing code.  At least MD5 and SHA1 checksums are used all over the
place in Emacs packages.  But we have our own implementations for those
in Emacs, so I don't think hashing makes for a convincing use case.

The interesting primitives are HMAC+PBKDF2; the Nettle ciphers applied
in CBC, ECB, and CTR modes; and the public key algorithms (RSA, DSA,
ECDSA).  Those are the building blocks I'd like.

Ted