From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daiki Ueno Newsgroups: gmane.emacs.devel Subject: Re: GPGME Date: Wed, 29 Jun 2011 05:36:02 +0900 Message-ID: <874o39n171.fsf-ueno@unixuser.org> References: <878vtmo081.fsf@lifelogs.com> <87tycamhmv.fsf@lifelogs.com> <87pqmxvfoh.fsf@lifelogs.com> <87sjrttwh8.fsf@lifelogs.com> <87wrh4b9h9.fsf@lifelogs.com> <87aae05l8p.fsf-ueno@unixuser.org> <87k4d4b66p.fsf@lifelogs.com> <87wrh0fh4g.fsf_-_@lifelogs.com> <87y60ncma8.fsf_-_@lifelogs.com> <87vcvrne02.fsf-ueno@unixuser.org> <87r56ep3sm.fsf@lifelogs.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1309293397 3775 80.91.229.12 (28 Jun 2011 20:36:37 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 28 Jun 2011 20:36:37 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 28 22:36:33 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Qbf1M-00033z-Cd for ged-emacs-devel@m.gmane.org; Tue, 28 Jun 2011 22:36:32 +0200 Original-Received: from localhost ([::1]:58065 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qbf1L-000149-Cg for ged-emacs-devel@m.gmane.org; Tue, 28 Jun 2011 16:36:31 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:49827) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qbf14-00013l-0J for emacs-devel@gnu.org; Tue, 28 Jun 2011 16:36:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qbf12-0007oS-3Z for emacs-devel@gnu.org; Tue, 28 Jun 2011 16:36:13 -0400 Original-Received: from ivory4.scn-net.ne.jp ([219.117.176.192]:46925) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1Qbf11-0007o8-0t for emacs-devel@gnu.org; Tue, 28 Jun 2011 16:36:11 -0400 Original-Received: from ([192.168.0.187]) (envelope sender: ) by ivory4.scn-net.ne.jp with Active!Hunter esmtp server; Wed, 29 Jun 2011 05:36:05 +0900 Original-Received: Received: from well-done.deisui.org (g187018.scn-net.ne.jp [202.83.187.18]) (authenticated) by blue17.scn-net.ne.jp (unknown) with ESMTP id p5SKa413017974 for ; Wed, 29 Jun 2011 05:36:05 +0900 In-Reply-To: <87r56ep3sm.fsf@lifelogs.com> (Ted Zlatanov's message of "Tue, 28 Jun 2011 06:56:57 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-Received-From: 219.117.176.192 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:141147 Archived-At: Ted Zlatanov writes: > Are there any alternatives? Maybe you remember our discussion years ago > about encrypt.el, where I proposed a neutral API with at least some > symmetric ciphers implemented in ELisp and C in the Emacs core > (essentially what Lars was requesting). I remember that the problem of encrypt.el was that the data format is not interoperable and the algorithm used is not interchangeable though the API might be neutral. I guess you need a minimal encryption function which employs the standard GPG message format (RFC4880). > Could something like that work > within the EPA/EPG structure, so some special invocation of > `epg-encrypt-string' could bypass the external callout to GPG? If your statement in <87wrh0fh4g.fsf_-_@lifelogs.com>: The decoding will happen late, probably in the funcall to obtain the secret (and it will set some scoped variables to cache the data) is true, epg-encrypt-string is not necessarily to be optimized in that way, I think. How about implementing your side first and profiling before the optimization? One suggestion to reduce the number of calls to epg-encrypt-string is that, I would suggest encrypt the key name as well. For example, key1 val1 encrypted hexdata where hexdata is decrypted to: key2 val2 key3 val3 Regards, -- Daiki Ueno