for the first my thank goes out to chadders, Lord Tocharian, BlackBart, turbobri and everyone i forgot from the original Encrypted Root File System, Swap, etc... thread. They have most of the work done i describe here. I only had a few problems and had to do several changes. also the thread is now 12 pages long so it's a little hard to get everything that is in it and i wanted to summarize what they wrote on several pages.
I had the experience that the old tutorial wasn't gentoo related in that case that it did not work with gentoo related enabled stuff, like the kernel setting to mount devfs at boot (correct me if i'm wrong). Ok, enough introduction!

if you have /dev file system support in your kernel and enabled the option to mount at boot (as it is suggested in the gentoo installation doc) then continue. else have a look at the old tutorial.
Note: since udev requires disabling devfs in the kernel, i updated the tutorial so that it works now with or without devfs. the settings should be the same for 2.4 and 2.6 kernel versions.

And it is never wrong to have a look at the loop-AES.readme where you can find many useful informations.

Ok, the tutorial is divided into two, one if you want to encrypt a clean install and one if you want to encrypt your current root partition. the requirements are needed for both!

The steps1. Requirements2. Encrypt your current root partition3. Encrypt your current root partition using a gpg encrypted key4. Encrypt a clean root partition while installing gentoo5. Setting up an encrypted swap partition6. How to merge the bootsplash initrd and the loop-AES initrd into one7. If something has gone wrong

- get the latest util-linux (at the moment it is util-linux-2.12) from a gentoo mirror or from kernel.org.
util-linux is also in the portage tree but you have to patch util-linux and i dont know if the ebuild of util-linux contains an entry for the patch. haven't tried it yet but you can try it.

- get a knoppix (kde) .iso from one of the mirrors and burn it. i think you can also use gnoppix (gnome).
Note: i experienced that at least the latest gnoppix version does not work, so you have to use knoppix until now!

- decide wether you want to build loop AES as module or to build it directly into the kernel. i would really suggest not to use the module for example because you have to disable loopback device completely in your kernel config if you use the module. If you want to encrypt your root partition with a 2.6 kernel, there is no need to patch the kernel or to build modules, cause it has already built-in cryptoloop support.

if you have a 2.4 kernel, choose either to patch the kernel with loop-aes 2a1) or to use the module 2a2)!
If you have a 2.6 kernel continue with 2a3), cause 2.6 has already built-in cryptoloop support!

extract the loop-AES archive in a temporary folder, for example /tmp/enc.

2a1) patching your current 2.4 kernel and rebuilding it
go to the kernel directory, patch the kernel rebuild and install it.

Pseudo filesystems --->
[*] /proc file system support
[*] /dev file system support (OBSOLETE) <---- Note: As far as i know, you have to disable this to use the new udev system. you can do this, but look for the modifications at the ramdisk you will create later [choose step 2c2) instead of 2c1)]! I have NOT tested this yet for success, so i suggest to create 2 kernels and two ramdisks (one with devfs and one without) to be sure, that you at least can boot your system with devfs enabled. but i'm very sure that both methods work, cause the difference between the two options are very obvious.
[*] Automatically mount at boot

you can either reboot now to make sure your kernel works or directly boot from the knoppix cd if you are sure the new kernel DOES work!!! continue with step 2b).

2b) install util-linux

you can try to emerge util-linux but as i said at the beginnig there is no guarantee that it will work cause i dunno whether it is patched or not. here is the manual method:
Note: i experienced, that the util-linux from the portage tree doesn't work. you have to install it manually, cause the one from the portage tree does not contain the loop-AES patches.

if you rebooted earlier then mount /boot again.

- extract the util-linux archive into the /tmp/enc/loop-AES-v2.0d/ directory and cd into it (cd /tmp/enc/loop-AES-v2.0d/util-linux-2.12/)
- then type the following commands:

- edit build-initrd.sh:
- replace BOOTDEV, BOOTTYPE, CRYPTOROOT, ROOTTYPE and CYPHERTYPE with the things you want i suggest to use AES128 instead of AES256. Because of the fact that 128 isn't to hack with bruteforce, 256 isn't more safe. and 256 is about 25% slower than 128 according to some tutorials and to other people.
do NOT use the normal disk/partition descriptions (/dev/hda1 ...) in BOOTDEV and CRYPTOROOT! you have to use the dev descriptions: so for example if /dev/hda1 is your /boot partition then replace it with BOOTDEV=/dev/discs/disc0/part1 etc ...
- change USEMODULE to 0 if you choosed to patch the kernel or if you encrypt a 2.6 system. leave it at 1 if you choosed to use the module instead of patching.
- change USEPIVOT to 1.
- change USEDEVFS to 1.
- save the file.
- type sh build-initrd.sh
this will build the ramdisk and copy it over (including some tools) to /boot. again, be sure /boot is mounted!!

