From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Emacs crypto use cases Date: Mon, 07 Oct 2013 23:02:21 -0400 Message-ID: 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1381201353 29022 80.91.229.3 (8 Oct 2013 03:02:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 8 Oct 2013 03:02:33 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 08 05:02:38 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 1VTNZE-0005ty-EM for ged-emacs-devel@m.gmane.org; Tue, 08 Oct 2013 05:02:36 +0200 Original-Received: from localhost ([::1]:34360 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTNZD-00034t-Vp for ged-emacs-devel@m.gmane.org; Mon, 07 Oct 2013 23:02:35 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44068) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTNZ5-0002wm-Ok for emacs-devel@gnu.org; Mon, 07 Oct 2013 23:02:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VTNZ1-00087m-1F for emacs-devel@gnu.org; Mon, 07 Oct 2013 23:02:27 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:6737) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTNZ0-000870-Tm for emacs-devel@gnu.org; Mon, 07 Oct 2013 23:02:22 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABK/CFHO+K8t/2dsb2JhbABEvw4Xc4IeAQEEAVYoCwswBBIUGA03CRKHcAYMwSGNYQJLglwDlymNUYFegmop X-IPAS-Result: Av4EABK/CFHO+K8t/2dsb2JhbABEvw4Xc4IeAQEEAVYoCwswBBIUGA03CRKHcAYMwSGNYQJLglwDlymNUYFegmop X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="34985948" Original-Received: from 206-248-175-45.dsl.teksavvy.com (HELO pastel.home) ([206.248.175.45]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 07 Oct 2013 22:58:42 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id B94266049A; Mon, 7 Oct 2013 23:02:21 -0400 (EDT) In-Reply-To: <87d2ngzlyl.fsf_-_@flea.lifelogs.com> (Ted Zlatanov's message of "Mon, 07 Oct 2013 19:43:14 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.182 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:163986 Archived-At: > 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 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