On 8/19/06, Stefan G. Weichinger <[EMAIL PROTECTED]> wrote:
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?
Well genkernel also allows you to specify a custom linuxrc (--linuxrc=). This is probably the route I would take with genkernel. The default is in /usr/share/genkernel/generic/linuxrc, which you can use for inspiration. Generally that script does everything that you will want to do, just not in the order you want to do it in. You have a few options for this setup. If you don't mind typing your password twice, you can just use cryptsetup twice in your linuxrc to decrypt swap and root. Actually, with suspend2 usage, you would probably have something like: cryptsetup ... crypt_swap if test -f /proc/suspend2/resume2; then devnum=`busybox stat -c "0x%.2t%.2T" /dev/mapper/crypt_swap` echo $devnum >/proc/suspend2/resume2 fi if test -f /proc/suspend2/do_resume; then echo > /proc/suspend2/do_resume fi # didn't resume, so continue booting cryptsetup ... crypt_root ... An option to allow typing your password once duing bootup is to suspend to a file on the root filesystem, and encrypt your swap partition randomly. I've never tried this, but I expect the resume part would be something like: cryptsetup ... crypt_root mount -o ro /dev/mapper/crypt_root /mnt/newroot if test -f /proc/suspend2/resume2; then echo "/mnt/newroot/.suspend.img" >/proc/suspend2/resume2 fi if test -f /proc/suspend2/do_resume; then echo > /proc/suspend2/do_resume fi Another option if you want to keep a single combined swap/suspend2 'partition' is to use LVM. In this case, you would combine your swap and root partitions, and setup a dm-crypt mapping. On the encrypted volume, you make an LVM physical volume, create a volume group on the pv, and then create logical volumes within the volume group. It sounds complex, but it really isn't too hard. The bootup sequence there looks like: cryptsetup ... crypt_pv vgchange -a y if test -f /proc/suspend2/resume2; then devnum=`busybox stat -c "0x%.2t%.2T" /dev/mapper/vg0-swap` echo $devnum >/proc/suspend2/resume2 fi if test -f /proc/suspend2/resume2; then echo "/mnt/newroot/.suspend.img" >/proc/suspend2/resume2 fi # didn't resume, so continue booting mount -o ro /dev/mapper/vg0-root /mnt/newroot ... You do have to remember to update your lvm configuration to scan encrypted device-mapper volumes: filter = [ "a|/dev/mapper/crypt_*|", "r|/dev/mapper/*|" ]
Are there any comparisons between the speed of using aes-cbc-essiv:sha256, 128bit and aes-cbc-essiv:sha256, 256bit ?
I don't have any comparisons, but it should be easy enough for you to create. Just setup a bare (not luks) mapping and do: dd if=/dev/mapper/crypt_foo of=/dev/null bs=64k count=49152 This will read 3G of 'encrypted' data from the drive. You can do this without affecting any data on the disk, as long as you do *not* luksFormat it. Remember to keep an eye on the CPU usage of this with vmstat or top as well.
/dev/mapper/root is active: cipher: serpent-cbc-essiv:sha256
Generally I've found AES to be slightly faster...
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.
Just be sure to keep in mind the type of data you have and who you are trying to defend against. Researching encryption on the net is a quick way to get irrationally paranoid. The bottom line is that everything can be broken given enough time and money. So if you work for the CIA and keep the secret identies of all spies and informants on your laptop, well, then dm-crypt is not sufficient to begin with. If you work for my investment brokerage and have all your customers' financial records on your disk, I want you to use 256-bit encryption. If it is just your bank records and personal emails, use whatever you want. -Richard -- gentoo-user@gentoo.org mailing list
