I'm looking for a good way to encrypt and decrypt files on your hard disk that:
1)doesn't require the file is first written to disk (in plain text)
2)uses secure memory (like gpg does)
3)doesn't decrypt the file to disk

Thanks for your suggestions.

I suggest using a loopback encrypted filesystem (note: free registration required, but an excellent step-by-step).

Is there a way to use gpg to encrypt/unencrypt a file in the console (secure memory) so you don't have to write it to disk (with say xedit) before and after you use gpg to encrypt/unencrypt it?

I've used the "gpg -c" option but that required a file on disk first. Also when you unencrypt the file it writes it to disk (is there a way around this?)...Thanks.

Well... you could write your data to /dev/shm/. That is a pseudo filesystem in RAM, so it is volitile, and standard access permissions apply. If your distribution doesn't mount it automatically, you will need to add an entry like this to your /etc/fstab:

That seems most sensible to me.

keep in mind that tmpfs will write to the disk (swap) if necessary... this might or might not be a concern for you... if it is, then i'd suggest a regular ramdisk instead...

just my ...

so far the easiest way i've found is to make the file with a text editor (e.g. xedit) then do a "gpg -c" and shred the original file. Are there any tmp files or caches I should worry about when using xedit (text editor of choice)? Thanks.

ps. there is a gvim gpg plugin but its 3 years old and it only works with keys.

While I'm not familiar with xedit enough to know if it will use tmp files under any condition, I do know that shred may not work as you intend (unless the argument is a physical partition or disk). From the man page, there are many filesystems and configurations that may prevent actually overwriting file data.

Another possibility is to use either a loopback encrypted filesystem on /dev/shm (to handle the situation that win32sux mentioned), or to use a fuse (filesystem in user space) encrypted filesystem to hold the temporarily clear text information. In that way, even the clear text data that you see is actually always stored in an encrypted format.

It's really a question of how important the data is, and how willing you are to adhere to the necessary procedures to protect the data. Even with scripts automating the various processes, it can become quite tedious very quickly. Real security is more about discipline than algorithms.

Thats exactly why I'm looking for a simple method: security through simplicity (usually).

After all, for absolute security an encrypted ram disk is needed, and I've never set one of those up before (i'll look into it more though). And then, from there, you can use gpg to encrypt the data to disk. Even many of the most paranoid people don't consider encrypting the memory, but if you are trying to protect data why not ensure its protected...

Encrypted memory does not give you much protection, because on a linux system, only the appropriate processes and root can access a given page of memory, and when root is compromized, security is gone anyway.
The real problem is your swap file. If unencrpted files are in memory and written to swap, an attacker could, with some effort, later recover them from the disk. Possible workarounds are:
a) using locked memory. Locked memory is never written to swap. E. g. gpg does this to prevent passphrases to be leaked. However, I have no idea how to make sure a ramdisk uses locked memory.
b) disabling swap (requires root privileges). c) encrypting swap (a lot of work, drastically diminishes swap performance). You could use loop-aes or maybe dm-crypt for that.

If the swap problem is sorted out, i would create a ramdisk and decrypt the file there., afterwards reencrypt it to disk fill the whole ramdisk with zeros: If you write a script, that does most of teh work for you, operating the en/decryption should be quite easy once everything is properly set up.

This seems to be a reliable source for why I said an encrypted ram drive is a good idea:
http://www.cs.auckland.ac.nz/~pgut00...ecure_del.html

Of course this should be used in addition to an encrypted swap (or swapoff if you have a lot of memory).
It is unfortunate that the facts within this paper are almost never mentioned by security experts.