4) The Knoppix (or Knoppix lite) CD from http://www.knoppix.net . Burn it to a CD and make sure you can boot from it. Knoppix is great rescue system and I use it it alot to fix stuff when I mess up bad. Knoppix comes with loop-AES already on it so you don't need to make your own rescue system. This is important later because to encrypt a root file system you can't be running on it at the same time.

How to do it steps
--------------------

1) Recompile your kernel. You HAVE to use CONFIG_MODULES=y, CONFIG_BLK_DEV_LOOP=n (y or m WONT WORK), CONFIG_BLK_DEV_RAM=y, CONFIG_BLK_DEV_RAM_SIZE=4096, CONFIG_BLK_DEV_INITRD=y, CONFIG_MINIX_FS=Y (this is because the ramdisk is minix), CONFIG_PROC_FS=y plus whateve FILESYSTEM YOUR ROOT IS HAS TO BE Y (modules wont work because the kernel can't get modules from the root file system until it knows how to read it and decrypt it when it is booting, other stuff can be modules if you want). Make sure that your new kernel works before going further.

2) cd to /usr/src and untar the loop-AES tar file. Type make. This makes a new loop device driver that knows how to encrypt and uncrypt stuff.

4) In the loop-AES directory edit build-initrd.sh. Change BOOTDEV, BOOTTYPE, CRYPTROOT, ROOTYPE and CIPHERTYPE to what you want. Then type sh build-initrd.sh . This makes a ramdisk so that the kernel knows how to get the pass phrase when you boot later.

5) Boot the knoppix CD. Type knoppix 2 so you get a root shell and not everything else because it makes it slow. Type this stuff:

losetup -e AES256 -T /dev/loop0 /dev/hda2 (or whatever is your root partition)
give the secret pass phrase that you want (DONT FORGET WHAT IT IS!)
dd if=/dev/hda2 of=/dev/loop0 bs=64k conv=notrunc (this will take a while if the partition is real big SO DONT WORRY)

Reboot (TAKE OUT THE KNOPPIX CD) and tell grub you want the Encrypted Root and it will start booting then ask you for your secret pass phrase and EVERYTHING WORKS GREAT!

