Seeking Current Info on Linux Encrypted FS? 297
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.
FreeBSD & NFS (Score:5, Insightful)
It's Really Pretty Trivial (Score:5, Insightful)
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
Re:It's Really Pretty Trivial (Score:2, Insightful)
Right.
That kind of attitude will really encourage people in general to use Linux and encryption on a daily basis...
Re:SuSE does this out of the box... (Score:4, Insightful)
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 [dhs.org] doesn't support text input yet).
I've used it the last 2 years (Score:5, Insightful)
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!
Re:Here is how to do it (Score:4, Insightful)
sigh...
"its encrypted because we say it is, and trust us on that"
encrypted root + warning about crypto in linux 2.4 (Score:5, Insightful)
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...
Apologies (Score:3, Insightful)
Nonetheless, I'm sorry for spoiling something informative with some elitist babble. It's just a knee-jerk reaction from time to time.
Re:It's Really Pretty Trivial (Score:2, Insightful)
Young'un
Maybe he just forgot his password on an encrypted file system that he couldn't mount?
Re:Deniability (Score:4, Insightful)
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.
Re:Here is how to do it (Score:2, Insightful)
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.