Re: Emacs crypto use cases

[Ted Zlatanov]

On Mon, 07 Oct 2013 23:02:21 -0400 Stefan Monnier <address@hidden> wrote: 

>> I can't help the FFI problem,
SM> Can't see why not.  On the contrary, you have a perfect use case for the
SM> FFI, so all you need is to dive in.  The way I suggest to do it
SM> (apparently a path also followed by Jerry James <address@hidden> in
SM> XEmacs) does not require any special knowledge, AFAICT.

SM> Just write a .c file and matching .h that will be included in Emacs and
SM> that describe some functions exported from Emacs to the dynload modules.
SM> Then adjust your libnettle code to use those exported functions instead
SM> of the lisp.h macros.  Then write a bit of package.el code that runs
SM> a C compiler for packages that include such C files.  And finally add
SM> a `dynload' function that uses something along the lines of `dl_open'.

I have no idea how that would work.  Is there an example?  And is this
anywhere close to usable?  The FFI discussion thread hasn't indicated
it.  If I'm to be the guinea pig, I'm not excited about it.

>> but you already depend on libgnutls so I don't see what difference it
>> makes here.

SM> It means more code, hence more bugs to fix, especially in the long run.
SM> It means more exposed interfaces that we'll have to live with for the
SM> next decades.

SM> Hence the need for "clear and concrete use-case" to justify the
SM> investment.

I honestly didn't know Emacs was turning into Enterprise Software.

>> 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.

SM> I don't need hypothetical use-cases.  I need concrete ones.

>> - 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.

SM> I don't see off hand what would be the benefit: maybe it avoids the
SM> password problems you reported, but IIUC these only affect GPG2, so
SM> there's already an alternative solution which is to use GPG1.

Given the choice between:

- run a persistent gpg-agent daemon everywhere and depend on it for
  accessing my secret data, shelling out to GnuPG 2.x, installing it
  everywhere I need my data

- shelling out to GnuPG 1.x, installing it everywhere I need my data

- calling a fast internal function against the existing GnuTLS libs

I prefer the last one.  It may not be for everyone, but it's right for
me, and today we're *forcing* our users into a particular security model
away from the last choice.

In general I believe a well-integrated system is more reliable and
secure than a loosely coupled system, but the matter of choice is what
bothers me the most.

SM> Also, it sounds like it wouldn't immediately give us the ability to
SM> en/decrypt GPG messages, but instead we'd either have to roll our
SM> own format (bad idea), or reimplement some of GPG's code (bad idea).

As I mentioned, GnuTLS can provide most of that for us.  The complicated
tricky parts are there; the OpenPGP protocol is mostly ASN decoding on
top.  In any case, I hope this would be a ELPA package to remove it from
your concern.

SM> Better work on trying to solve the password problem either by fixing
SM> GPG2 or by changing the way epg.el uses GPG2.

I am tired of arguing that one, honestly.  Comment on the relevant bugs
if you like, but right now there is no password problem according to
Daiki Ueno.

>> - 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,

SM> Still requires distribution of that shared key, which seems like a pain
SM> compared to simply connecting via SSH.

The distribution of a shared key enables *fast* message authentication
with minimal infrastructure.  Setting up a separate SSH channel or PPK
or SSL certificates requires significant infrastructure.

(We could also require a private VLAN for every client-server
connection, that would be very secure and require no work from us. :)

SM> So, I'll be happy to add such code to GNU ELPA, but for now I don't want
SM> it in Emacs.  Hence the FFI.

I'll see what I can do with FFI, but this is likely to take a lot of my
time.  Some help getting started would go a long way.

Ted