Re: [gentoo-user] Guidance on encrypting my /home

[Richard Fish]

On 8/19/06, Stefan G. Weichinger <lists@×××××.at> 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@g.o mailing list