From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/84217 Path: news.gmane.org!not-for-mail From: Ted Zlatanov Newsgroups: gmane.emacs.gnus.general Subject: Re: Emacs Cloud Date: Mon, 10 Feb 2014 08:32:59 -0500 Organization: =?utf-8?B?0KLQtdC+0LTQvtGAINCX0LvQsNGC0LDQvdC+0LI=?= @ Cienfuegos Message-ID: <87wqh36qk4.fsf@lifelogs.com> References: <877g9fxwih.fsf@building.gnus.org> <87d2j140t1.fsf@building.gnus.org> <87lhxnaw6g.fsf@lifelogs.com> <877g966y3u.fsf@building.gnus.org> Reply-To: ding@gnus.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1392039212 30598 80.91.229.3 (10 Feb 2014 13:33:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 10 Feb 2014 13:33:32 +0000 (UTC) To: ding@gnus.org Original-X-From: ding-owner+M32469@lists.math.uh.edu Mon Feb 10 14:33:36 2014 Return-path: Envelope-to: ding-account@gmane.org Original-Received: from util0.math.uh.edu ([129.7.128.18]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WCqzP-0007lK-9V for ding-account@gmane.org; Mon, 10 Feb 2014 14:33:35 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by util0.math.uh.edu with smtp (Exim 4.63) (envelope-from ) id 1WCqz4-0001vw-0i; Mon, 10 Feb 2014 07:33:14 -0600 Original-Received: from mx1.math.uh.edu ([129.7.128.32]) by util0.math.uh.edu with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1WCqz2-0001vh-7K for ding@lists.math.uh.edu; Mon, 10 Feb 2014 07:33:12 -0600 Original-Received: from quimby.gnus.org ([80.91.231.51]) by mx1.math.uh.edu with esmtps (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1WCqyz-0001hL-R4 for ding@lists.math.uh.edu; Mon, 10 Feb 2014 07:33:12 -0600 Original-Received: from plane.gmane.org ([80.91.229.3]) by quimby.gnus.org with esmtp (Exim 4.80) (envelope-from ) id 1WCqyy-000322-8X for ding@gnus.org; Mon, 10 Feb 2014 14:33:08 +0100 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WCqyv-0007Z2-6V for ding@gnus.org; Mon, 10 Feb 2014 14:33:05 +0100 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 ; Mon, 10 Feb 2014 14:33:05 +0100 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 ; Mon, 10 Feb 2014 14:33:05 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: ding@gnus.org Original-Lines: 44 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:DRXGQb8eK48mY7H73Dxe4RphgUM= X-Spam-Score: -2.5 (--) List-ID: Precedence: bulk Xref: news.gmane.org gmane.emacs.gnus.general:84217 Archived-At: On Mon, 10 Feb 2014 17:43:11 +0900 Daiki Ueno wrote: DU> I wasn't really following the discussion, but I now suspect the use of DU> symmetric encryption here might be irrelevant in the first place. Do DU> you plan to use untrusted (even authenticated, e.g. Gmail) IMAP servers DU> for file sharing, right? DU> If so, those symmetrically encrypted data can be a target of dictionary DU> attacks. You will be giving unlimited time to attackers (or server DU> admins) cracking your encrypted data. Primarily, the data is the Gnus configuration (including topology) and group marks, the newsrc.eld IIUC. Encrypting it may not justify the full asymmetric infrastructure, especially with the use cases of "you're a guest on a machine without the ability to install software" and "you're a guest on a machine and you can't obtain a GnuPG agent connection to a secure machine" (both common in corporate settings). It's still a concern, though, as the Gnus newsrc can at least indicate your reading habits. I personally don't bother to hide or encrypt my newsrc.eld on shared machines, but wouldn't want it easily exposed to IMAP server admins. I think it should be a user choice how that data should be encrypted. Lars mentioned he would like to put the authinfo data in the cloud as well. I think *that* should definitely require an explicit choice by the user and it would make sense to apply asymmetric encryption to that data specifically, if the authinfo is already encrypted (has the .gpg extension). Either way, I plan to treat the authinfo data as keychain entries rather than one big block of data, storing them separately and allowing them to be updated individually. That would mitigate the dictionary attack risk even with symmetric encryption. auth-source.el will need some work, but it's due for a refactoring anyhow. The "encrypted tokens" I added and the plist support you added in auth-source could also be useful here to mitigate the risk, since decrypting the authinfo lines doesn't give access to the secrets. However we approach it, I think the user should have some choice in the matter and we should allow for the two use cases I mentioned above. Ted