2c2)creating the ramdisk with devfs disabled in the kernel

- edit build-initrd.sh:
- replace BOOTDEV, BOOTTYPE, CRYPTOROOT, ROOTTYPE and CYPHERTYPE with the things you want i suggest to use AES128 instead of AES256. Because of the fact that 128 isn't to hack with bruteforce, 256 isn't more safe. and 256 is about 25% slower than 128 according to some tutorials and to other people.
in this case you can use the normal disk/partition descriptions (/dev/hda1 ...) in BOOTDEV and CRYPTOROOT.
- change USEMODULE to 0 if you choosed to patch the kernel or if you encrypt a 2.4 or 2.6 system with the kernel loop device. leave it at 1 if you choosed to use the module.
- change USEPIVOT to 1.
- change USEDEVFS to 0.
- save the file.
- type sh build-initrd.sh
this will build the ramdisk and copy it over (including some tools) to /boot. again, be sure /boot is mounted!!

2d) modifying /etc/fstab

- replace your root partition with loop5. for example if you have /dev/hda3 as root, then replace it with /dev/loop5.

of course, leave other changes that you need as they are. for example if you have hdc=ide-scsi etc in your kernel line leave it where it is.
only one thing: if you have bootsplash at boot enabled and you so have the initrd on your boot partition and the line in your grub.conf then you have to remove it.
Until now i don't know how to load two ramdisks at the same time or how to merge them into one. But let me know if you have a solution for that problem!

2f) encrypting your root partition with the help of knoppix

- reboot now with your earlier burned knoppix cd. you can type knoppix 2 at boot so that X will not be loaded and you'll only get a shell. it is a little bit faster but in fact doesn't matter.
- type the following:

Code:

losetup -e AES128 -T /dev/loop0 /dev/hda2

- replace 128 with the encryption you choosed to use earlier in the build-initrd.sh and hda2 with your root partition.
- then enter a passphrase you want to use.
- then convert your root partition:

Code:

dd if=/dev/hda2 of=/dev/loop0 bs=64k conv=notrunc

don't worry this can last a few hours if your root partition is big so as long as your hdd light flashes, everything goes right.

2g) rebooting and starting with your new encrypted root partition.

- when the convertion process is finished, type reboot, remove the knoppix cd and start with the new encrypted root partition. if everything went well, it will asks you for a password while the boot process.

3. Encrypt your current root partition using a gpg encrypted key.

Lord Tocharian wrote:

I have been playing around with encryption and by using hulk2nd's great guide along with the loop-AES.README I have setup an encrypted root partition using a gpg encrypted key. I thought I would add on to his guide with how I setup my system.

All I basically did is put the loop-AES.README into an easier to read format. I would highly suggest reading the entire thing before attempting to encrypt your hard drive. Also a current backup of your hard drive definitely helps.

3j) Build /boot/initrd.gz
Follow the bottom part of 2c) create the ramdisk to setup and execute your build-initrd.sh with the following changes:
-change USEGPGKEY to 1
-leave USEMODULE set to 1
I would note that I have used both AES128 and AES256 on the same system at different times and in my desktop usage I noticed no difference between the two as far as slow down.

3k) Modify /etc/fstab
Use the same procedure as in 2d) modifying /etc/fstab

3l) Edit grub.conf / lilo.conf
Use the same procedure as in 2e) modifying your grub.conf
NOTE: if you use lilo read the top of build-initrd.sh for instructions on how to setup lilo

3m) Do the actual encryption using some sort of bootable CD:
First reboot onto Knoppix/Gentoo LiveCD or some other form of bootable CD so your root partition will not be mounted. Then do the following steps:

Note: The whole step 3) has not been tested by myself, but since Lord Tocharian sucessfully used this method, before he wrote this update here, there is no doubt that it should work this way! Thanks to Lord Tocharian for writing this addon.

- boot your pc with the knoppix cd (type knoppix 2 at boot to get a console only).
- bring up your network and enable hdparm (optional) like it is described in the installation doc, then create your partitions and the filesystems you want.
- create your boot, swap and root partitions
- type the following:

