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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users