Richard Fish wrote: >> http://gentoo-wiki.com/SECURITY_System_Encryption_DM-Crypt_with_LUKS > > This guide seems reasonable. I think the current live CD includes the > version of cryptsetup that understands LUKS though, so it shouldn't be > necessary to download that. And I prefer to randomize the disk by > encrypting with a random password before I setup the actual mapping. > > If you want to get started on this before your new laptop arrives, I > suggest starting with the initramfs and encrypting swap only. You > should be able to create an initramfs that will setup the mapping and > do the swapon before your root filesystem mounts. Once you have that > working, and are comfortable with how the initramfs works, you can > move on to your root filesystem.
I followed that guide and have now managed to boot from my encrypted root-fs, using the current genkernel, which provides LUKS-support via --luks. Doing it this way I skipped the init-script on that page completely. But this only works for /root, not for swap. As my goal is to encrypt root and swap *and* use suspend2, I had to go slightly different paths than the mentioned howto says. There are various HOWTOs out there, but no one that exactly meets my requirements. (For example I also tried genkernel-luks 3.1.0, but AFAI can see, this is already merged into the current genkernel 3.4.0) Would you recommend to use the initramfs from the HOWTO, or might there be another way of doing it, staying closer at the genkernel-way of doing it? - I also didn't fully understand that note about having two swap-partitions, one for swap and one for suspend: Wouldn't the suspended image be unencrypted? - Are there any comparisons between the speed of using aes-cbc-essiv:sha256, 128bit and aes-cbc-essiv:sha256, 256bit ? I write this on my P4-M 1.8GHz, using this root-partition: /dev/mapper/root is active: cipher: serpent-cbc-essiv:sha256 keysize: 256 bits device: /dev/hda6 offset: 2056 sectors size: 20111261 sectors mode: read/write and the performance seems OK to me. But it could always be better ;) I will have a look through the docs to see the security-implications of using "only" 128bit. Greetings, Stefan. -- [email protected] mailing list
