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

How I encrypted my laptop

[Hairy_Potter]

I just removed the keys, and then replaced them incorrectly, foiling anybody but a touch typist. For instance, some cracker gets my laptop and tries to su, but they type this instead:

# ay
ay not found

Then they try to get to my /etc/passwd file, but end up typing this:

# fs .wrx.osaaqes

Really, this work!

CFS: best solution at the moment, IMHO

[Anonymous Coward]

The loopback-based solutions have the following drawbacks:

• The filesystem is a fixed-size file, thus unnecessarily eating diskspace when it's not filled and not being extendable as soon as it is full.
• It's closely tied to the Linux kernel and thus may break with future kernel upgrades. Not good IMHO for data where security is top priority.

CFS's major drawback is the performance penalty because it works over NFS (also internally). That said, I don't notice performance issues when working with CFS-encrypted text files on a Pentium I and an AMD K6. Moving data to CFS directories is slow though. BUT:

• Since it's a userspace implementation, it doesn't depend on kernel code; indeed, you can flawlessly exchange CFS-encrypted between Linux, *BSD and any other *nix flavor.
• The cypher files reside in the original file/directory structure (with encrypted names) on any filesystem. This makes it possible to burn CFS data on CD-ROMs, use it on DOS-formatted floppies etc.etc. It's also great for backup, because the backup software doesn't need to copy the whole crypto filesystem every time (as with the loopback solution), but only the files that were changed.

A very promising solution is ReiserFS, as soon as the plugin API has been implemented. Crypto plugins for ReiserFS will probably the fastest and easiest way to securely store data (although CFS data will still remain more portable).

(remaining anonymous this time because I don't want the whole world to know that there is CFS-encrypted data on my computers)

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?

Definitely susceptible

[devphil]

Peter Gutmann wrote an outstanding paper on recovering data from various media, especially hard drives. Bottom line: once it's written, you can almost always get it back eventually.

His paper is http://www.fish.com/security/secure _de l.html and is a good read.

Favorite fact: Freezing your RAM (like, -60 degrees C) makes the data easier to recover. Yeah, that's right, I said the RAM, not just the drives. Go read the paper. :-)

Hardware Encryption For Linux

[n3rd]

Would anyone know if there are any hardware level encryption devies that Linux supports?

As with most things, using hardware instead of software is faster (sometimes *much* faster), so this would not only be an answer to the speed problem that was posed, but also it would be very reliable (as opposed to encryption daemons that may die when the system runs out of swap, etc).

The other advantage is that hackers can't touch it. What if a hacker recompiled the binaries for your software encryption with a backdoor? Bad news, your formally encrypted partition is now fully accessable to the hacker or anyone who is aware of the backdoor. With a hardware solution, it's almost impossible to trojan and/or modify the hardware.

Ideas on the hardware solutions for disk encrption that are out there, and if so, which ones does Linux support?

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