Hi there.
I still dream about suspend to loop device. But the only one thing I've found is a patch for 2.6.0 kernel supposed to work only with built-in swsusp, not the one from swsusp.sourceforge.net.
You can try it out there.
But even so it doesn't compile with kernel-2.6.1. It exits with error.
May be someone has any ideas how to encrypt swsusp?
Currently I'm using encrypted root filesystem with absolutely unencrypted suspend to disk. And it's really a stupid thing... _________________signature sucks

first of all, thanks hulk2nd, great guide. Very simple to use. I have one question that I"m still a little confused about. I already encrypted my root and swap, but I was wondering if I could encrypt another hard drive as well. I read the http://www.ece.cmu.edu/~rholzer/cryptoloop_mini_howto.html
but am still confused. Do I have to use a different loop device from my root partition, or can I just run a command to convert it to the same cryptography as the root drive? It'd be nice if my root encryption password would unlock everything. Do I do it more like the swap space where you don't have to run losetup? Thanks.

I recently decided to put a system of mine that was lying around to some good use and hence decided to set up Gentoo on it as well, but with an encrypted root partition and read-only boot partition on CD-ROM. Using hulk2nd's amazing guide, I got through it quite successfully. Well, almost. The problem arises when I boot the system. Essentially what happens is when it displays the message "Encrypted root filesystem...", it encounters an error and prints

It then continues to do this 5 times and then halts the system. Now, I've checked and rechecked the seed, so there's nothing wrong there. I'm also positive about the /dev/discs.. entry, because my root partition is /dev/hda1. I realize this information is a bit vague, so I'll try to give more information. I'm running kernel 2.4.22-hardened and util-linux 2.12 with loop-AES 2.0e. Running file on losetup returns

For obvious reasons, I replaced the real seed with XXXXXX for displaying purposes. If there's any other information you would like me to provide, please feel free to ask. Note that I can freely access the partition as normal when I use Knoppix. My system has been unbootable (if there is such a word) for the past few days and this really is very frustrating. Thanks in advance for any help or insight you can provide!_________________You can take a horse to water but you can't make it drink.
You can give a person facts, but you can't make them think.

A new version of loop-aes will be out soon to address the problems of having a loop.ko instead of a loop.o like build-initrd.sh expects. One other problem I ran across is that on my highly tweaked ~x86 system, any initrd I built would fail. I tried a few different things and it turns out that enabling dietlibc support (DIETLIBC=1) in build-initrd fixed my problems. Just make sure to emerge dietlibc first or you'll get some complaints. This works for both devfs and udev enabled kernels.
One problem I haven't fixed yet is having / mounted twice. I haven't dug around too much yet but if anyone else gets something similar to
/dev/loop/5 on / type ext3 (rw,noatime)
/dev/loop5 on / type ext3 (rw,noatime)
and they have a fix, I would love to hear it.

you can install gentoo with mostly every linux live cd. there is no need to use the gentoo cds.
of course, the stage tarballs are not included in a knoppix iso, so you have to get it from somewhere else (from the net, from your lan, or from any other storage device) but since you need internet access to install gentoo at all, i can't see any differences.

greets,
hulk_________________Linux: "Free as in free speech, not as in free beer"

I'm not sure what other info you might need. I am doing this with loop-AES-v2.0e, but I had identical problems with f. I'm hesitent to go back too many versions for fear of what other bugs might be in them.

Thank you very much for all the time and effort you've put into this tutorial!

many thanks to hulk2nd and Lord Tocharian ! this guide definately rocks !

as i am in the process of installing a new system which i want fully encrypted , i got to the following question : how usefull (or contra productive) is it to use losetup seeding together with gpg keys ?
couldnt find any documentation on that .

as i understand it , the key passed to losetup is passed on to pgp , which will use the key to decrypt the real keys which are used for the multikey hd encryption ?

adding seed to losetup would then
a) change (salt/seed) the key passed on to pgp ? OR :
b) change (salt/seed) the key(s) from pgp used for en/decryption ?

