Note: This is too lame to be a HOWTO since I just followed directions I found elsewhere,
but I'm so happy I finally got a solid, large encrypted filesystem working under linux that I'm
posting my experience

The Goal

A 100GB encrypted filesystem on a USB2 external drive.

My Trevails

I started with cryptoloop and the cryptoAPI. I had nothing but problems. Looking back, I realize it may
be that I had HIGHMEM set, and I think there are cryptoAPI bugs when that is set. With it set, I had
frequent hard lockups, either working with a block device or a file. I'll chalk it up to HIGHMEM (for
now), though I've read of others' problems. At any rate, cryptoloop looks to be on the way out,
according to http://kerneltrap.org/node/view/2433/ One other thing I don't like about
cryptoloop is that losetup doesn't ask for your password twice. If you pick a good, long passphrase,
you could easily typo it and find yourself unable to access your data.

Next I looked at loop-AES. This package has gotten good reviews, but requires (a) replacing your kernel's
loop module, and (b) patching util-linux (though Gentoo does this for you). I held this as a last resort
(what if I need my loop module for something some day?) and happily, never needed to use it.

Finally, I looked at BestCrypt, a commercial product from Jetico. BestCrypt is very well-documented but
is not free ($50 US after a 30-day trial; they give you the source code, so it's an honor system thing).
I downloaded and tested it, but 1.5.1 didn't work well with my 2.6.3 system. When using a block device,
it ran out of space or gave strange "bogus i_mode" messages in dmesg while attempting to fetch impossible
inodes, which hung the box. When I tried to use containers (of 100Gb size), mkfs would freeze. Since
BestCrypt provides its own kernel modules, I'm going to have to lay the blame at their doorstep. (The
product works very well under Windows, incidentally).

Before 2.6.4, you needed to do some special patches on the -mm tree...that's a little too bleeding edge for me.
But the good news is that 2.6.4-rc1 has dm-crypt support built in. Note: HIGHMEM is still broken in
regard to CryptoAPI/dm-crypt, so don't use it if you want dm-crypt (yes, this sucks - see the dm-crypt page
above for some patches to fix it).

device-mapper is needed for dm, which is an option in the 2.6.4 kernel (under the RAID section).
You will also need hashalot, but that's pretty common (and just emerge hashalot if you don't have it).

