Better be at least this paranoid!

So you've prepared the disk in a way suitable for your level of paranoia, now it's time to actually create the encrypted file system on it. Luckily that's an increasingly simple task, at least if you are using a moderately well-equipped kernel. If you didn't build your own, then it probably has everything you need already; if you did build your own, you should know how to fix things if something is missing. So we're good to continue.

I start by partitioning the disk. Note that if you want to be more mysterious you can encrypt the entire thing without partitioning it, but I like to at least get some kind of message that's not "disk not formatted" out of most systems I am likely to connect the drive to. So I partition. Since this is a pure "data disk" there's really no need for more than one partition, therefore no need for GPT. I simply make an old-school MBR partition table. But then I create two partitions. The first one (/dev/sdX1 say) is tiny, just 1 MB in size for example, and it'll get formatted with ext2. I like to put a small disclaimer and a few related files (such as the Bill of Rights) on that one.

The rest of the disk gets allocated to the second partition (/dev/sdX2 say). Here's how I then set up the encryption layer:

cryptsetup --verbose --cipher aes-xts-plain64 --key-size 512 --hash sha512 --iter-time 5000 --use-random luksFormat /dev/sdX2

Alright, that's quite a long command, so let's see. First I explicitly pick a cipher that is reasonably secure as of this writing. It's actually the same cipher that cryptsetup would default to anyway as of 1.6.0 or so. But I turn up the key size to something higher than the default and I also replace the hash function used for key generation to something more likely to survive a few more years. Finally I tell it to iterate for 5 seconds instead of just 1 second when computing the key. It's hard to say what kind of improvement that is, but in general the assumption is that if you spend more time generating the key, it'll be "better" in some way. Oh, I also use /dev/random instead of /dev/urandom, something you may not want to do if your system doesn't have enough entropy built up. Overall I think those are fairly conservative options that should result in decent security for the next few years. Or so one would hope...

Pick a good, long, cryptic, etc. pass phrase!

But we're paranoid, right? So let's make sure that we actually got what we requested from the command. Here's how to see that:

cryptsetup luksDump /dev/sdX2

This will spit out some interesting information I don't want to get into, but it'll also show you that the cipher, key size, and hash function are as requested. Good to know, right? Now it's time to actually attach the encrypted device to the system. Here's how we do that:

cryptsetup luksOpen /dev/sdX2 encrypted

The name "encrypted" will be used to create /dev/mapper/encrypted which is the name we use to refer to the encrypted version of the partition. (Remember that /dev/sdX2 is the raw, unencrypted partition and that we're "simulating" an encrypted layer above that.) Now I go ahead and create an ext4 filesystem as follows:

mkfs.ext4 /dev/mapper/encrypted

And after mounting that sucker, we're set: We can now write data to the ext4 filesystem on top of the encrypted disk on top of the actual raw partition. Win! After your backup, unmount the whole thing, issue an

cryptsetup luksClose encrypted

and finally store the disk in a safe place. You have succeeded. More or less anyway. Good luck in that military tribunal!