Emacs crypto use cases (was: GNU Emacs-libnettle-libhogweed integration patch v1)

[Ted Zlatanov]

On Mon, 07 Oct 2013 18:58:00 -0400 Stefan Monnier <address@hidden> wrote: 

>> If I changed my proposal to use the GnuTLS interface functions, so no
>> new library dependencies are added, would it be acceptable?

SM> It'd be a bit less bad, but basically the main problems remain:
SM> - no clear and concrete use-case.
SM> - I want these things to go through an FFI.
SM> - I don't want to have an OpenPGP implementation to maintain.

I can't help the FFI problem, but you already depend on libgnutls so I
don't see what difference it makes here.

I don't have to put the OpenPGP implementation in the Emacs core, if it
can be put in a package.  Actually GnuTLS has some work in that
direction (as of 3.1) so it may turn out to be fairly trivial on our
side, but then without FFI it would have to be supported in the core.  I
don't really care that much about the delivery method as long as it
works.

Regarding the use cases, you could look at the algorithms in
http://gnutls.org/manual/html_node/Using-GnuTLS-as-a-cryptographic-library.html#Using-GnuTLS-as-a-cryptographic-library
and see for yourself that they form a general toolbox that will serve
the Emacs core well.  I will make an effort here to list some use cases,
but I am positive there will be more as time goes on.  I would
appreciate it if anyone else interested in this work added their use
cases or vote of support.

- symmetric encryption without the burden or risk of shelling out
  
(http://gnutls.org/manual/html_node/Encryption-algorithms-used-in-the-record-layer.html#tab_003aciphers).
  I would love to use this instead of the painfully heavy GnuPG
  integration for the symmetric case.

- HMAC keyed hashing (http://www.ietf.org/rfc/rfc2104.txt) allowing
  message authentication with a shared key.  For instance, that would
  allow the Emacs client and server to authenticate the data they share
  without a full PPK infrastructure, or check that some shared memory
  hasn't been corrupted... it's a general authentication mechanism for
  content.

- asymmetric (public-private key) operations: encrypt and verify data.
  This is obiously the foundation of package signing in an OpenPGP
  implementation, but is useful on its own.  My use case is storing
  secret data in Emacs in an encrypted format, so it can't be decoded
  trivially.  The private key can be protected from a memory dump in
  many ways depending on the platform (e.g. the Secrets API).  A full
  OpenPGP protocol for this would be overkill.

- OpenPGP support: allow package.el signing verification without GnuPG
  on the platform and much more.

I hope this is helpful.

Ted