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: Emacs crypto use cases (was: GNU Emacs-libnettle-libhogweed integration patch v1) Date: Mon, 07 Oct 2013 19:43:14 -0400 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87d2ngzlyl.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> 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 1381189407 7552 80.91.229.3 (7 Oct 2013 23:43:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 7 Oct 2013 23:43:27 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 08 01:43:30 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 1VTKSV-0005FT-L5 for ged-emacs-devel@m.gmane.org; Tue, 08 Oct 2013 01:43:27 +0200 Original-Received: from localhost ([::1]:33954 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTKSU-0005px-S2 for ged-emacs-devel@m.gmane.org; Mon, 07 Oct 2013 19:43:26 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42477) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTKSO-0005mX-Ci for emacs-devel@gnu.org; Mon, 07 Oct 2013 19:43:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VTKSJ-0005RL-Lb for emacs-devel@gnu.org; Mon, 07 Oct 2013 19:43:20 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:41755) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTKSJ-0005R6-FO for emacs-devel@gnu.org; Mon, 07 Oct 2013 19:43:15 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VTKSH-0005C3-Sv for emacs-devel@gnu.org; Tue, 08 Oct 2013 01:43:13 +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 01:43:13 +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 01:43:13 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 54 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:UDkIkN+jUIdEVoyHSdELc7AQkm4= 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:163983 Archived-At: On Mon, 07 Oct 2013 18:58:00 -0400 Stefan Monnier 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