Code:

losetup -e AES128 -T /dev/loop0 /dev/hda3

- replace 128 with the encryption you want to use and hda3 with your root partition and then enter a passphrase you want to use.
- format your root partition with the filesystem you want to use.

- when you get to "15. Modifying /etc/fstab for your machine" in the gentoo install doc, go up be sure to add the changes that were mentioned in:
2d) modifying /etc/fstab

- when you get to "16. Installing the kernel and system logger", be sure to add the modifications that were meant in:
2a) (re)compile your kernel as following:

- after you did the whole "16. Installing the kernel and system logger" step, do the following steps from this doc:
2b) install util-linux2c) create the ramdisk (and optional the loop module)

- after that, continue with step "17. Installing miscellaneous necessary packages" from the gentoo doc until you get to step "23. Configure a Bootloader".
- follow the instructions from the gentoo doc and add the changes from
2e) modifying your grub.conf

- do the end of the gentoo installation doc and everything should work after you reboot.

5. Setting up an encrypted swap partition

- first you need to swapoff your current swap partition. i will always write /dev/hda3 for the swap partition so replace hda3 with your actual partition, as usual.

Code:

swapoff /dev/hda3

- now add "loop=/dev/loop6" and "encryption=AES128" to the swap line in your /etc/fstab. for example:

Code:

/dev/hda3 none swap sw,loop=/dev/loop6,encryption=AES128 0 0

- if there is old unencrypted data on the swap partition, run the following commands

Code:

dd if=/dev/zero of=/dev/hda3 bs=64k conv=notrunc
mkswap /dev/hda3

That should it be. If everything went right, you should now be able to reboot and enjoy your newly encrypted root and swap partition!!!

6. How to merge the bootsplash initrd and the loop-AES initrd into one

i finally got it working to use both, the bootsplash AND the loop-AES ramdisk.
- First, mount /boot and create the bootsplash ramdisk as explained in the howto.
- i would suggest to backup both ramdisks so that you can go back to the old state when something goes wrong.
- cd /boot ant type ls to double check that the initrd-1280x1024 (bootsplash) and the initrd.gz (loop-AES) ramdisks exist.
- extract the loop-AES ramdisk and merge it with the bootsplash ramdisk into one:

P.S. Richard Dean Anderson is awesome! Did you know about Young Macgyver? Unfortunately the WB didn't pick it up .

hi there,

no i've actually never heard of the young macgyver. i would really like to see a picture. but i hardly can belive that he is able do invent that many incredible machines like "the old macgyver" is able to. and that he can beat every enemy while staying THAT polite!!!!

I'm probably going to try this on my new computer when all it's parts arrive.
A question though. I read a bit about encryption and apprently it keeps everything in RAM encrypted, and decrypts it in RAM as it's being used. Does this process take up memory? How much about? Does it slow things down, or will it not be noticible?

i bet it does slow down things, but unitl now i don't have experienced speed differences between before and after encryption. as far as i know, only the ram disk is in ram but that is only a few kb. it really doesn't matter. but im not 100% sure about that.

AFAIK, the data in RAM is not encrypted. Data on the hard drive and data written to swap is encrypted but the RAM access is handled normally. This is not much of a problem though since the RAM is cleared at power off and old data isn't recoverable.

As far as the speed goes, my system is basically as fast as before encryption. Programs load as fast, games run the same. The only time you notice the encryption is in transferring large files between drives -- there is about a 25% processor usage (2GHz Athlon, transferring between u160 SCSI drives).

A cool thing to do if you have a USB bootable motherboard is have your /boot partition on a USB pen drive, then
everything on your hard disks would be encrypted (as opposed to an unencrypted boot on the drive). Unfortunately, my nForce 2 board does not have this feature.

Sorry, made a typo, meant to say that everything on the hard drive (not RAM) is encrypted and it decrypts it in RAM.

If I do this, it will be for a home server (web, ftp, file and other) that will be up 24/7. Will the RAM get more clogged as time goes on or does it compensate? It will only have 256mb of pc100 RAM per node, which brings me to another question. It's a 4u setup with 4 SBC motherboards with 733mhz P3's. 3 of these will be diskless thin clients to one fat client with a 180gb HD. These clients won't have any troubles will they? (btw, I'm going to use openMosix clustering also, if that matters)
Thanks.

