From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.devel Subject: Re: Emacs crypto use cases Date: Tue, 08 Oct 2013 06:33:36 -0400 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87siwcxda7.fsf@flea.lifelogs.com> References: <877gdqrc9u.fsf@flea.lifelogs.com> <87mwmmp05f.fsf@flea.lifelogs.com> <87fvsdpato.fsf@flea.lifelogs.com> <8738oc20xk.fsf@flea.lifelogs.com> <87d2ngzlyl.fsf_-_@flea.lifelogs.com> Reply-To: emacs-devel@gnu.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1381228426 11647 80.91.229.3 (8 Oct 2013 10:33:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 8 Oct 2013 10:33:46 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 08 12:33:51 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VTUbs-0000K5-Hz for ged-emacs-devel@m.gmane.org; Tue, 08 Oct 2013 12:33:48 +0200 Original-Received: from localhost ([::1]:35680 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTUbs-0001cc-4H for ged-emacs-devel@m.gmane.org; Tue, 08 Oct 2013 06:33:48 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33244) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTUbk-0001c8-Je for emacs-devel@gnu.org; Tue, 08 Oct 2013 06:33:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VTUbg-0001ZE-3U for emacs-devel@gnu.org; Tue, 08 Oct 2013 06:33:40 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:54918) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTUbf-0001Z2-QM for emacs-devel@gnu.org; Tue, 08 Oct 2013 06:33:36 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VTUbe-0000Eq-N8 for emacs-devel@gnu.org; Tue, 08 Oct 2013 12:33:34 +0200 Original-Received: from c-98-229-61-72.hsd1.ma.comcast.net ([98.229.61.72]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 08 Oct 2013 12:33:34 +0200 Original-Received: from tzz by c-98-229-61-72.hsd1.ma.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 08 Oct 2013 12:33:34 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 103 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-98-229-61-72.hsd1.ma.comcast.net X-Face: bd.DQ~'29fIs`T_%O%C\g%6jW)yi[zuz6; d4V0`@y-~$#3P_Ng{@m+e4o<4P'#(_GJQ%TT= D}[Ep*b!\e,fBZ'j_+#"Ps?s2!4H2-Y"sx" Mail-Copies-To: never User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux) Cancel-Lock: sha1:z5uNUsT9vrSJQmZ/XjPh0PQVPAU= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:163997 Archived-At: On Mon, 07 Oct 2013 23:02:21 -0400 Stefan Monnier 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 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