There are a variety of tools that offer encrypted filesystems for the various OSs. None of them are as easy to use as we would like, and none have reached the goal of "Zero User Interface" (ZUI) that is the only thing which causes successful deployment of encryption (ie. Skype, SSH and SSL.)

Many of these tools have a risk of failure if you don't also encrypt your swap/paging space, because your swap file will contain fragments of memory, including encrypted files and even in some cases decryption keys. There is a lot of other confidential data which can end up in swap -- web banking passwords and just about anything else.

It's not too hard to encrypt your swap on linux, and the ecryptfs tools package includes a tool to set up encrypted swap (which is not done with ecryptfs, but rather with dm-crypt, the block-device encryptor, but it sets it up for you.)

However, I would propose that swap be encrypted by default, even if the user does nothing. When you boot, the system would generate a random key for that session, and use it to encrypt all writes and reads to the swap space. That key of course would never be swapped out, and furthermore, the kernel could even try to move it around in memory to avoid the attacks the EFF recently demonstrated where the RAM of a computer that's been turned off for a short time is still frequently readable. (In the future, computers will probably come with special small blocks of RAM in which to store keys which are guaranteed -- as much as that's possible -- to be wiped in a power failure, and also hard to access.)

The automatic encryption of swap does bring up a couple of issues. First of all, it's not secure with hibernation, where your computer is suspended to disk. Indeed, to make hibernation work, you would have to save the key at the start of the hibernation file. Hibernation would thus eliminate all security on the data -- but this is no worse than the situation today, where all swap is insecure. And many people never hibernate. For full operation, it does need some APIs and UI. If a more involved disk encryption system is installed on the machine, it would need to talk to the swap encrypter. For example, it could tell the swap system to use keys managed by the master disk encrypter, so when you boot/unsuspend, you would enter a pass phrase that would enable access to both swap and other disks. This would make hibernation secure. Many systems already demand a password to restore from hibernate (though usually after it is restored) so the UI could be combined.

Another API would allow a command to disable the swap encryption. It would, after all, have a small CPU cost, and those who feel they have no security risks in swap might want to do so. But give them the UI to disable it, and leave it enabled if they don't explicitly turn it off.

While the system is alive, root programs that can examine memory and swap would still be able to do so, if you want to have such programs. It would be people who stole your laptop after you had shut it down or emergency reset it who would get nothing from the swap space. (As well as if you hibernated it after enabling a restore passphrase.)

Of course, a full disk encryption system with minimal UI is also something that would be good to make easy to install or even installed by default. However, due to the need for the key, it's harder to do with ZUI. One way to do it is to have a small flashcard slot on the laptop, and store keys there, as well as in a good escrow location. In this case the UI is simply to remember to pull out the card when worried about laptop theft or confiscation, or even deliberately wiping the card (knowing you can get the keys again from your web service with a secret password.)

Even more secure, but harder to do by default, would be a system where your bluetooth phone holds the keys, demanding you be nearby for boot -- also entering a passphrase for those who want full security against those who would steal the phone and the computer.) There are a few tricks here to give near-ZUI with security though:

• If the phone or computer is connected to the network, it might fetch what it needs to provide keys from a server. You can then remotely disable that server, blocking access after your device is stolen. And tell the phone and computer to report what it know about its location of course.
• You could also program the server to take special steps when you know you are going to be in a high-risk situation, such as at a border station. In fact, using the phone's GPS or other location sensing, it could know you are at a border station, and go into paranoid mode until a trusted friend (not you) commands it not to.
• If the phone or computer are not on the network, it can still provide keys if you enter a passphrase on the computer, or provide the key on a card.
• Of course, if the phone is not available, you may want to be able to still booth with a passphrase, though this runs the risk of being compelled to do so.