I haven't read the code to figure out exactly what the encryption utilities are doing, but it's probably using a minimal amount of RAM to decrypt your data which is then stored (decrypted) in memory as normal.

On my personal box I've had no noticable differences in memory usage when using loopback 256bit AES as compared to no encryption(uptimes up to a month, 512MB). My IDS box running snort, ACID, apache, and ssh had a 163 day uptime until I rebooted for a kernel upgrade yesterday, and it was still running as quick as ever (1GB).

I doubt you'd see any real memory usage increases on your cluster. The only thing to keep in mind is the increased processor usage when transferring large files across a fast link, but even this is fine for the added security.

as you know, even if cou can't boot a computer cause you don't have the root or the user password, you can connect the hard drive to another computer and read the data from there. with an encrypted filesystem this is impossible unless you know the encryption password etc ...
and if the encryption is high or/and secure enough, you can't hack it by bruteforce or other methods.
of course, the way i describe it here is not the safest possible one. but there is a point where you have to think if more security steps are really needed.
i personally own a laptop and thats the reason why i encrypted my partitions cause i don't want other people to be able to read my data if i lose my laptop or if it gets stolen.

as you know, even if cou can't boot a computer cause you don't have the root or the user password, you can connect the hard drive to another computer and read the data from there. with an encrypted filesystem this is impossible unless you know the encryption password etc ...
and if the encryption is high or/and secure enough, you can't hack it by bruteforce or other methods.
of course, the way i describe it here is not the safest possible one. but there is a point where you have to think if more security steps are really needed.
i personally own a laptop and thats the reason why i encrypted my partitions cause i don't want other people to be able to read my data if i lose my laptop or if it gets stolen.

greets,
hulk

Sweet, I'm going to buy a laptop soon...now I know to encrypt the partitions. Thanks!

> Is there a point to using loop-AES with kernel-2.6? CryptoAPI is in the kernel.
> Why not just use it?

1) Loop-AES is about twice as fast on modern x86 boxes.
2) Kernel 2.6 cryptoloop will not work properly with encrypted swap.
Encrypted swap needs memory pre-allocation.
3) kerneli.org and mainline versions are more than two years behind in
security. Both have exploitable vulnerability that is best described as
back door.
4) Uncounted number of bugs fixed in loop-AES that still bite mainline.
5) If Andrew Morton's loop changes get merged to mainline loop, kernel 2.6
cryptoloop will no longer work reliably with journaled file systems.
(same why reason I don't recommend using journaled file systems with
file backed loops)

So, this means that even if you're running kernel 2.6 you still should patch it with loop-AES. I haven't tried patching 2.6 with the new loop-AES. But it is possible. This is the announcement from the linux-crypto mailing list:

Quote:

loop-AES changes since previous release:
- Fixed util-linux patch so it compiles on boxes where C library is compiled
against 2.6 kernel headers.
- Fixed SMP race that could corrupt data if all following conditions are
met: (1) loop device is in multi-key mode, (2) SMP or UP+PREEMPT box, (3)
shared writable mappings to a file, (4) memory mapped file data modified
at same time as that same data is being encrypted inside loop transfer
function, and (5) unclean shutdown so that re-dirtied page won't get
written again.

Additional ciphers package changes since previous release:
- Fixed SMP race in loop_twofish and loop_serpent modules that could corrupt
data if all following conditions are met: (1) loop device is in multi-key
mode, (2) SMP or UP+PREEMPT box, (3) shared writable mappings to a file,
(4) memory mapped file data modified at same time as that same data is
being encrypted inside loop transfer function, and (5) unclean shutdown so
that re-dirtied page won't get written again.

ahh, there is no need to patch the kernel. first, the archive isn't a patch anyway, it just builds the module. and second, this only updates serpent, twofish and blowfish encryption, i think. cause it builds only loop_twofish.o, loop_blowfish.o and loop_serpent.o. and since we use aes, i don't think we need to build these modules.

I'm thinking that when I upgrade my kernel (down the road) it will just be a matter of repacing the bzImage and that's it. Does that sound right?

Now I just need to figure out how to make this work with a gpg key on a usb stick... when and if I get the money for that I'll probably give it a shot. If anybody wanted to write a howto for that that would be even cooler.

I'm not sure I have the expertise to write an ebuild for the modified util-linux, but if I (or somebody) did would it be an appropriate thing to put into portage?

Perhaps you should submit the whole clean install onto an encrypted partition procedure to the alternative install guide.