Secure text editor?

[Peter S. May]

Peter Lebbing wrote:
> I want to have a text file with personal data in it, which I encrypt to
> myself, and decrypt to view and edit. However, to do that securely, I need
> an editor which will not leak the text in any way, so locking it's
pages in
> memory so they won't be swapped out, and other angles of attack.
> ...
> My workstation runs Windows, but I think I would prefer a tool that works
> under Linux too (possibly under Cygwin in Windows).

Some of the other respondents so far seem to have missed the part where
you mentioned locking pages in memory.  I've been curious about this
myself; is there any text editor in existence that locks itself from
being paged out to the swap space?  If there isn't, why not?

Anyway, my guess is that no such self-contained Windows-based solution
exists, since even gpg can't lock its memory in Windows.  It would be a
lot more _possible_ to make one for a Linux-based system, but I haven't
heard of one myself.  Either way, I thought I'd heard somewhere that
even locked memory can get written to disk if the operator decides to
enter hibernate mode...

(Developers familiar with swap-locked memory:  I'd appreciate at least a
short explanation of how it works to someone who understands ISO C but
not necessarily OS-specific APIs.  Can stack memory be locked, or only
heap memory?  Would there be any way to load a whole, full-featured text
editor, such as the 1.8MiB vim on my machine, entirely into locked RAM
without screwing something up?)

As one of the other readers noted, however, one way to counteract any
such problem is to install a whole-disk encryption solution.  That way,
even if what you've got is paged out to disk, nobody can get to it while
the machine is off.  I can think of imperfections with this system as
well, but they're not terribly significant.  On Linux, swap space is its
own partition, which makes it possible to do crazier things with it,
such as run whole-volume encryption on the partition with a session key
randomly generated at each startup--so that the moment you shut down it
becomes garbage even if you don't shut down properly.

I myself simply make sure I have a filesystem on my machine that's
capable of causing shred -uz to work as prescribed (ext3 with no
journaling) and give the swap partition an occasional stir with shred.
Anyone who can get past that is fairly likely to be able to do worse
things with my system.

(A script I wrote and still use acts a whole lot like crontab, complete
with -l and -e flags:  It consults mktemp for a filename to use,
decrypts to it, runs whatever is in my VISUAL/EDITOR env on it, signs
and re-encrypts back to its original location, and runs shred -uz on the
temp file.  It's not leakproof, but it at least makes attacks
nontrivial.  It makes a handy password stasher and has singlehandedly
broken my habit of using anything but randomly-generated passwords on
most websites. :-D  Needless to say, this isn't a smart thing to do
unless the encrypted file is backed up regularly...)

Anyway, decide how likely or unlikely an attack is before expending too
much effort on this one.  :-)

M2C
PSM

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : /pipermail/attachments/20070514/9feff17b/attachment-0001.pgp