Re: Emacs Cloud

[Ted Zlatanov <tzz@lifelogs.com>]

On Mon, 10 Feb 2014 17:43:11 +0900 Daiki Ueno <ueno@gnu.org> 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