+ * 2.1 LUKS Container Setup mini-HOWTO
+
+ This item tries to give you a very brief list of all the steps you
+ should go though when creating a new LUKS encrypted container, i.e.
+ encrypted disk, partition or loop-file.
+
+ 01) All data will be lost, if there is data on the target, make a
+ backup.
+
+ 02) Make very sure you have the right target disk, partition or
+ loop-file.
+
+ 03) If the target was in use previously, it is a good idea to
+ wipe it before creating the LUKS container in order to remove any
+ trace of old file systems and data. For example, some users have
+ managed to run e2fsck on a partition containing a LUKS container,
+ possibly because of residual ext2 superblocks from an earlier use.
+ This can do arbitrary damage up to complete and permanent loss of
+ all data in the LUKS container.
+
+ To just quickly wipe file systems (old data may remain), use
+
+ wipefs -a <target device>
+
+ To wipe file system and data, use something like
+
+ cat /dev/zero > <target device>
+
+ This can take a while. To get a progress indicator, you can use
+ the tool dd_rescue (->google) instead or use my stream meter "wcs"
+ (source here: http://www.tansi.org/tools/index.html) in the
+ following fashion:
+
+ cat /dev/zero | wcs > <target device>
+
+ Be very sure you have the right target, all data will be lost!
+
+ Note that automatic wiping is on the TODO list for cryptsetup, so
+ at some time in the future this will become unnecessary.
+
+ Alternatively, plain cm-crypt can be used for a very fast wipe with
+ crypto-grade randomness, see Item 2.19
+
+ 04) Create the LUKS container:
+ cryptsetup luksFormat <target device>
+
+ Just follow the on-screen instructions.
+
+ Note: Passphrase iteration is determined by cryptsetup depending on
+ CPU power. On a slow device, this may be lower than you want. I
+ recently benchmarked this on a Raspberry Pi and it came out at
+ about 1/15 of the iteration count for a typical PC. If security is
+ paramount, you may want to increase the time spent in iteration, at
+ the cost of a slower unlock later. For the Raspberry Pi, using
+
+ cryptsetup luksFormat -i 15000 <target device>
+
+ gives you an iteration count and security level equal to an average
+ PC for passphrase iteration and master-key iteration. If in doubt,
+ check the iteration counts with
+
+ cryptsetup luksDump <target device>
+
+ and adjust the iteration count accordingly by creating the container
+ again with a different iteration time (the number after '-i' is the
+ iteration time in milicesonds) until your requirements are met.
+
+ 05) Map the container. Here it will be mapped to /dev/mapper/c1:
+ cryptsetup luksOpen <target device> c1
+
+ 06) (Optionally) wipe the container (make sure you have the right target!):
+ cat /dev/zero > /dev/mapper/c1
+
+ Note that this creates a small information leak, as an attacker can
+ determine whether a 512 byte block is zero if the attacker has
+ access to the encrypted container multiple times. Typically a
+ competent attacker that has access multiple times can install a
+ passphrase sniffer anyways, so this leakage is not very
+ significant. For getting a progress indicator, see step 03.
+
+ Note that at some time in the future, cryptsetup will do this for
+ you, but currently it is a TODO list item.
+
+ 07) Create a file system in the mapped container, for example an
+ ext3 file system (any other file system is possible):
+
+ mke2fs -j /dev/mapper/c1
+
+ 08) Mount your encrypted file system, here on /mnt:
+ mount /dev/mapper/c1 /mnt
+
+ Done. You can now use the encrypted file system to store data. Be
+ sure to read though the rest of the FAQ, these are just the very
+ basics. In particular, there are a number of mistakes that are
+ easy to make, but will compromise your security.
+
+
+ * 2.2 LUKS on partitions or raw disks?
+
+ This is a complicated question, and made more so by the availability
+ of RAID and LVM. I will try to give some scenarios and discuss
+ advantages and disadvantages. Note that I say LUKS for simplicity,
+ but you can do all the things described with plain dm-crypt as well.
+ Also note that your specific scenario may be so special that most
+ or even all things I say below do not apply.
+
+ Be aware that if you add LVM into the mix, things can get very
+ complicated. Same with RAID but less so. In particular, data
+ recovery can get exceedingly difficult. Only do so if you have a
+ really good reason and always remember KISS is what separates an
+ engineer from an amateur. Of course, if you really need the added
+ complexity, KISS is satisfied. But be very sure as there is a price
+ to pay for it. In engineering, complexity is always the enemy and
+ needs to be fought without mercy when encountered.
+
+ Also consider using RAID instead of LVM, as at least with the old
+ superblock format 0.90, the RAID superblock is in the place (end
+ of disk) where the risk of it permanently damaging the LUKS header
+ is smallest and you can have your array assembled by the RAID
+ controller (i.e. the kernel), as it should be. Use partition type
+ 0xfd for that. I recommend staying away from superblock formats
+ 1.0, 1.1 and 1.2 unless you really need them. Be aware that you
+ lose autodetection with them and have to fall back to some
+ user-space script to do it.
+
+ Scenarios:
+
+ (1) Encrypted partition: Just make a partition to your liking,
+ and put LUKS on top of it and a filesystem into the LUKS container.
+ This gives you isolation of differently-tasked data areas, just as
+ ordinary partitioning does. You can have confidential data,
+ non-confidential data, data for some specific applications,
+ user-homes, root, etc. Advantages are simplicity as there is a 1:1
+ mapping between partitions and filesystems, clear security
+ functionality and the ability to separate data into different,
+ independent (!) containers.
+
+ Note that you cannot do this for encrypted root, that requires an
+ initrd. On the other hand, an initrd is about as vulnerable to a
+ competent attacker as a non-encrypted root, so there really is no
+ security advantage to doing it that way. An attacker that wants to
+ compromise your system will just compromise the initrd or the
+ kernel itself. The better way to deal with this is to make sure the
+ root partition does not store any critical data and move that to
+ additional encrypted partitions. If you really are concerned your
+ root partition may be sabotaged by somebody with physical access
+ (that would however strangely not, say, sabotage your BIOS,
+ keyboard, etc.), protect it in some other way. The PC is just not
+ set-up for a really secure boot-chain (whatever some people may
+ claim).
+
+ (2) Fully encrypted raw block device: For this, put LUKS on the
+ raw device (e.g. /dev/sdb) and put a filesystem into the LUKS
+ container, no partitioning whatsoever involved. This is very
+ suitable for things like external USB disks used for backups or
+ offline data-storage.
+
+ (3) Encrypted RAID: Create your RAID from partitions and/or full
+ devices. Put LUKS on top of the RAID device, just if it were an
+ ordinary block device. Applications are just the same as above, but
+ you get redundancy. (Side note as many people seem to be unaware of
+ it: You can do RAID1 with an arbitrary number of components in
+ Linux.) See also Item 2.8.
+
+ (4) Now, some people advocate doing the encryption below the RAID
+ layer. That has several serious problems. One is that suddenly
+ debugging RAID issues becomes much harder. You cannot do automatic
+ RAID assembly anymore. You need to keep the encryption keys for the
+ components in sync or manage them somehow. The only possible
+ advantage is that things may run a little faster as more CPUs do
+ the encryption, but if speed is a priority over security and
+ simplicity, you are doing this wrong anyways. A good way to
+ mitigate a speed issue is to get a CPU that does hardware AES.
+
+
+ * 2.3 How do I set up encrypted swap?
+
+ As things that are confidential can end up in swap (keys,
+ passphrases, etc. are usually protected against being swapped to
+ disk, but other things may not be), it may be advisable to do
+ something about the issue. One option is to run without swap, which
+ generally works well in a desktop-context. It may cause problems
+ in a server-setting or under special circumstances. The solution to
+ that is to encrypt swap with a random key at boot-time.
+
+ NOTE: This is for Debian, and should work for Debian-derived
+ distributions. For others you may have to write your own startup
+ script or use other mechanisms.
+
+ 01) Add the swap partition to /etc/crypttab. A line like the following
+ should do it:
+
+ swap /dev/<partition> /dev/urandom swap,noearly
+
+ Warning: While Debian refuses to overwrite partitions with a
+ filesystem or RAID signature on it, if your disk IDs may change
+ (adding or removing disks, failure of disk during boot, etc.), you
+ may want to take additional precautions. Yes, this means that your
+ kernel device names like sda, sdb, ... can change between reboots!
+ This is not a concern if you have only one disk. One possibility is
+ to make sure the partition number is not present on additional
+ disks or also swap there. Another is to encapsulate the swap
+ partition (by making it a 1-disk RAID1 or by using LVM), so that it
+ gets a persistent identifier. Specifying it directly by UUID does
+ not work, unfortunately, as the UUID is part of the swap signature
+ and that is not visible from the outside due to the encryption and
+ in addition changes on each reboot with this setup.
+
+ Note: Use /dev/random if you are paranoid or in a potential
+ low-entropy situation (embedded system, etc.). This may cause the
+ operation to take a long time during boot. If you are in a "no
+ entropy" situation, you cannot encrypt swap securely. In this
+ situation you should find some entropy, also because nothing else
+ using crypto will be secure, like ssh, ssl or GnuPG.
+
+ Note: The "noearly" option makes sure things like LVM, RAID, etc.
+ are running. As swap is non-critical for boot, it is fine to start
+ it late.
+
+ 02) Add the swap partition to /etc/fstab. A line like the following
+ should do it:
+
+ /dev/mapper/swap none swap sw 0 0
+
+ That is it. Reboot or start it manually to activate encrypted swap.
+ Manual start would look like this:
+
+ /etc/init.d/crypdisks start
+ swapon /dev/mapper/swap
+
+
+ * 2.4 What is the difference between "plain" and LUKS format?
+
+ First, unless you happen to understand the cryptographic background
+ well, you should use LUKS. It does protect the user from a lot of
+ common mistakes. Plain dm-crypt is for experts.