After rebuilding the kernel, I downloaded cryptsetup (http://www.saout.de/misc/cryptsetup),
a script that makes working with encrypted volumes really easy. Once downloaded (and chmod'd 755), setting
up the volume is easy. I chose to use AES (The defaults are aes with a 256 bit key, hashed using rmd160):

You'll get a warning that -y isn't implemented yet - see below (I put it in the example in case someone
is cutting/pasting a month from now).

crypsetup will ask you for a password when you run it. Unfortunately, the -y flag, which would ask you
for the password twice, is not implemented yet - a hack is to type your password in an editor somewhere
and cut and paste it, thus insuring that your long string of characters is not typo'd.

The mkfs ran pretty hot in terms of system load - 2 to 2.5 on a 1.6Ghz P-IV. After the filesystem was
built, I started the copy. It cooked along pretty well - I didn't really notice much of a slowdown compared
to a normal copy (though this is USB2, so it's not as fast as writing to a ATA133 anyway The load average
moved between 1 and 2, with 'pdflush' hogging most of it.

When I was finished, it was simply

Code:

umount /data

Yep, that simple.

Status

2.6.4-rc1 has only been out a few days, so this is all barely tested. However, unlike my earlier experiences, I've written tens of gigabytes
of data on top of a dm-crypted filesystem and mounted and unmounted it several times without a problem.

Future Projects

I haven't investigated how to put this in /etc/fstab, but that's my next step.

I don't really see much use for an encrypted root/swap at home (since I'm religious about linking everything
unique *off* of root, such as /var/www, /home, /usr/local, etc.) It would be interesting to play with
dm-crypt on a laptop...but that's a project for another day

I have 2.6.4-rc1 installed and would really like to try this, but the cryptsetup script that you link to no longer exists. Do you think you could post it here?

Cheers,
bluephile

EDIT:
Ah, although archive.org didn't have the page, Google's cache does. I'll be back later with my results!
EDIT2:
Unfortunately, it appears to be older than the one you used, as there is no mention of a -y option anywhere in the script.
EDIT3:
I realized that cryptsetup was linked from the dm-crypt page. They have a new verison of the script (er, program!) now in C: http://www.saout.de/misc/dm-crypt/cryptsetup-0.1.tar.bz2

I've been running my laptop with the entire hard disk encrypted using dm-crypt for over a week now. Works great! I'm using a USB flash drive for my /boot and initrd, roughly following the method described in the Disk-Encryption-HOWTO. I wanted to build a swap device on top of the same encrypted device as my root filesystem and also have flexibility for multiple filesystems, so I'm using lvm2 on top of the encrypted block device. I had to build a custom initrd and linuxrc script to deal with a root filesystem over lvm2 over dm-crypt, but it was fairly straightforward (except for the conflicting documentation regarding what, exactly, the linuxrc script must accomplish). Minimal documentation follows:

Warning: You may destroy your data if you follow these instructions!

First I wrote a mkkey script to create a completely random key for the disk encryption and store the key on my flash drive in an encrypted loop file, protected by a passphrase. Note that all my scripts use the soon to be defunct cryptsetup.sh but should be easily adapted to the new cryptsetup.

Then I backed up my hard drive, double-checked the backup, shredded my hard drive, and built a new partition table. I chose to build my encrypted device on /dev/hda1 (maximum size) rather than /dev/hda just in case a new partition table accidently gets written to the disk or something. Then I wrote a cryptup script to create the encrypted block device:

The above script failed the first time I tried it because lvm2 does not consider device-mapper block devices (such as a dm-crypt device) for use as physical volumes by default. I had to add a line to the devices block in /etc/lvm/lvm.conf:

Code:

types = [ "device-mapper", 16 ]

Now is a good time to verify that the encrypted block device can be remounted correctly, especially because cryptsetup.sh didn't ask for the password twice during setup (thanks to hashalot). First I used cryptdown:

Code:

#!/bin/bash

DMTARGET="pvcrypt"

# 'vgchange -a n' fails if I don't do this first. Not sure why.
# Asking lvm folks about this but no answer yet.
for lv in $(lvs --noheadings | awk '{print $2 "-" $1}'); do
dmsetup remove $lv
done

vgchange -a n vgcrypt

cryptsetup.sh remove $DMTARGET

Then I could run cryptup and vgscan. vgscan found the vgcrypt volume group, so everything worked. Then I copied my old root filesystem onto /dev/vgcrypt/lvroot from the backup and built my initrd in /boot. I copied my keyloop to the initrd and wrote a new linuxrc:

This took a few tries. Setting up all the files necessary to run cryptsetup.sh on the initrd was a bit of a pain but this will be easier with the new cryptsetup. The lvm2 tools also have to be on the initrd along with a customized /etc/lvm/lvm.conf.

I'm trying to follow your instructions, but I'm confused on one major point:

What system are you booted into when you're running cryptsetup, etc.? The LiveCD kernel is too old for device-mapper support, and I don't know how to connect a laptop harddrive to my desktop to set this up with another machine. Please let me know how you did this!

seems like all this thing needs is a bit more time for developers to make util-linux(mount) and alike support this thing... i run cryptsetup from /etc/init.d/local , to mount my disk, this would ofcourse not work for a root/swap partition ;) i would love any hints to do it a easier way though..(hi to bluephile btw, who fixed the compile error in dmconvert for me! :) )

