Re: NaCl support for Emacs

[Ted Zlatanov <tzz@lifelogs.com>]

On Mon, 09 Jan 2012 22:21:19 -0500 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> Argh.  The auth-source cache is already implemented as a hack, is that
>> hard enough evidence?  Quoting the relevant bit from
>> `auth-source-netrc-parse':

>> #+begin_src lisp
>> ;; cache all netrc files (used to be just .gpg files)
>> ;; Store the contents of the file heavily encrypted in memory.
>> ;; (note for the irony-impaired: they are just obfuscated)
>> (aput 'auth-source-netrc-cache file
>> (list :mtime (nth 5 (file-attributes file))
>> :secret (lexical-let ((v (mapcar '1+ (buffer-string))))
>> (lambda () (apply 'string (mapcar '1- v))))))
>> #+end_src

SM> Not only I'm not worried about that, but I'm not sure libnettle (or any
SM> other encryption library) would help you fix the underlying problem:
SM> Emacs needs to be able to recover the password for later use anyway, so
SM> anything we do can only ever be obfuscation, AFAIK.  Maybe there's some
SM> clever way to do better, but again, for lack of hard evidence
SM> I'm unconvinced.

With true encryption with libnettle, we can encrypt the secret in
memory, on the wire, and on disk so a casual attacker doesn't have the
chance to grab it.  This should hook into the Lisp object printer, for
instance, so it's effortless to print and read encrypted objects.

I'm worried about treating obfuscation as "good enough" security.  That
has a history of backfiring.  Would it convince you to show an attack
that succeeds with obfuscation but fails with true encryption?

I know Emacs is not designed with security in mind.  We have to start
somewhere; this will at least harden the outer shell.  You may not be
worried about it, but I am.

Ted