so in my oppinion adding seed would not really have any effect , since the key's given back by pgp should already be dictionary attack safe ? (in both cases) (given that the pgp keys were generated randomly , as described in the tutorial)

I'm thinking about an encrypted raid setup with reiser4 as the fs, am i just taking my life into my own hands here?

Let us all know how that goes/went. Be sure to throw some LVM in as well for good measure. Oh, and do it on an Opteron box.

compuboy86 wrote:

I'm certainly not an authority on this but it seems to me that encrypting a raid array wouldn't allow for rebuilding the array (should a drive go down) Software raid might work. Any thoughts?

RAID (1,3,4,5) bases it's parity data on the low-level contents of the partition, rather then the actual high-level contents (files and folders) of your filesystem, so encrypting the blocks your filesystem sits on really doesn't matter one way or the other to a RAID controller (it will calculate the parity for the encrypted data instead). On top of that, you COULD run a software RAID on some cypher-loops, and then run the resulting /dev/md* through a cypher-loop, but .... don't do that.

Gentoo Server wrote:

when you are using encryption anyway your performance is low

use reiser3 then

when your files are cached you will have good speed

Reading from the HD is several orders of magnitude more time consuming then manipulating data in RAM and usually when intense filesystem activity is going on, the CPU and RAM arenât being utilized fully (theyâre waiting on the FS operation to complete). Itâs been a while since my last thesis on this, but as I remember, block cipher operations are pretty much O(n) (as compared to block compression operations, thank you NTFS), so you can sneak an encryption/decryption operation into a block device without too much of a hit to your CPU/RAM (which is fine, since theyâre usually not the bottleneck anyways).

File caching is nice if you have the RAM, but usually people have more space on disk then they do RAM.

/replies

I'm deploying a server into a hostile physical environment. It's all old hardware, so I'm really not too worried about someone hitting it with a truck or otherwise lighting it on fire, but to facilitate several key functions of this server, it has passwordless SSH keys that handle unmanned logins to some fairly important servers, keys I donât want falling into the wrong hands, like those of a kid with a Knoppix CD for example.

Iâve been looking into encryption of the root partition (the only partition besides boot and swap, is 2G in size and currently has ~600M used with a full portage tree and kernel sources sitting in /usr/src. Filesystem is ReiserFS btw). Due to the possibility for abuse, the node will be headless (possibly even hidden in a ceiling); and itâs fairly hard to enter a password when thereâs no keyboard attached.

I decided to follow Option 3 of the howto, encryption with a gpg key. The following are my setup notes.

The performance hit for running âcat /dev/loop/5 > /dev/nullâ was CPU usage ranging from 50% to 75% by the âloop5â kernel process, and a pretty much solid 99% overall system CPU usage. So decrypting data coming from the drive at 8.64M/s was at par or too much for a 400mhz K6 processor. Interestingly enough, while running âupdatedbâ the loop5 processes stayed around 5-15% proc usage.

Iâm not sure what thatâs all about, but if it keeps working through multiple reboots, Iâll try not to worry about it.

One other thing Iâm going to continue looking into is loosing the password prompt from the initrd. It would be nice if loop-aes could detect if the gpg key presented is in fact password protected before asking for one. After reading through the loop-AES readme file though, it would seem that the gpg key is never examined by losetup or mount (just passed along to gpg) so I suppose Iâll have to look into using the -p option in losetup, and piping /dev/null or something into it.

Final note, Iâve been having random seg faults coming from emerge and runscript (possibly other apps) while running an encrypted root partition. Iâm going to compile a stock 2.6 kernel to rule out love-sources as being the cause. Iâll post again assuming I succeed in getting it stable._________________--Tracker

What happens if the filesystem gets corrupted? What happens if the system goes down unexpectedly? As far as i know when you encrypt something all it takes is 1 damaged bit to lose everything... Will only open files be lost or the entire partition?_________________... and we will show Microsoft, that they cannot take whatever they want. And that Free Software is our software!