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.
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.
It would be convinient if you could have multiple entries in fstab share the same password, for now a little shell script will do (also because Aurora doesn't support text input yet).
Monkey sense
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!
good thing that you have the ultra-secure, no government backdoors UBER-MS encryption there, right...
sigh...
"its encrypted because we say it is, and trust us on that"
... hi bingo
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
Sorry to everyone who was offended by my last comment in this post. I did in fact mean to help, but I just though that the original submitter of this Ask /. question could have done a little more work figuring this out. Hell, even I managed to get my file systems encrypted with that outdated HOWTO.
Nonetheless, I'm sorry for spoiling something informative with some elitist babble. It's just a knee-jerk reaction from time to time.
Why bother.
Rubberhose doesn't give you deniability.
The presence of Rubberhose software and a huge segment of random noise on the disk is going to be enough to convince a court that you have a Rubberhose partition.
The suggested "create 1GB of noise and then put two partitions in it, and just say you've got one" isn't going to work either. The court is gonna say "oh, you've got 1GB of noise according to our expert, but only a 300MB partition with nothing incriminating on it? Yeah, right, buddy; gimme the password for the other 700MB partition or you can rot in jail on contempt".
Even a couple megs of "unused" space is going to be taken as a sign you've got a small partition hidden, if you've got Rubberhose software on the system to access it.
Steganography only works when the carrier files have utility beyond that of the hypothetical encrypted information.
The only way you'll ever be sure is if you write your own
Or get the source code for an existing cryptographic application and audit it. A good programmer and a good mathematician working together could probably produce a reasonably trustworthy audit of the cryptographic functions in a given application.
Of course, this requires that the source code be availble for inspection and that the code can be compiled for actual use in the production environment. It's pointless to audit source code that is then carried off and you are subsequently handed a binary-only application "supposedly" based on the audited code.
If you're a zombie and you know it, bite your friend!