I have public yum RPM repositories. Put these entries in your yum.conf file to access them.
Alternatively, you can browse my repositories via http.
(Last updated: 2004-04-09)
Unfortunately, at the moment, I've found no satisfactory method to get this working.
For Red Hat Linux 9, getting encrypted loopback devices working
required only a patch to util-linux. (See bug
56698 for the gory details.) This was because Red Hat had added
the unofficial
CryptoAPI patch to their kernel.
However, the CryptoAPI patches were officially integrated into the kernel as of 2.6.0-pre2, and then backported to 2.4.22. As a result, Red Hat removed their CryptoAPI patches from Fedora Core 1.
Additionally, util-linux 2.12 was released, which integrates the patches necessary to support encrypted loopback devices.
So, everything should be simple now, right? Well, not quite...
FC1 shipped with util-linux-2.11y instead of util-linux-2.12.
The official backport of CryptoAPI to the 2.4.22 kernel doesn't include the cryptoloop glue that is needed to support encrypted loopback devices.
util-linux-2.12 lacks hashing functions, so you need to hash your pass phrases with an external program and feed them to losetup. But the -p option to losetup is broken in util-linux-2.12.
Problems #1 and #3 can be fixed by upgrading to util-linux-2.12 and installing the hashalot program, respectively.
But problem #2 is a sticking point. I had previously cleaned up a patch that could be added to kernel-2.4.22-1.2115.nptl.src.rpm that would provide the missing cryptoloop glue. However, kernel-2.4.22-1.2115 contains security vulnerabilities and should not be used. Moreover, I haven't been able to come up with a working patch against the latest errata kernel.
(For the curious, the problem is that certain parts of the kernel build process are invoking commands with very long arguments. My patch makes at least some of those argument lists too long, which causes the kernel build process to die with Arg list too long errors. The solution is to change the kernel build process to use xargs, but changing the kernel build process is highly non-trivial.)
Since the 2.6 development kernels do contain the cryptoloop glue that is missing in the 2.4 kernel, I next tested using a 2.6 development kernel, thus avoiding the issue of rebuilding the 2.4 kernels entirely. But that didn't work either: the system calls that losetup invoked failed. Sine the same system calls worked when running a 2.4 kernel with the cryptoloop glue patches, my guess is that there's some problem with how the cryptoloop glue patches were integrated into the 2.6 kernel.
So, unfortunately, I still don't have a solution for getting encrypted loopback devices working in Fedora Core 1. While I think I could resolve these issues is I put a lot of effort into it, based on what's happened recently (keep reading), that would be pointless.
(Updated 2004-04-13: cryptsetup-0.1-0.1 now builds correctly with device-mapper-1.00.14-1.0.)
Starting with the 2.6.4 kernel, cryptoloop has been replaced with dm-crypt, which is a device-mapper crypto target.
(If you haven't already done so, please go read Christophe Saout's explanation of dm-crypt.)
Ok, so what do you need to get this working under FC2 test2? Simple: you need Christophe's cryptsetup program. (Ok, you don't strictly need cryptsetup, but it's a real pain using dmsetup directly.)
Note that you do not need a 2.6.4 kernel; the kernel that FC2 test2 shipped with (2.6.3-2.1.253.2.1) contains dm-crypt and works just fine.
Christophe's cryptsetup program requires at least version 1.1.42 of libgcrypt, which is newer than what Red Hat provides. The newer version of libgcrypt requires the libgpg-error package. Hopefully, Red Hat will integrate these packages into FC2. But until then, I've built them myself. You can either pull them from my yum repository, or download them directly:
binary RPMs:
source RPMs:
I highly encourage you to pull the SRPM packages and verify that I haven't taken any malicious actions with them!
Once you've [built and] installed the above packages, here's a quick recipe for accessing existing cryptoloop filesystems that you've created.
First, make sure the necessary device entries exist:
Then make sure the necessary modules are loaded:
Finally, setup the loopback device, and then stack the dm-crypt device on top of it:
(The defaults are AES with a 256 bit key hashed using ripemd160, which is exactly what the 2.4 cryptoloop patches used. So, if you weren't using a 256-bit keysize, you will need to use the -s option to tell cryptsetup the proper keysize.)
That's it. Now, you can treat /dev/mapper/test like any other block device: you can run mke2fs on it, mount it, etc.
To cleanly shut down the dm-crypt device, run these commands:
Is this a change from how things worked using cryptoloop? Most definitely. It it worth it? Most definitely. Divorcing encrypted block devices from loopback devices means that you don't have to create a loopback device in order to encrypt it; you can stack encrypted devices on top of regular block devices (e.g., disk partitions).
As a really neat example, you can easily create an encrypted swap partition using cryptsetup. Assuming that you've reserved /dev/hda5 to use as a swap partition, and your system has been running awhile to gather entropy, manually run these commands:
WARNING: do not put the above lines in your /etc/rc.d/rc.sysinit file. That's because the way the init scripts are currently set up, swap partitions are activated before the saved entropy is fed back into the random number generator. As a result, data read from /dev/urandom in /etc/rc.d/rc.sysinit will be pathetically deterministic.
Standard disclaimers apply: this stuff works for me, but I make absolutely no guarantees. Test everything yourself before you even think of trusting it.
You can go to my home page.
You can validate this page using the W3C HTML Validation Service.