I used catalyst to create a new livecd based on 2.6.4 that included device-mapper, gcrypt, and cryptsetup. I successfully created my encrypted LVM partition, but I'm having trouble with the initrd: the kernel oopses when it boots up before panicing due to being unable to mount root. I've had the same problem with an encrypted root without LVM. I can't figure out how to read what the oops is to try and track down what's wrong. I'm afraid I'm stuck until development of dmcrypt/cryptsetup/etc. progresses somewhat (perhaps it'll include scripts to create the initrd & do this stuff automatically?) and I don't have to figure out why my initrd is failing, unless someone has a suggestion.

Good question! I was using a minimal system installed on a second partition on my hard disk that I failed to mention. Someday it won't be there, but, as I have been on the road constantly over the past few weeks, I'm not quite ready to be without a safety net! I haven't had the time or motivation to use catalyst yet, but I would like to.

I found it useful to use bash or sash as my linuxrc when I was first trying to get my initrd to work. Being able to interact with the process was very helpful for debugging. Have you figured out if the oops is prior to, during, or after linuxrc?

earlier i got the thing mounted... but it startet showing errormsg's after i tried to copy something to it... now, it cant get through mkfs.xfs before showing errors, so i cant mount it.

As i said earlier the disk works perfectly without the encryption.
Anyone got any ideas?

Another question i have in this dm-crypt matter is, when will we see this dm-crypt stuff merging into mount and such, so that the whole matter could be easilier managed(would be a breeze to encrypt root and such), since it's becoming the future in linux disk encryption since 2.6.4 i mean....

I don't know all too much about encryption and modern algorithms, but isn't encrypting the root partition a bit dangerous due to the amount of known plaintext? As long as the intruder knows that you're running Linux, there are quite a few libraries and such that are fairly standard to just about any Linux system. Not to mention those of us like me who've installed the howtos, now theres a lot of plaintext just waiting to be exploited..

There must be something I'm missing here otherwise I'm sure it would've been mentioned long ago.. is known plaintext no longer an issue?

Here is something, although I think that most modern ciphers themselves are not vulnerable to a known plaintext attack. (which is what you are describing) Chaning modes (CFB and CBC) and Initialization Vectors (IV) were invented to prevent this, I think.

I don't know all too much about encryption and modern algorithms, but isn't encrypting the root partition a bit dangerous due to the amount of known plaintext?

The only known plaintext attack I'm aware of that we need to be concerned about is the optimized dictionary attack described in the link provided by tbd. This attack only works if the attacker knows some plaintext, including its exact location on the block device. Even though there is a lot of known plaintext on a root filesystem, very little of it is in a predictable location. That's why the attack in the link targets something in the filesystem header rather than any individual data files within the filesystem.

Personally, I don't trust any IV method to protect me from an optimized dictionary attack, at least not until the method and the specific implementation have undergone significant peer review. That's why my key is a chunk of completely random bits that would never be found in a dictionary. Then I encrypt my key with an easier to remember passphrase. The encrypted block device can't be attacked with an optimized dictionary because the key would not be in anyone's dictionary (even though there is known plaintext on the device); the encrypted key can't be attacked with an optimized dictionary because it contains no known plaintext (even though my passphrase could conceivably be in someone's dictionary).

If someone had both my hard disk (encrypted block device) and my flash device (encrypted key), then they could perform a dictionary attack, but it would be very computationally expensive and could not be optimized for multiple targets.

I already have a partition set up with encryption and mounting provided by the loopback driver. How do I use device-mapper functionality to mount the drive?

Note that I only want to mount an existing encrypted filesystem with this new method, I do NOT want to have to reformat or reencrypt. In fact, the first time I want to mount it read-only so I can make sure I'm not going to lose my home dir.

About halfway down the page is a section about migration. It looks like dm-crypt can do cryptoloop created by 2.6 kernels. There are a few links to follow from there as well._________________Do you know what a usufruct is?

I have some experience with loop-AES with gpg keys.
but for loop-AES to work perfectly i need to patch util-linux and build a loop.ko module.

is there any reason why i should switch to dm-crypt ?

EDIT: has anyone encrypted their whole harddisk ? how does it work ?
did you guys figure out how to add the encrypted drive to fstab ?_________________Encrypt, lock up everything and duct tape the rest

I have some experience with loop-AES with gpg keys.
but for loop-AES to work perfectly i need to patch util-linux and build a loop.ko module.

is there any reason why i should switch to dm-crypt ?

EDIT: has anyone encrypted their whole harddisk ? how does it work ?
did you guys figure out how to add the encrypted drive to fstab ?

yes there is a good reason to switch to dm-crypt. Because the 2.6 maintainer morton has deprecated the loop-crypt.

To set up the encrypted partitions in fstab you would need to patch your util-linux with the patch located in the mailinglist(for util-linux 2.12 i belive, dunno if this works with a root/swap partition though)

Anyone know how to use dmconvert to encrypt a already existing partition?

I haven't began to do this yet but I have a backup server that a lot of servers backup to. I store all this data on a separate partition, and it's a raid device as well (mirror). Is this going to cause trouble? Do I need to delete the partition before I encrypt it?

One last question, I noticed that when you unmount the drive that you type 'cryptsetup remove crypt' which will make it so that on a reboot, it will still ask for a pass phrase. My question is, what happens if this drive needs to be mounted at all times? I'm guessing that you can still type the cryptsetup command to remove the key even while it's mounted? Otherwise theres no point for me in using this, because if the backup server gets stolen then they will have access to the partition.

Here's a very dirty hack I'm using to encrypt swapspace on bootup with local.start and local.stop

DISCLAIMER: Use at your own risk. This is what I am using on my system, and it works for me, but I can't promise it won't make your hard drive scream in pain or your mouseball to get filled with dust twice as quick. However, I'd highly doubt it could do worse than cause the swap not to work, which could be easily fixed by simply removing this hack, and mkswap on your swap partition again.

/etc/fstab

Code:

/dev/hda9 none swap sw 0 0

I still have an unencrypted swap in my fstab that the kernel activates during bootup. This is most likely not necessary, but I left it just in case it uses swap as it boots.