+ * 1.6 Where is the project website?
+
+ There is the project website at
+ https://gitlab.com/cryptsetup/cryptsetup/ Please do not post
+ questions there, nobody will read them. Use the mailing-list
+ instead.
+
+
+ * 1.7 Is there a mailing-list?
+
+ Instructions on how to subscribe to the mailing-list are at on the
+ project website. People are generally helpful and friendly on the
+ list.
+
+ The question of how to unsubscribe from the list does crop up sometimes.
+ For this you need your list management URL, which is sent to you
+ initially and once at the start of each month. Go to the URL mentioned
+ in the email and select "unsubscribe". This page also allows you to
+ request a password reminder.
+
+ Alternatively, you can send an Email to dm-crypt-request@saout.de with
+ just the word "help" in the subject or message body. Make sure to send
+ it from your list address.
+
+ The mailing list archive is here:
+ https://marc.info/?l=dm-crypt
+
+
+ * 1.8 Unsubscribe from the mailing-list
+
+ Send mail to dm-crypt-unsubscribe@saout.de from the subscribed account.
+ You will get an email with instructions.
+
+ Basically, you just have to respond to it unmodified to get
+ unsubscribed. The listserver admin functions are not very fast. It can
+ take 15 minutes or longer for a reply to arrive (I suspect greylisting
+ is in use), so be patient.
+
+ Also note that nobody on the list can unsubscribe you, sending demands
+ to be unsubscribed to the list just annoys people that are entirely
+ blameless for you being subscribed.
+
+ If you are subscribed, a subscription confirmation email was sent to
+ your email account and it had to be answered before the subscription
+ went active. The confirmation emails from the listserver have subjects
+ like these (with other numbers):
+
+ Subject: confirm 9964cf10.....
+
+ and are sent from dm-crypt-request@saout.de. You should check whether
+ you have anything like it in your sent email folder. If you find
+ nothing and are sure you did not confirm, then you should look into a
+ possible compromise of your email account.
+
+
+2. Setup
+
+ * 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 use 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>
+
+ Plain "dd" also gives you the progress on a SIGUSR1, see its man-page.
+
+ 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 dm-crypt can be used for a very fast wipe with
+ crypto-grade randomness, see Item 2.19
+
+ 04) Create the LUKS container.
+
+ LUKS1:
+
+ cryptsetup luksFormat --type luks1 <target device>
+
+ LUKS2:
+
+ cryptsetup luksFormat --type luks2 <target device>
+
+
+ Just follow the on-screen instructions.
+
+ Note: Passprase iteration count is based on time and hence security
+ level depends on CPU power of the system the LUKS container is created
+ on. For example on a Raspberry Pi and LUKS1, I found some time ago that
+ the iteration count is 15 times lower than for a regular PC (well, for
+ my old one). Depending on security requirements, this may need
+ adjustment. For LUKS1, you can just look at the iteration count on
+ different systems and select one you like. You can also change the
+ benchmark time with the -i parameter to create a header for a slower
+ system.
+
+ For LUKS2, the parameters are more complex. ARGON2 has iteration,
+ parallelism and memory parameter. cryptsetup actually may adjust the
+ memory parameter for time scaling. Hence to use -i is the easiest way
+ to get slower or faster opening (default: 2000 = 2sec). Just make sure
+ to not drop this too low or you may get a memory parameter that is to
+ small to be secure. The luksDump command lists the memory parameter of
+ a created LUKS2 keyslot in kB. That parameter should probably be not
+ much lower than 100000, i.e. 100MB, but don't take my word for it.
+
+ 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
+
+ This will take a while. 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.
+
+ 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
+
+ 09) Make a LUKS header backup and plan for a container backup.
+ See Section 6 for details.
+
+ 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? What about RAID?
+
+ Also see Item 2.8.
+ 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 add LVM 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 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.
+
+ 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 to move that to
+ additional encrypted partitions. If you really are concerned your root
+ partition may be sabotaged by somebody with physical access (who 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 different RAID
+ 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 as most do today.
+
+
+ * 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, as 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-partition
+ RAID1 or by using LVM), as that 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 however. 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.
+
+ Plain format is just that: It has no metadata on disk, reads all
+ parameters from the commandline (or the defaults), derives a master-key
+ from the passphrase and then uses that to de-/encrypt the sectors of the
+ device, with a direct 1:1 mapping between encrypted and decrypted
+ sectors.
+
+ Primary advantage is high resilience to damage, as one damaged encrypted
+ sector results in exactly one damaged decrypted sector. Also, it is not
+ readily apparent that there even is encrypted data on the device, as an
+ overwrite with crypto-grade randomness (e.g. from
+ /dev/urandom) looks exactly the same on disk.
+
+ Side-note: That has limited value against the authorities. In civilized
+ countries, they cannot force you to give up a crypto-key anyways. In
+ quite a few countries around the world, they can force you to give up
+ the keys (using imprisonment or worse to pressure you, sometimes without
+ due process), and in the worst case, they only need a nebulous
+ "suspicion" about the presence of encrypted data. Sometimes this
+ applies to everybody, sometimes only when you are suspected of having
+ "illicit data" (definition subject to change) and sometimes specifically
+ when crossing a border. Note that this is going on in countries like
+ the US and the UK to different degrees and sometimes with courts
+ restricting what the authorities can actually demand.
+
+ My advice is to either be ready to give up the keys or to not have
+ encrypted data when traveling to those countries, especially when
+ crossing the borders. The latter also means not having any high-entropy
+ (random) data areas on your disk, unless you can explain them and
+ demonstrate that explanation. Hence doing a zero-wipe of all free
+ space, including unused space, may be a good idea.
+
+ Disadvantages are that you do not have all the nice features that the
+ LUKS metadata offers, like multiple passphrases that can be changed, the
+ cipher being stored in the metadata, anti-forensic properties like
+ key-slot diffusion and salts, etc..
+
+ LUKS format uses a metadata header and 8 key-slot areas that are being
+ placed at the beginning of the disk, see below under "What does the LUKS
+ on-disk format looks like?". The passphrases are used to decrypt a
+ single master key that is stored in the anti-forensic stripes. LUKS2
+ adds some more flexibility.
+
+ Advantages are a higher usability, automatic configuration of
+ non-default crypto parameters, defenses against low-entropy passphrases
+ like salting and iterated PBKDF2 or ARGON 2 passphrase hashing, the
+ ability to change passphrases, and others.
+
+ Disadvantages are that it is readily obvious there is encrypted data on
+ disk (but see side note above) and that damage to the header or
+ key-slots usually results in permanent data-loss. See below under "6.
+ Backup and Data Recovery" on how to reduce that risk. Also the sector
+ numbers get shifted by the length of the header and key-slots and there
+ is a loss of that size in capacity. Unless you have a specific need,
+ use LUKS2.
+
+
+ * 2.5 Can I encrypt an existing, non-empty partition to use LUKS?
+
+ There is no converter, and it is not really needed. The way to do this
+ is to make a backup of the device in question, securely wipe the device
+ (as LUKS device initialization does not clear away old data), do a
+ luksFormat, optionally overwrite the encrypted device, create a new
+ filesystem and restore your backup on the now encrypted device. Also
+ refer to sections "Security Aspects" and "Backup and Data Recovery".
+
+ For backup, plain GNU tar works well and backs up anything likely to be
+ in a filesystem.
+
+
+ * 2.6 How do I use LUKS with a loop-device?
+
+ This can be very handy for experiments. Setup is just the same as with
+ any block device. If you want, for example, to use a 100MiB file as
+ LUKS container, do something like this:
+
+ head -c 100M /dev/zero > luksfile # create empty file
+ losetup /dev/loop0 luksfile # map file to /dev/loop0
+ cryptsetup luksFormat --type luks2 /dev/loop0 # create LUKS2 container