Re: Emacs crypto use cases

[Stefan Monnier <monnier@iro.umontreal.ca>]

> I can't help the FFI problem,

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

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

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

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

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

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

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.

I don't see off hand what would be the benefit: maybe it avoids the
password problems you reported, but IIUC these only affect GPG2, so
there's already an alternative solution which is to use GPG1.
Also, it sounds like it wouldn't immediately give us the ability to
en/decrypt GPG messages, but instead we'd either have to roll our own
format (bad idea), or reimplement some of GPG's code (bad idea).

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

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

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

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


        Stefan