Re: [gentoo-amd64] Re: Using encrypted swap via cryptsetup-luks on amd64

[Richard Freeman]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Duncan wrote:
>
> Well, there's could, and there's groking what it's actually doing, in case
> there's a problem and to ensure it's actually encrypting it.  (I
> /seriously/ hope that mention of uuencode doesn't mean they're using /it/
> to "encrypt", for instance.  A quick look say they aren't, but that
> doesn't tell me what's actually going on yet, either.)

Ok, in a nutshell:

1.  Generate MD5 hash of first 40k of previous swap volume (essentially
a source of entropy).  In my opinion it isn't needed but probably
couldn't hurt.

2.  Wipe that 40k 20 times - just so nobody can figure out what that
hash might have been later.

3.  Generate a random encryption key (WHOA - why on earth is that script
using urandom for this - it only pulls 18 bytes - I just changed it to
/dev/random in mine (more secure in the event the entropy pool gets low
- - although normally they are the same)).  For those not in the know,
/dev/random blocks if it runs out of entropy, but /dev/urandom just
gives out a less random value.  If you need 50MB of random data you have
to use urandom if you don't want to freeze the system for 12 hours, but
for 18 bytes we can afford to wait for quality data.

4.  /dev/(u)random dumps binary data - losetup wants something more sane
as a key, so uuencode is used to convert to text.  No source of
compromise here - the original data was random so the uuencoded data is
still random (it is now constrained in potential output values, but is
longer which compensates).

5.  Set up the loop device using the output of steps 1 and 4
concatenated as an encryption key (losetup will generate a SHA-512 key
from the text key and use that for actual encryption).

6.  Wipe out the variables containing the two key components (probably
doesn't accomplish much).  The keys will be in RAM somewhere for as long
as the swap is mounted and only root can hunt for the keys either way.

7.  Zero the start of the encrypted loop device - mainly just to make
mkswap happy in case the device ends up looking like some other type of
partition.

8.  Create and use the swap device.


> If I'm going to be
> running encrypted swap, I'm going to need to know all about what I'm using
> to encrypt it (losetup here, it seems), and how that plays with my
> four-way striped swap (a four gig partition on each of my four SATA
> drives, all set pri=1 so the kernel stripes it for performance), among
> other things. If I can't rest assured it's working well, why bother?
>

I'd just make SWAPDEVICE and LOOPDEV command-line parameters and then
call the script 4 times.

> swap again, wipe the partitions, and simply leave swap off.  Only if they
> ever get suspend to disk working semi-reliably...

Not sure encrypted swap will play well with suspend to disk.  Somehow
when the system wakes up it needs to find out what the encryption key
actually was, otherwise the loop device can't be reactivated.  Now, it
is possible that the kernel will just write the key to disk somewhere,
but this defeats much of the security of an encrypted swap device (where
after a reboot the swap space is impossible to read without a brute
force attack on AES-CBC).  If the key isn't written to disk the kernel
will boot and look around and not see any valid swap partitions on the
disk at all.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFO2EGG4/rWKZmVWkRAsRsAKCoF3LGq2Qw+jvQI6W+1i5A0i2hXwCgifEl
oWpJqZG0t7txICyhZhQhu/Q=
=AdpP
-----END PGP SIGNATURE-----