Encrypted Filesystems With Linux?

PhracturedBlue asks: "There are lots of ways to encrypt a filesystem (via loopback, ppdd, CFS or CryptFS), but all of these options appear to have their faults, be it poor performance, lack of features, or not being actively maintained. So are there any other options out there, that provie quality FS encryption with reasonable performance? So, are there any other viable options, besides the ones I've found? Are there any actual benchmarks of actual performance for the viable options above (I guess the viable ones are loopback, CFS, TCFS, and PPDD)? How about systems using the AES-winner Rijndael (I know Loopback Encryption and possibly TCFS and PPDD can use Twofish, but isn't Rijndeal supposed to be one of the faster encryption methods?). I've seen the recent Slashdot article, and it didn't really address the above questions."

"First let me say that I know little to nothing about cryptography, and I wouldn't know the first thing about good vs. bad options, so any statements I make here are based on what I've read and may be completely erroneous. What I'm looking for a way to secure my (Debian) Linux laptop, since physical security is an issue (I can't keep it locked up in my house all the time). So I went out looking for a way of encrypting my filesystem.

The easiest method appears to be to install Loopback Encryption, but from what I can figure out this is a bad solution because (a) its very poor performance, and (b) there is no way to do key authentication. Another option is CFS (a quick howto can be found here), but this is also reported to have poor performance (even with blowfish, or the NFS related TCFS) and it also appears to be abandoned. (Okay TCFS may not be abandoned, but it hasn't been updated for over a year). People seem to rave about CryptFS, but this appears to be a prototype developed for a research paper that has gone no further. Of the last real options that I've uncovered PPDD (which is a device-driver rather than a filesystem) seems like it may be the most promising (though it doesn't seem to have been updated since January, and I can find no indication about testing it with the 2.4 beta kernels)."

Comments

Re:why?

[rgmoore]

But why shouldn't somebody want to encrypt their whole partition? There are actually a number of reasons why doing so might very well be a better idea than encrypting selected files:

• No need for an explicit decision. Rather than having to decide whether a file is worth encrypting, it happens automatically. This is particularly nice if I later change my mind about wanting to encrypt something; there are no bits left on my HD that might contain an unencrypted version.
• Less effort. Rather than having to encrypt and decrypt specific files each time I want to use them, or remember a specific password to access them, it happens without obvious effort. That's just plain handy.
• Why not? Yes there is a possible performance penalty, but there's no other particular reason not to encrypt. Just because people have typically not done things that way doesn't mean that we should continue.

In general, I think that the valid question is not "why should you bother to encrypt your /home partition" but rather "why should the default behavior be to let anyone be able to read the data off the hard drive". The existence of file permission bits in Unix already implies that the right to prevent others from reading your data is a good thing. Why not back it up with a mechanism that can't be trivially avoided by reading the raw data off the disk?

StegFS

[Laxitive]

You might want to look at StegFS. It's a stegagnographic filesystem. It supports multiple "levels" of security, and the nifty thing is that nobody can tell exactly how many levels of encrypted filesystems there actually are. I.e., you can have 3 levels of encryption, and even if the first level is broken, there is no way for the cracker to get to the other levels, or even find out exactly how many levels of encryption there are. Check out stegfs by clicking on this link . -Laxitive

My /home is encrypted

[abelsson]

I have my homedir encrypted with the loopback driver. It's worked like a charm for around a year, when i decided to try it just for fun. No dataloss, no crashes.

Some observations:
It's not noticeable slower. I havn't run any benchmarks, but there's absolutly no noticeable slowdown of any kind. Even when copying 0.5gb files between encrypted and unencrypted dirs - the harddrive is the limiting factor, not the encryption algorithm. Granted, i have a speedy CPU (Athlon 900mhz) and only a IDE hardrive (a 7200rpm deskstar). Just if you missed it, The speed difference isnt noticeable. There, now i've said it three times :)

Another thing to take into account is that you only need to encrypt data, not binaries. Encrypting /usr only gives an attacker more known plaintext to try to crack the key with.

As for the other drawback you mention, i think having no key authentication is acctually an adantage: There's no fixed header the Bad Guys can use to prove that it isnt a 2gb big chunk of random data. Think plausible deniability. (even tho it's a long shot: i swear officer, i always keep 2gb of the outout from /dev/urandom on all my computers)

As for algorithms, i think they're mostly irrelvant, as long as you use an algorithm with no known secure holes and a long enough keylength (128bits should be impossible for just about anyone to bruteforce). Cracking fingers (if you just want the data) or the passwords (if you dont want anyone to know you stole it) is most likely a lot easier than bruteforcing the algorithm. So the main advice here: Choose a good long password!

I havn't tried any of the other available methods, but i doubt any has a lower overhead than the kernel level loopback filesystem.

I feel reasonable safe about entrusting all my data to the loopback fs encryption. (i even reviewed the code before compiling - just to be on the safe side. Me, paranoid? Where'd you get that idea from?)

-henrik