Python’s keyring lib supports Windows win32crypto, Mac OS X’s SXKeychain, KDE’s KWallet, Gnome’s keyring, and encrypted or unencrypted password files. When your application wants to store or fetch data from the keyring, it will just work.

Generate a gpg keypair. Check /dev/random to make sure you’re getting some output. If you dont get any standard output when you run this, ctrl-c and you will see 0+1 records in/out. This means there is a problem with your /dev/random device. Here’s the fix…

If you want to store a mix of encrypted and unencrypted files under the same area, choose plaintext passthrough, otherwise choose the default, no. I suggest an all or nothing approach, as it can get confusing as to which files are encrypted especially when they’re binary! (With ascii text files you can just cat a file and tell if it’s encrypted or not.)

I really like eCryptfs, an encrypted file system supported in kernel able to encrypt right on top of the already supported file systems. No kernel-user-kernel-user swapping required. I like the selective ability of encrypting individual files and I especially like the interchangeable key structure.
While eCryptfs sounds great, there are a few downsides of stacked file system encryption.

I’m going to test on a remote machine that I have a shell on, so lets see how many processors it has. I wonder how many connections it can handle with its current 1024 bit certificate. You could test by retrieving a file accessible from the encrypted web server if you wanted (to see how many requests for something specific that the server can handle for example) I’ll try this from a different machine.

Use cryptsetup to setup dm-crypt managed device-mapper mappings. This method will allow you to use an encrypted mapping to transparently read and write encrypted data so that you and your applications don’t even need to worry about handling any encryption at all; it will just work, trust me. If you need to save data that’s already on the device, then copy it somewhere else, encrypt the drive, and copy it all back after encrypting.

I wouldn’t do it this way for a production network, but i’ve set up similar configurations for testing in vmware, in a research environment, and in a production environment.  So instead of a step by step, here’s a quick run through… It should clear up some of the missing pieces …