The last days I've written a target for the device-mapper in the 2.5
kernel that uses the in-kernel cryptoapi to do transparent encryption on
a block device.

It works for me and doesn't show any strange corruptions. Joe (the
device-mapper guy) also looked over it and made some modifications. 


The target doesn't have any special user space tool yet, so you have to
use the dmsetup tool (in the libdevmapper-1.0 package you'll find on the
Sistina ftp server) to set up an encrypted device. It also means that it
doesn't store a passhrase encrypted key, you'll have to directly specify
the key for the symmetric encryption/decrypt operation.

With the dmsetup tool you can create a device like this:

dmsetup create <device name> <table file>

The device will be created in /dev/mapper/<device name> and can be
removed with "dmsetup remove <device name>".

The table file can contain several lines, but if you just want a device
that doesn't use several other devices as backend (like LVM can do),
specifying only one line is fine. The syntax for the crypt target is:

<cipher> <key> <iv_offset> <dev_path> <start>

<cipher> is one of the ciphers in the cryptoapi like aes or des. You can
optionally specify the block chaining mode like "aes-cbc" or "aes-ecb"
(inspired by cryptoloop, but no copied code). The CBC mode is the
default, but it doesn't really do cipher block chaining, it only
additonally perturbs the encryption by munging the sector number so that
the same sector gets always encrypted differently, like zero-filled
ones.

<key> is the actual key. It's hex encrypted, two digits per byte.

<iv_offset> is used with CBC and you can specify a sector offset for the
perturbation. For example if you want to map only a part of your
encrypted device and start at some offset, you can specify it here, so
that you're still able to read your data.

<dev_path> is the device path of the device you want to encrypt (can
also be a loop device if you want to test things on a file).

<start> is the sector offset in the device where you want the mapping to
start.

So a complete line for the table file might look like:

0 204800 crypt aes 0123456789abcdef0123456789abcdef 0 /dev/hda7 0

(the second parameter is the size of the device you want to create in
sectors, this would give a 100 MB device).

If something fails look into your log file (and don't forget to remove
the device that was created with dmsetup remove <devname>).


My tests suggest that it's fairly stable. I've created different
filesystems on it (ext2, ext3, reiserfs) and did a lot of copy
operations from/to/on it. A lot of small files, large files.
Unmounting/remounting, etc... I didn't find any corruptions.
It even works when putting swap space on it and it didn't deadlock my
machine under extreme memory pressure.
I also added a lot of temporary debug statements and poisoning code to
make sure that allocations and frees are correctly balanced.


The attached patch adds a dm-daemon.c/.h, this is a forward-ported
version from 2.4 and the actual dm-crypt.c.
It can be compiled in statically or as a module (kernel configuration:
Multiple Devices -> Device mapper -> crypt target).

The patch should apply cleanly on top of 2.6.0-test1. I've appended it
as an attachement because my mailer adds additional newlines. :(

--
Christophe Saout <christophe@saout.de>
Please avoid sending me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html