Instead the encryption options to be employed are used directly to create the mapping between an encrypted disk and a named device. The mapping can be created against a partition or a full device. In the latter case not even a partition table is needed.The unlocking process will map the partitions to a new device name using the device mapper. This alerts the kernel that /dev/partition name is actually an encrypted device and should be addressed through LUKS using the /dev/mapper/name so as not to overwrite the encrypted data. To guard against accidental overwriting, read about the possibilities to backup the cryptheader after finishing setup.For setting up LVM ontop the encryption layer the device file for the decrypted volume group would be anything like /dev/mapper/lvmpool instead of /dev/sdaX. LVM will then give additional names to all logical volumes created, e.g. /dev/mapper/lvmpool-root and /dev/mapper/lvmpool-swap.The creation and subsequent access of a dm-crypt plain mode encryption both require not more than using the cryptsetup open action with correct parameters. The following shows that with two examples of non-root devices, but adds a quirk by stacking both (i.e. the second is created inside the first). Obviously, stacking the encryption doubles overhead. The usecase here is simply to illustrate another example of the cipher option usage.Why that did not work Because the plain2 starting block (10) is still encrypted with the cipher from plain1. It can only be accessed via the stacked mapper. The error is arbitrary though, trying a wrong passphrase or wrong options will yield the same. For dm-crypt plain mode, the open action will not error out itself.It is possible to define up to 8 different keys per LUKS partition. This enables the user to create access keys for save backup storage: In a so-called key escrow, one key is used for daily usage, another kept in escrow to gain access to the partition in case the daily passphrase is forgotten or a keyfile is lost/damaged. Also a different key-slot could be used to grant access to a partition to a user by issuing a second key and later revoking it again.If /path/to/additionalkeyfile is given, cryptsetup will add a new keyslot for additionalkeyfile. Otherwise a new passphrase will be prompted for twice. For using an existing keyfile to authorize the action, the --key-file or -d option followed by the old keyfile will try to unlock all available keyfile keyslots:If the header of a LUKS encrypted partition gets destroyed, you will not be able to decrypt your data. It is just as much as a dilemma as forgetting the passphrase or damaging a key-file used to unlock the partition. A damage may occur by your own fault while re-partitioning the disk later or by third-party programs misinterpreting the partition table.Attention: Many people recommend NOT backing up the cryptheader, but even so its a single point of failure In short, the problem is that LUKS is not aware of the duplicated cryptheader, which contains the master key used to encrypt all files on the partition. Of course this master key is encrypted with your passphrases or keyfiles. But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader I.e. if someone obtains a copy of the cryptheader and one of your keys he can decrypt the master key and access all your data. Of course the same is true for all backups you create of partitions. So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not. See also the LUKS FAQ for further details on this.The cryptsetup package features the cryptsetup-reencrypt tool. It can be used to convert an existing unencrypted filesystem to a LUKS encrypted one (option --new) and permanently remove LUKS encryption (--decrypt) from a device. As its name suggests it can also be used to re-encrypt an existing LUKS encrypted device. For re-encryption it is possible to change the Encryption options for LUKS mode. cryptsetup-reencrypt actions can be performed to unmounted devices only. See man cryptsetup-reencrypt for more information.One application of re-encryption may be to secure the data again after a passphrase or keyfile has been compromised and one cannot be certain that no copy of the LUKS header has been obtained. For example, if only a passphrase has been shoulder-surfed but no physical/logical access to the device happened, it would be enough to change the respective passphrase/key only (Key management).After it finished, the encryption was performed to the full partition, i.e. not only the space the filesystem was shrunk to (sdaX has 2.6GiB and the CPU used in the example has no hardware AES instructions). As a final step we extend the filesystem of the now encrypted device again to occupy available space:A possible usecase is to re-encrypt LUKS devices which have non-current encryption options. Apart from above warning on specifying options correctly, the ability to change the LUKS header may also be limited by its size. For example, if the device was initially encrypted using a CBC mode cipher and 128 bit key-size, the LUKS header will be half the size of above mentioned 4096 sectors:While it is possible to upgrade the encryption of such a device, it is currently only feasible in two steps. First, re-encrypting with the same encryption options, but using the --reduce-device-size option to make further space for the larger LUKS header. Second, re-encypt the whole device again with the desired cipher. For this reason and the fact that a backup should be created in any case, creating a new, fresh encrypted device to restore into is always the faster option.This is a keyfile containing a simple passphrase. The benefit of this type of keyfile is that if the file is lost the data it contained is known and hopefully easily remembered by the owner of the encrypted volume. However the disadvantage is that this does not add any security over entering a passphrase during the initial system start.This is a keyfile containing a block of random characters. The benefit of this type of keyfile is that it is much more resistant to dictionary attacks than a simple passphrase.