Adam Back's blog

• Mon 4 April 2011 - Luks redux. Now I found that using aes-xts is potentially a bad idea. Its not supported in even slightly older kernels so your removable drive may not work in another machine (or maybe its aes-xts-plain64 that is the problem plain64 was introduced over plain for IVs to support drives larger than 2TB didnt try the difference yet). To see the luks config run cryptsetup luksDump /dev/<device>. So I reformatted with the default aes-cbc-essiv:sha256 which is just as good really.
• Sun 3 April 2011 - More Luks tinkering. On fedora 14 it will automount your device and prompt for password. However it by default gets an ugly name (a UUID). You can change this with sudo e2label /dev/mapper/udiskblah <name> presuming you formatted the disk with ext2/3/4. Unplug and replug and the directory in /media is now your chosen <name> Furthermore you want to change the ownership of the files on the disk to the user that uses them. sudo chown -R adam.adam /media/name/. I guess if you used an ownerless file system like vfat, you wouldnt have that step, and any user could mount it but one should use a real file system as a Luks encrypted removable disk is going to be pretty hard to mount on windows anyway.

  Note the anti-forensics feature probably wont help much on an SSD due to wear leveling.

• Sat 2nd April 2011 - Playing with Luks / dm-crypt. You can get encrypted linux disks using dm-crypt without using the Luks extensions (use program cryptsetup to control everything). But one reason to use Luks is that it has an anti-forensics feature - the key management blocks are secret split across mulitple blocks by secret-splitting and stretching, the idea being if some of the blocks end up being bad and you later want to change a compromised password or wipe keys, the fact that all of the blocks are needed decreases your risk asymptotically towards 0 that all of those blocks will be bad. Just do cryptsetup luksFormat <physical-device-partition> and then cryptsetup luksOpen <device> <name> name is a dev-mapper name and gets linked in /dev/mapper/ (dev-mapper is the newer replacement for loopback /dev/loop). You might want to use --cipher aes-xts-plain64 but thats a matter of preference - the default aes-essiv is fine also.

  For non-removable harddrives you can ask fedora or ubuntu to make an encrypted disk and it'll manage it for you. Fedora uses aes-xts-plain64. btw the plain64 just refers to the IV source being the 64bit plain sector nuber, XTS mode makes sector number IVs that safe, normally they would tend to cancel with plaintext differences (passive leak) or be susceptible to chosen plaintext (active attack). ESSIV also protects against such things.