If it doesnt work it means that you did something wrong so then boot the knoppix cd again and do the losetup (FROM #6 LOOK UP A FEW LINES) again (DONT DO THE DD AGAIN NO MATTER WHAT) and mount it and then read the loop-AES README to find out what got messed up.

It is easy to encrypt swap and other partitions to. Read the loop-AES README!

Hope you like it!!!
Chad

Last edited by chadders on Sat Jul 05, 2003 4:47 pm; edited 1 time in total

Only got one question. Whats the overhead for running a encrypted file system?_________________If Microsoft really wanted to kill open source, they'd put you all in the same room together with weapons and tequila.
-- John Jasen, LKML

I think it is pretty fast because I did a emerge -u world with the stage3 and all of GRP packages and it took about a whole day BEFORE encrypted root. Then i messed up bad and had to load everything again and this time I did a emerge -u world AFTER encrypted root and it still took a whole day but not two days. I think its a little bit slower but not a lot slower. I dont know exactly when it gets done because sometimes it gets done when im sleeping or at school.

I didn't keep good track because I was kinda mad at myself for messing it up.

When i browse and xchat and stuff like that it is about the same I can't tell the difference.

I used XFS for encrypted root. I tried REISERFS and EXT3 before. I think I like XFS best but it probably doesn't make very much difference because I can't tell if one is faster or not. I don't know very much about filesystem stuff yet but I am working on that. If you know that one is better please tell me so that I can try it out.

That is hard because I have a crappy computer and its kinda old and not very fast and not a very big disk drive with no space for another partition on it. Changing the encrypted root partition from one kind of filesystem to another kind takes me 2 days each time because I have to reinstall gentoo.

We have another computer thats real fast but its my dads and he wont let me use it anymore because he says im to dangerous.

just woke up and leaving for class in like 5 minutes, so i must make this brief.

i understand your problem and would be willing to head up an effort to benchmark the different FS's while encrypted; however i cannot do it alone... (to anyone reading this) if you would like to help in the testing of the filesystems (note, you dont have to convert your root FS to test it in this fasion, but it would be more accurate that way), please contact me by using the phpbb (these forums) contact methods

I'd be willing to help benchmark the speed difference. I got a spare Dual PIII 1GHz with 512 Ram at home thats not doing anything and some time to kill . I can start some unencrypted benchmarks tonight and maybe some of the encrypted._________________If Microsoft really wanted to kill open source, they'd put you all in the same room together with weapons and tequila.
-- John Jasen, LKML

A simple compile of the kernel is not a good test of FS performance. Since with enough memory most of the files would be cached in buffers. Their are plenty of real fs benchmarking utils out there that would be more appropriate.

I can think of much more interesting reason to encrypt you r entire filesystem than keeping mp3's away from your family members. My fileserver would already be encrypted, but a p200 is not exactly well suited for the job.

I've always wanted to do this, but I've never gotten around to it. (or I guess I've never had a gun put to my head and told "make an encrypted filesystem setup in 5 minutes") Now, I'm running LVM.. expandable, shrinkable, etc. This is great for static partitions, but what would really be spack-dang-tacular if something like this was built into the IO of the kernel somehow to be independent of loopback.

My manager about 3-4 years back did this, and it was awesome though. (with slackware I believe it was) He ran it on a Pentium 400 or so, and it ran just like normal.

on topic: i use evms (atop lvm), so i dont know if that will contribute to the quickness or slowness of the system, although i ****highly**** doubt it will slow it down due to the fact that evms is kernel lowlevel (iirc)

side note: evms has everything else, now they need to implement an "encrypt" function

/me hounds IBM

also: if a moderator comes accross this, you can feel free to split the discussion of benchmarking, etc. to a new topic as it feels as though we are deviating a wee bit too much to me.

make modules KDIR=/usr/src/linux CDIR=/root/crypoapi-0.1.0
make modules_install

In this way I didn't even need to patch and recompile my kernel.

Then I added to my modules.autoload the needed modules:
cryptoloop
cryptoapi
cipher-twofish (you can choose as many ciphers you want)

then I have built a couple of perl scripts...
The first one acts like a server and runs on a server machine.
The second one queries the server from the client and mounts a crypto filesystem on demand of the user (it can be added to ~/.bashrc to do that automatically at login) getting the needed password from the server (I prefer not to store the password in the local filesystem for security problems).
All the communication between server and client is crypted with perl modules Crypt::Blowfish and Crypt::CBC.

I can publish the scripts on demand. But what do you think of my solution?_________________Linux!

This kid has pulled off something that few fully appreciate, including himself in all likelihood. He has encrypted his root filesystem and by inference ALL of his other partitions (except a small Boot) as well.

That means that there is no information whatsoever available to attackers who may gain physical access to the machine. No logs, no software configuration information (registry/gconf and so forth), no deleted files, no hidden application files, no browser cookies, no residual trash on swap, nothing.

Perhaps someone could gain his pass phrases by attaching a hardware keystroke logger... and even then there are options, such as a GnuPG keyring on a diskette. I would hate to be the corporate spy (or law enforcement official) trying to extract useful information from such machine.

This configuration is perfect for laptop computers that might "walk away". Even windows users can benefit... Imagine a copy of Windows XP under VMware with the XP virtual disks themselves hosted beneath an encrypted filesystem. It would be impossible to determine that XP even existed on the box.

should your computer be seized by the government, the harddrives are useless to them (unless they can crack a theoretically uncrackable password), noone can access your files unless you want them to, and general security.

I have it working also. Chadder's instructions are adequate, especially when backed up by the loop-AES README material.

My experience with performance is very encouraging. The performance hit is much MUCH less than I anticipated across all filesystems. This is probably a result of how well the fs buffers data thus avoiding disk access (an corresponding encryption overhead).

IMHO, multiple passes compiling the kernel is not a very helpful benchmark. However, it does illustrate how trivially small the performance impact is on machines that are not memory constrained.

One caveat to the install, be sure *not* to have the filesystem mounted at the time the dd if=/dev/hda? of=/dev/loop? initially encrypts the partition. The unmount which will inevitably follow writes a few blocks of meta data (in the clear) which will damage the partition and may leave it unrecoverable.

An earlier post (contigab) made the comment that similar results can be achieved using modules taken from the cryptoloop package. If the similar result is an encrypted "root" filesystem then additional work is needed. The kernel will not have access to the root file system to retrieve the encryption module untilt he encryption module is retrieved... a chicken and egg problem. This is the reason that an intermediate root (initrd=/dev/ram) is required to boot. Contigab handles encrypted home, etc, very well and is useful, but does not appear to handle the encrypted root case. The original loop-AES post that started this thread does address this.

I was doing the dd if/of part when something crashed =( System hard-locked. I think it's related to my SCSI card, though it's possible it could be related to ram but ... my kernel compiles have been going just fine, no weird errors...no odd panics or anything ... ever.

Well, I'm gonna try again. I'm always looking for a reason to reinstall anyways. =) Hey, I get to try the new live cd out now!

Well I followed chadders instructions and it all seemed to work as described. That is until I tried to do the final reboot into my newly encrypted root. It never asked me for a password on boot and the system quickly halted with a kernel panic.

I rebooted with Knoppix and was able to losetup and mount the encrypted partition, and everything seems to be in tact. All the necessary files are in the /boot partition, and my grub.conf looks ok. The only thing that was different was that I was using an older version of Knoppix and losetup did not recognize the -T option, so I omitted it. Any suggestions?

It sounds like it couldn't find the initrd.gz ram disk (because it didn't ask for the pass phrase). Look in build-initrd.gz in the loop-AES directory and follow the instructions EXACTLY. Especially the part about what to put in LILO or GRUB.

I don't think the -T on the losetup would mess it up it just means prompt for the passphrase two times.