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: GPGME Date: Wed, 29 Jun 2011 06:09:27 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87iprosxlk.fsf@lifelogs.com> 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> <874o39n171.fsf-ueno@unixuser.org> Reply-To: emacs-devel@gnu.org NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1309348220 22661 80.91.229.12 (29 Jun 2011 11:50:20 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 29 Jun 2011 11:50:20 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 29 13:50:16 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 1QbtHa-0001Ir-Ll for ged-emacs-devel@m.gmane.org; Wed, 29 Jun 2011 13:50:14 +0200 Original-Received: from localhost ([::1]:35194 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QbtHZ-0002Kh-O3 for ged-emacs-devel@m.gmane.org; Wed, 29 Jun 2011 07:50:13 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:45984) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QbseR-0000JV-Sd for emacs-devel@gnu.org; Wed, 29 Jun 2011 07:09:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QbseQ-0006Eq-6U for emacs-devel@gnu.org; Wed, 29 Jun 2011 07:09:47 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:54709) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QbseP-0006Em-Nk for emacs-devel@gnu.org; Wed, 29 Jun 2011 07:09:46 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QbseM-0000Rv-IF for emacs-devel@gnu.org; Wed, 29 Jun 2011 13:09:42 +0200 Original-Received: from 38.98.147.133 ([38.98.147.133]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 29 Jun 2011 13:09:42 +0200 Original-Received: from tzz by 38.98.147.133 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 29 Jun 2011 13:09:42 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 63 Original-X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 38.98.147.133 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.110018 (No Gnus v0.18) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:oejPn/OeEsoxt9+LKHuWCM2kONA= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 80.91.229.12 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:141166 Archived-At: On Wed, 29 Jun 2011 05:36:02 +0900 Daiki Ueno wrote: DU> 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). DU> I remember that the problem of encrypt.el was that the data format is DU> not interoperable and the algorithm used is not interchangeable though DU> the API might be neutral. Is that a problem, if the intent is to provide an Emacs facility? DU> I guess you need a minimal encryption function which employs the DU> standard GPG message format (RFC4880). I'm not sure that would benefit any Emacs users since EPA/EPG already provide so much functionality for this and the GPG message format doesn't seem to have any obvious benefits for simple data encryption. >> 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? DU> If your statement in <87wrh0fh4g.fsf_-_@lifelogs.com>: DU> The decoding will happen late, probably in the funcall to obtain the DU> secret (and it will set some scoped variables to cache the data) DU> is true, epg-encrypt-string is not necessarily to be optimized in that DU> way, I think. How about implementing your side first and profiling DU> before the optimization? That's not a performance optimization. We decode late to avoid prompting the user for a passphrase before the password is actually needed. I'm asking if, instead of a new package, we can use `epg-encrypt-string' to provide symmetric encryption without calling GPG externally. It can provide it in any format and with any symmetric cipher you think would make sense. But if you don't think so, then we need a new package to provide that functionality. DU> One suggestion to reduce the number of calls to epg-encrypt-string is DU> that, I would suggest encrypt the key name as well. For example, DU> key1 val1 encrypted hexdata DU> where hexdata is decrypted to: DU> key2 val2 key3 val3 But if we do that, we have to decrypt the hexdata in order to know it has key2 and key3. The benefit of the GPG tokens for netrc field encryption is that you know all the keys, so you can search for "must have key X" with confidence, without prompting the user, and without extra decryption overhead at search time. Obviosly if you search for "must have key X with value Y" that doesn't work, but typically we don't encrypt things that we search for. Right now we only encrypt the password in any case. Ted