Method/program for editing secure files

Question

I'm not entirely sure if this is on-topic for Security.SE, but it doesn't seem entirely off-topic either, so I'll try. :)

I keep a couple of (GPG-)encrypted files with more-or-less sensitive information; particularly passwords for various web services. While they are mostly used read-only, I sometimes need to edit them to change or add information, and I worry about how I leak the contents of them when doing so, and what can be done about it.

In particular, what I do is: 1) decrypt the file, 2) edit it with vi -n (I'm using Linux), 3) encrypt the file again and 4) clear the decrypted file with the shred utility. I know, however, that this leaves at least the following venues for the contents to leak:

• Since vi's memory is swappable, it may have leaked to the swap partition. I guess this is unlikely due to me having lots of RAM and the editing sessions being brief, but it's clearly a possibility.
• The same can be said for the terminal emulator I'm running vi in, obviously.
• Worst of all, however, is that vi uses the terminal's "alternate screen", which isn't cleared when vi exits.

Is there anything that can be done about these, and are there any others that I've missed. I guess there should be some easy way to clear the alternate screen after I've exited vi, but I haven't found one yet (neither clear nor reset do). The problems about vi and xterm being swappable, however, seem generally harder to fix.

Can anything be said about general guidelines when editing files with secure contents?

Answer 1

Here is what I have done, and still do in some specific cases:

1. I use a machine with no swap. In my case, an old Asus EeePC with the famously horrendous proto-SSD; you really do not want to use it for swap space. Instead, I replaced the RAM chip, up to 2 GB.

2. I configure /tmp to be a RAM-based filesystem (search for "tmpfs" in the man page for "mount").

3. When I need to access a GnuPG-encrypted file, I decrypt it and visualize or edit it entirely in /tmp. Only the encrypted file ever exists on the disk.

4. I never use the "hibernate" option. I shut the machine off when I don't use it.

That way, no risk of leakage to a permanent medium. I apply this when I need to travel and keep my "passwords.txt" file with me. The attack model is the following: if my machine is stolen, it will be off.

Now this probably seems a little extreme, but I think it is time to reconsider the wisdom of enabling swap space. Over the last four years, the only occasions where I actually hit swap were situations with a process gone into an endless allocation loop, thus saturating the whole RAM -- the presence of swap only served to make the problem worse, not better, because it allowed the machine to pretend that it could survive, and engage into considerable harddisk grinding, before finding out that the mad process had finally to be killed.

GC-based language and smartphones/tablet both contribute to creating an ecosystem of software (applications, libraries...) which are definitely adverse to swap, so it can be predicted that swap space will keep on losing relevance over the next years.

(I admit that if I wanted to use hibernation, it would bring the leakage back. But I never really got used to hibernation; I prefer to optimize the boot sequence. My current laptop -- not the EeePC -- has a good SSD and runs Lubuntu: it boots up in less than 25 seconds, including the BIOS sequence.)