-----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-----
smime.p7s
Description: S/MIME Cryptographic Signature
