disk encryption

Ratio: Why?

Encryption comes at a price: You will have to spend time on it, because you have to decide how to do it and you will permanently use computing resources when using it. But what seems to be unattractive can pay out in situations, when your drive can be accessed by any foreigners, which might include:

  • a person who has stolen it from you
  • if your drive has failed and you returned it for guarantee the manufacturer will not repair exactly your drive, but will in most cases collect them and send you an already repaired drive back, which someone else had sent in before

Choosing an encryption algorithm

This really is a problem, because you never know which algorithm will be proven to be insecure tomorrow. Sadly the cryptsetup command expects a not well documented format for its –cipher parameter. The man page just says that it defaults to aes-xts-plain64 when using LUKS. I found two methods to find out which encryptions are supported by your kernel. First and recommend is the usage of

which is supposed to compare the performance of those implementations on your hardware. In rare cases you might find some more with

mount on boot

prepare your usb stick

This will erase all data and label your stick ‘usb-key’:

automatically mount the usb stick

I suggest you use the following line to mount the stick. It will create a directory /mnt/.usb-key on itsown giving it rw- --- --- permissions by default and it will silently ignore a missing stick:

The trick will then be, that current systems are using systemd even to mount entries found in the fstab and thus allowing us to define dependencies.

automatically mount

Because there is no support for external luks headers available in systemd at the time of writing (also there is a patch) we need another solution in order to mount the stick before opening the luks-device and mounting it. I used a service to do so:

Unlock using the master key

Recover a lost key

It is trivial, that as long as your device is accessible the key must be somewhere in the random access memory and can be read. You don’t have to work for the NSA to find it, because dmcrypt provides everything you need:

will output everything you need to reproduce a key, which can be used independant from LUKS and is an ascii representation of what is meant to be binary. So copy the key into the hexeditor of your choice (or do with xxd) and create a new LUKS header like so:

From man cryptsetup: For luksFormat this allows creating a LUKS header with this specific master key. If the master key was taken from an existing LUKS header and all other parameters are the same, then the new header decrypts the data encrypted with the header the master key was taken from

This method is also described officially