Slashdot Mirror
Seeking Current Info on Linux Encrypted FS?
slick_rick asks: "I'm looking for info on encrypted file systems under Linux to help my employers company move away from Microsoft centric solutions. However the latest HOWTO is two years old, the latest kernel patch dates back to April (and 2.4.3) and even the Sourceforge project has nearly zero documentation and appears to be very dead. Are slashdotters using encrypted file systems? If so, what are your experiences?" We last talked about this topic, just
over a year ago, in this article.
It's been a long time since I set it up under FreeBSD...but, as I recall, it had a very easy-to-setup system for creating an encrypted filesystem. I just 'cattach' it when I boot the machine...and I'm the only user than can look at the contents. It's really quite nifty. And I've never been able to find a good Linux equivalent.
If you can wait until September 2002, ReiserFS v4 will have an encryption plugin builtin.
Note that this filesystem based encryption, not user based. I.e. you must enter a password to mount the filesystem, but after that it acts as a normal filesystem (but slower due to the aforementioned encryption).
The way that SuSE do it is to have an encrypted block device, so that you can throw anything you want on top of it. Typically this would be a filesytem ;-)
From the SuSE webpage:
Encrypted filesystems are useless without deniability. Rubberhose gives you that: http://www.rubberhose.org
"The invisible and the non-existent look very much alike." -- Delos B. McKown
The kernel patch you refer to is not outdated. There just is no reason to release new versions. Here's how you patch your kernel with the international patch.
/usr/src), do...
/usr/src/linux/Makefile.rej. It shows you what lines failed. You can easily fix this by adding (under the DRIVERS line)
:) Also, make sure you build the loopback device as a module, and then add crypto support. I assume you know how to load modules
/dev/loop0 /dev/hda3
/dev/loop0 with your favorite file system (I prefer ReierFS because I've had trouble with ext2 fscking of encrypted file systems -- data loss most notably whenever I mistyped my passphrase). Do something like
/dev/loop0
/dev/loop0
/etc/fstab
/mountpoint reiserfs defaults,loop,auto,encryption=serpent 0 0
/. question. But that's just my opinion.
One level up from your Linux source tree (typically
zcat ~/patch-int-2.4.3.1.gz | patch -p0 -E
You'll notice a chunk fails. The ONLY problem here is patching the root Makefile. Look at the file
CRYPTO = crypto/crypto.o
And changing the line
SUBDIRS = kernel drivers mm fs net ipc lib
to...
SUBDIRS = kernel drivers mm fs net ipc lib crypto
Now your kernel should be properly patched. Make it mrproper, then configure as needed. Add the proper cyphers (I'm sure you can figure this out). Typically, serpent and blowfish are the best choices. Also, build them as modules so you can harvest a little extra entropy.
Now for the easy part. Once you have the kernel modules built and loaded, make sure you have the latest mount tools (including losetup). Pick the device file you want to use as an encrypted file system. For this example, I'm going to use hda3 with 256 bit serpent encryption for shits & giggles.
losetup --keybits 256 --encryption serpent
It will prompt you for a pass phrase. Use a PHRASE and REMEMBER this. You cannot change the passphrase of an encrypted fs after you set it. Get it right. Next, format the device
mkreiserfs
Now, destroy the loopback device...
losetup -d
And add the following line to your
/dev/hda3
Now, every time you boot or mount that file system, it will ask you for the key length and the pass phrase. And there you go. Encrypted file system. Yea.
You can see how trivially easy that was and if you had put about half an hour's thought into it, you could have realized that the "outdated" howto hasn't been updated because the process is pretty much unchanged and you would not have wasted our time with yet another linux newbie Ask
Why bother.
Maybe you need deniability, but out here in the real world a lot of people should be using encrypted file systems just to ensure that sensitive or confidential information is not exposed to others if the disk is stolen, the cleaning people are bored, etc.
Personally, I don't want my doctor to have deniability about his records regarding me. Or my lawyer. Or my accountant. And most especially not my banker, financial adviser, etc.
In fact, for these people deniability makes a solution look much less attractive. People get *really* nervous when their accountant or lawyer has strong deniability about what the advice they gave you, about where your money went, etc.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
Do a search on google for CryptoAPI. That's the new encrypted filesystem interface for linux. The pathes for 2.4.3 are old. I have an encrypted file system working with 2.4.16 patched with GRSecurity. You no longer need to patch the kernel with CryptoAPI, it just creates kernel modules that you install. It's pretty easy to do.
For the past two years, I've been using it in several distributions, manually applying the kernel patches and compiling the necessary programs (utils). But with SuSE (>7.2), kernel encryption is built in which has saved me a load of time compiling it into the kernel.
SuSE uses twofish as the encryption algorithm which is good enough for me. I would prefer to use serpent, but not enough to recompile everything. Both twofish and serpent were finalists in the U.S. Federal AES competition, both losing to rijndeal. Of course, W2K/XP use weak 56-bit DES in their EFS and have administrator back doors, so it barely qualifies as encryption.
If you want fast, reliable, and easy to use enrypted file systems, choose SuSE!
For the truly paranoid, or as used to be my case, for laptops that travel a lot and hence are very prone to theft, the cool thing to do is to encrypt your (almost) entire disk, with your root filesystem on an encrypted loopback device, and no swap at all (because swap can't efficiently be encrypted, and RAM is so cheap anyway nowadays). Of course you still need to keep a small unencrypted boot partition to host your kernel, and an initrd image. The initial ramdisk must have a script that will setup the loop device -- prompting you for your passphrase -- before proceeding with system boot.
For additional protection, you might be tempted to keep this boot partition on a business-card size CD-R, thus making sure that nobody can insert code to steal your passphrase, but if they have access to your system for long enough, they could install a hardware keylogger and you're screwed anyway ^_^... Still, might be worth it to put some tamper detection right after the root fs is mounted (i.e. an md5sum check of your entire boot partition)
In any case, I've used such a laptop on a day-to-day basis for over a year and it worked great -- but do expect a huge performance loss on disk access.
On a related note, there is a warning on http://www.kernel.org/pub/linux/kernel/crypto/v2.4 /README.WARNING to the effect that encryption might be a bit broken in 2.4 kernels. I guess you better stick with 2.2 for now if you really need loopback crypto filesystems...
"Words have meaning, and names have power." -- Lorien