Difference between revisions of "Plain dm-crypt without LUKS"

From ArchWiki
Jump to: navigation, search
(Created page with "{{Lowercase title}} Category:Security Category:File systems {{Article summary start}} {{Article summary text|This tutorial will show you how to set up system encryptio...")
 
("open" is a cryptsetup action, not an option. Only the options have prepended hyphens)
(21 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{Lowercase title}}
 
 
[[Category:Security]]
 
[[Category:Security]]
 
[[Category:File systems]]
 
[[Category:File systems]]
 +
{{Merge|Dm-crypt with LUKS|Assess the possibility of merging the common content between the two articles in order to avoid duplication.|section=Merge}}
 
{{Article summary start}}
 
{{Article summary start}}
 
{{Article summary text|This tutorial will show you how to set up system encryption with plain dm-crypt.}}
 
{{Article summary text|This tutorial will show you how to set up system encryption with plain dm-crypt.}}
Line 9: Line 9:
 
{{Article summary end}}
 
{{Article summary end}}
  
 
+
This article focuses on system disk encryption using plain dm-crypt without LUKS.
This article focuses on encryption using plain dm-crypt without LUKS, for both non-system partitions and system partitions.
+
  
 
'''dm-crypt''' is the standard device-mapper encryption functionality provided by the Linux kernel. It can be used directly by those who like to have full control over all aspects of partition and key management.
 
'''dm-crypt''' is the standard device-mapper encryption functionality provided by the Linux kernel. It can be used directly by those who like to have full control over all aspects of partition and key management.
Line 18: Line 17:
 
For most use cases, [[dm-crypt with LUKS]] is by far the better option for both system encryption and encrypted partitions. Below are some considerations for choosing one over the other.
 
For most use cases, [[dm-crypt with LUKS]] is by far the better option for both system encryption and encrypted partitions. Below are some considerations for choosing one over the other.
  
===== Advantages=====  
+
=== Advantages===
 
* dm-crypt does not require a header on the encrypted disk. This means that an unpartitioned, encrypted disk will be indistinguishable from a disk filled with random data. This may be useful in a country that can force you to give up an encryption key where a reasonable suspicion of encrypted data exists.
 
* dm-crypt does not require a header on the encrypted disk. This means that an unpartitioned, encrypted disk will be indistinguishable from a disk filled with random data. This may be useful in a country that can force you to give up an encryption key where a reasonable suspicion of encrypted data exists.
 
* plain dm-crypt encrypted disks are more resilient to damage than LUKS encrypted disks, because of the one-to-one mapping of unencrypted data to encrypted data.
 
* plain dm-crypt encrypted disks are more resilient to damage than LUKS encrypted disks, because of the one-to-one mapping of unencrypted data to encrypted data.
  
===== Disadvantages=====  
+
=== Disadvantages===
 
* dm-crypt does not allow multiple pass-phrases, nor does it allow changes to the pass-phase or key-file after initial set-up. LUKS allows for up to eight passphrases, and key-files and passphrases can be changed without having to re-encrypt the entire disk or partition.
 
* dm-crypt does not allow multiple pass-phrases, nor does it allow changes to the pass-phase or key-file after initial set-up. LUKS allows for up to eight passphrases, and key-files and passphrases can be changed without having to re-encrypt the entire disk or partition.
 
* plain dm-crypt requires manual configuration of encryption options each time a device is opened, whereas LUKS stores those details in its header.
 
* plain dm-crypt requires manual configuration of encryption options each time a device is opened, whereas LUKS stores those details in its header.
Line 32: Line 31:
  
 
A separate {{ic|/boot}} partition is required, as it needs to remain unencrypted to be accessed by the bootloader. In the scenario that follows, it is assumed that no evidence of encryption is to be left on the main system drive, and so we install the {{ic|/boot}} partition and the bootloader to a separate USB stick, and the encryption key to yet another USB stick. Throughout the guide, the system disk will be shown as {{ic|/dev/sd''X''}}, the USB stick containing {{ic|/boot}} will be shown as {{ic|/dev/sd''Y''}}, and the USB stick containing the encryption key will be shown as {{ic|/dev/sd''Z''}}, where ''X'', ''Y'' and ''Z'' represent their respective device letters.
 
A separate {{ic|/boot}} partition is required, as it needs to remain unencrypted to be accessed by the bootloader. In the scenario that follows, it is assumed that no evidence of encryption is to be left on the main system drive, and so we install the {{ic|/boot}} partition and the bootloader to a separate USB stick, and the encryption key to yet another USB stick. Throughout the guide, the system disk will be shown as {{ic|/dev/sd''X''}}, the USB stick containing {{ic|/boot}} will be shown as {{ic|/dev/sd''Y''}}, and the USB stick containing the encryption key will be shown as {{ic|/dev/sd''Z''}}, where ''X'', ''Y'' and ''Z'' represent their respective device letters.
{{Tip|The essential process of filling an encrypted drive can take well over a day to complete on a multi-terrabyte disk. It is therefore recommended that, if an alternative computer is not available for use during this time, the [[Dm-crypt without LUKS:Encrypting system partitions#Preparation|Preparation]], [[Dm-crypt without LUKS:Encrypting system partitions#Set up encryption|Set up encryption]] and [[Dm-crypt without LUKS:Encrypting system partitions#Fill the mapped device|Fill the mapped device]] steps should be done from another installation rather than the Arch installation media.}}
+
{{Tip|The essential process of filling an encrypted drive can take over a day to complete on a multi-terrabyte disk. It is therefore suggested that the following steps, up until [[#Mount the partitions]], be done from another installation rather than the Arch installation media.}}
==== Preparation ====
+
=== Preparation ===
===== Safety first =====
+
==== Safety first ====
 
We must first make absolutely sure we are targeting the correct disk:
 
We must first make absolutely sure we are targeting the correct disk:
 
  # fdisk -l
 
  # fdisk -l
===== Load the kernel module =====  
+
==== Load the kernel module ====
 
   # modprobe dm-crypt
 
   # modprobe dm-crypt
==== Setup encryption ====
+
=== Setup encryption ===
 
Cryptsetup is used to create the mapping between an encrypted disk and a named device. Its form in this case is:
 
Cryptsetup is used to create the mapping between an encrypted disk and a named device. Its form in this case is:
  # cryptsetup <options> --open --type plain <device> <name>
+
  # cryptsetup <options> open --type plain <device> <name>
  
 
{| class="wikitable" border="1" cellpadding="5" cellspacing="0"
 
{| class="wikitable" border="1" cellpadding="5" cellspacing="0"
Line 53: Line 52:
 
| --key-size||The key size (in bits). The size will depend on the cipher being used and also the chainmode in use. Xts mode will require twice the key size of cbc, which should be apparent from the output of {{ic|cryptsetup benchmark}}.||128, 256, 512||256bits
 
| --key-size||The key size (in bits). The size will depend on the cipher being used and also the chainmode in use. Xts mode will require twice the key size of cbc, which should be apparent from the output of {{ic|cryptsetup benchmark}}.||128, 256, 512||256bits
 
|-
 
|-
| --offset||The offset from the beginning of the target disk from which to start the mapping||0||Unknown, but it doesn't appear to be 0.
+
| --offset||The offset from the beginning of the target disk from which to start the mapping||0||Unknown, but it does not appear to be 0.
 
|-
 
|-
| --key-file||The device or file to be used as a key. See [[Creating key files]] for further details.||/dev/sda, /boot/keyfile.enc||Uses passphrase instead.
+
| --key-file||The device or file to be used as a key. See [[Dm-crypt_with_LUKS#Using_Cryptsetup_with_a_Keyfile |here]] for further details.||/dev/sd''Z'', /boot/keyfile.enc||Uses passphrase instead.
 
|-
 
|-
 
| --keyfile-offset||Offset from the beginning of the key file (in bytes) from which to read.||2049||0
 
| --keyfile-offset||Offset from the beginning of the key file (in bytes) from which to read.||2049||0
 
|-
 
|-
| --keyfile-size||Limits the bytes read from the key file. However, I've found that this is ignored when using plain dm-crypt. Instead, the size will depend on the key-size used.||512B||8192kB
+
| --keyfile-size||Limits the bytes read from the key file. However, I have found that this is ignored when using plain dm-crypt. Instead, the size will depend on the key-size used.||512B||8192kB
 
|}
 
|}
  
 
Dm-crypt does not need a partition table and the existence of one could provide a reasonable suspicion that the drive is encrypted. We therefore set up the encryption directly on the physical disk. If a partition table already exists on the target disk, it will be wiped when we later fill the disk.
 
Dm-crypt does not need a partition table and the existence of one could provide a reasonable suspicion that the drive is encrypted. We therefore set up the encryption directly on the physical disk. If a partition table already exists on the target disk, it will be wiped when we later fill the disk.
===== Example with default options =====  
+
==== Example with default options ====
 
Using default options with the device {{ic|/dev/sd''X''}} and using {{ic|enc}} for the mapped name, we have:
 
Using default options with the device {{ic|/dev/sd''X''}} and using {{ic|enc}} for the mapped name, we have:
  # cryptsetup --open --type plain /dev/sdX enc
+
  # cryptsetup open --type plain /dev/sdX enc
 
You will then be prompted for a password twice, which should have very high entropy. See https://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions#5._Security_Aspects for details.
 
You will then be prompted for a password twice, which should have very high entropy. See https://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions#5._Security_Aspects for details.
===== Example with custom options =====  
+
==== Example with custom options ====
 
If custom options are required, you may wish to test which encryption system works best on your system:
 
If custom options are required, you may wish to test which encryption system works best on your system:
 
  # cryptsetup benchmark
 
  # cryptsetup benchmark
 
Using the device {{ic|/dev/sd''X''}}, with the twofish-xts cipher with a 512 bit key size we have:
 
Using the device {{ic|/dev/sd''X''}}, with the twofish-xts cipher with a 512 bit key size we have:
{{bc|<nowiki># cryptsetup --hash=sha512 --cipher=twofish-xts-plain64 --offset=0 --key-file=</nowiki>/dev/sd''Z'' <nowiki>--key-size=512 --open --type=plain /dev/sdX enc</nowiki>}}
+
{{bc|<nowiki># cryptsetup --hash=sha512 --cipher=twofish-xts-plain64 --offset=0 --key-file=</nowiki>/dev/sd''Z'' <nowiki>--key-size=512 open --type=plain /dev/sdX enc</nowiki>}}
 
Unlike encrypting with LUKS, the above command must be executed ''in full'' whenever the mapping needs to be re-established, so it is important to remember the cipher, hash and key file details.
 
Unlike encrypting with LUKS, the above command must be executed ''in full'' whenever the mapping needs to be re-established, so it is important to remember the cipher, hash and key file details.
 
We can now check that the mapping has been made:
 
We can now check that the mapping has been made:
Line 77: Line 76:
 
An entry should now exist for {{ic|/dev/mapper/enc}}.
 
An entry should now exist for {{ic|/dev/mapper/enc}}.
  
==== Fill the mapped device ====
+
=== Fill the mapped device ===
 
{{Note|It is vital that the mapped device is filled with data. Without doing so, the encrypted data that is written to disk will be easily distinguishable from areas not yet written to.}}
 
{{Note|It is vital that the mapped device is filled with data. Without doing so, the encrypted data that is written to disk will be easily distinguishable from areas not yet written to.}}
 
{{Warning|The following operation will destroy all data on the underlying physical disk.}}
 
{{Warning|The following operation will destroy all data on the underlying physical disk.}}
Line 89: Line 88:
 
  # fdisk -l
 
  # fdisk -l
 
{{Note| The partition table will only have been wiped if the offset was set to 0. As a side effect of this, the disk will no longer be addressable by UUID, however it can still be addressed by physical ID ({{ic|/dev/disk/by-id}}).}}
 
{{Note| The partition table will only have been wiped if the offset was set to 0. As a side effect of this, the disk will no longer be addressable by UUID, however it can still be addressed by physical ID ({{ic|/dev/disk/by-id}}).}}
==== Install the system ====
+
=== Install the system ===
 
Much of the following steps are identical to those in the [[Installation Guide]]. Where they differ is:
 
Much of the following steps are identical to those in the [[Installation Guide]]. Where they differ is:
  
Line 97: Line 96:
 
* the details of the encryption are added to the kernel options in the bootloader.
 
* the details of the encryption are added to the kernel options in the bootloader.
  
===== Partition disks =====
+
==== Partition disks ====
 
See [[Partitioning]] for further details.
 
See [[Partitioning]] for further details.
  
Line 107: Line 106:
 
  # lvcreate -L 20G store -n root
 
  # lvcreate -L 20G store -n root
 
  # lvcreate -C y -L 10G store -n swap
 
  # lvcreate -C y -L 10G store -n swap
  # lvcreate -L +100%FREE store -n home
+
  # lvcreate -l +100%FREE store -n home
 
See [[Lvm#Installing_Arch_Linux_on_LVM]] for further details.
 
See [[Lvm#Installing_Arch_Linux_on_LVM]] for further details.
  
For the remainder of this guide we will use the simple LVM volume set created above, which will have created the volumes {{ic|/dev/store/root}}, {{ic|/dev/store/home}} and {{ic|/dev/store/swap}}. The choice of volume group name and logical volume names is arbitrary.
+
For the remainder of this guide we will use the simple LVM volume set created above, which will have created the volumes {{ic|/dev/store/root}}, {{ic|/dev/store/home}} and {{ic|/dev/store/swap}}. The choice of volume group name and logical volume names are arbitrary.
  
===== Format the partitions =====
+
The {{ic|/boot}} partition can be installed on the standard vfat partition of a USB stick, if required. But if manual partitioning is needed, then a small 200MB partition is all that is required:
 +
# fdisk /dev/sd''Y''
 +
> n
 +
> p
 +
> 1
 +
> default (2048)
 +
> +200M
 +
> w
 +
> q
 +
 
 +
==== Format the partitions ====
 
See [[File Systems#Format a device]] for further details.
 
See [[File Systems#Format a device]] for further details.
  
Line 119: Line 128:
 
  # mkfs.ext4 /dev/store/home
 
  # mkfs.ext4 /dev/store/home
  
And for the {{ic|/boot}} partition, we choose a non-journalling file system to preserve the flash memory:
+
And for the {{ic|/boot}} partition, if not already formatted as vfat, we choose a non-journalling file system to preserve the flash memory:
  # mkfs.ext2 /dev/sdY1
+
  # mkfs.ext2 /dev/sd''Y''1
  
 
And lastly the swap partition, if required:
 
And lastly the swap partition, if required:
Line 126: Line 135:
 
  # swapon /dev/store/swap
 
  # swapon /dev/store/swap
  
===== Mount the partitions =====
+
==== Mount the partitions ====
 
We are now in a position to mount the partitions and begin the standard Arch installation process.
 
We are now in a position to mount the partitions and begin the standard Arch installation process.
 
  # mount /dev/store/root /mnt
 
  # mount /dev/store/root /mnt
Line 132: Line 141:
 
  # mount /dev/store/home /mnt/home
 
  # mount /dev/store/home /mnt/home
 
  # mkdir /mnt/boot
 
  # mkdir /mnt/boot
  # mount /dev/sdY1 /mnt/boot
+
  # mount /dev/sd''Y''1 /mnt/boot
  
===== Install and configure the base system =====
+
==== Install and configure the base system ====
 
Please follow [[Installation Guide#Install the base system]] until editing {{ic|mkinitcpio.conf}} is required, then add {{ic|encrypt}} to the {{ic|HOOKS}} array as follows:
 
Please follow [[Installation Guide#Install the base system]] until editing {{ic|mkinitcpio.conf}} is required, then add {{ic|encrypt}} to the {{ic|HOOKS}} array as follows:
  
 
{{hc|/etc/mkinitcpio.conf|HOOKS<nowiki>=</nowiki>"base udev ... '''encrypt''' ... filesystems ..."}}
 
{{hc|/etc/mkinitcpio.conf|HOOKS<nowiki>=</nowiki>"base udev ... '''encrypt''' ... filesystems ..."}}
  
For this example, we also require the lvm2 hook, which must be placed after the encrypt hook:
+
For this example we also require the lvm2 hook:
  
 
{{hc|/etc/mkinitcpio.conf|HOOKS<nowiki>=</nowiki>"base udev ... encrypt '''lvm2''' ... filesystems ..."}}
 
{{hc|/etc/mkinitcpio.conf|HOOKS<nowiki>=</nowiki>"base udev ... encrypt '''lvm2''' ... filesystems ..."}}
Line 147: Line 156:
 
  # mkinitcpio -p linux
 
  # mkinitcpio -p linux
  
===== Install and configure the bootloader =====
+
==== Install and configure the bootloader ====
  
 
See [[Installation Guide#Install and configure a bootloader]] and then return to this guide.  
 
See [[Installation Guide#Install and configure a bootloader]] and then return to this guide.  
Line 162: Line 171:
 
<nowiki>cryptkey=<device>:<offset>:<size></nowiki>}}
 
<nowiki>cryptkey=<device>:<offset>:<size></nowiki>}}
  
Which one used will depend on whether the key has been written as a file to a partition, or as a bit stream to unpartitioned space. See [[Creating key files]] for details.
+
Which one used will depend on whether the key has been written as a file to a partition, or as a bit stream to unpartitioned space. See [[Dm-crypt_with_LUKS#Using_Cryptsetup_with_a_Keyfile |here]] for details on different keyfiles.
  
 
{{bc|
 
{{bc|
Line 169: Line 178:
 
Here, the arguments hash, cipher, keysize, offset and skip relate directly to the ''cryptsetup'' options --hash, --cipher, --key-size, --offset and --skip.
 
Here, the arguments hash, cipher, keysize, offset and skip relate directly to the ''cryptsetup'' options --hash, --cipher, --key-size, --offset and --skip.
  
====== Example with defaults ======
+
===== Example with defaults =====
  
 
For a disk encrypted with just default options, we can use the following kernel arguments:
 
For a disk encrypted with just default options, we can use the following kernel arguments:
Line 177: Line 186:
 
The {{ic|crypto}} argument must still be specified, but each entry can be left blank. This will prompt for the pass-phrase on boot.
 
The {{ic|crypto}} argument must still be specified, but each entry can be left blank. This will prompt for the pass-phrase on boot.
  
====== Example custom options ======
+
===== Example custom options =====
  
 
Assuming the key file is located on {{ic|/dev/sd''Z''}} and the options are as used in the previous example, we have:
 
Assuming the key file is located on {{ic|/dev/sd''Z''}} and the options are as used in the previous example, we have:
Line 193: Line 202:
 
This can then be used to update {{ic|grub.cfg}}
 
This can then be used to update {{ic|grub.cfg}}
 
  # grub-mkconfig -o /boot/grub/grub.cfg
 
  # grub-mkconfig -o /boot/grub/grub.cfg
====Post-installation====
+
 
You may wish to remove the USB sticks after booting. Since the {{ic|/boot}} partition is not usually needed, the following option can be added to the boot options in /etc/fstab:
+
The bootloader can then be installed on the same USB as the {{ic|/boot}} partition:
 +
# grub-install --recheck /dev/sd''Y''
 +
 
 +
===Post-installation===
 +
You may wish to remove the USB sticks after booting. Since the {{ic|/boot}} partition is not usually needed, the following option can be added to the boot options in {{ic|/etc/fstab}}:
  
 
{{hc|/etc/fstab|
 
{{hc|/etc/fstab|
 
# /dev/sd''Yn''
 
# /dev/sd''Yn''
<nowiki>UUID=************* /boot ext2 '''noauto''',rw,noatime 0 2</nowiki>}}
+
<nowiki>UUID=</nowiki>************* /boot ext2 '''noauto''',rw,noatime 0 2}}
  
 
However, when an update to the kernel or bootloader is required, the {{ic|/boot}} partition must be present and mounted. As the entry in {{ic|fstab}} already exists, it can be mounted simply with:
 
However, when an update to the kernel or bootloader is required, the {{ic|/boot}} partition must be present and mounted. As the entry in {{ic|fstab}} already exists, it can be mounted simply with:
  
 
  # mount /boot
 
  # mount /boot

Revision as of 17:47, 7 October 2013

Merge-arrows-2.pngThis article or section is a candidate for merging with Dm-crypt with LUKS.Merge-arrows-2.png

Notes: Assess the possibility of merging the common content between the two articles in order to avoid duplication. (Discuss in Talk:Plain dm-crypt without LUKS#Merge)
Summary help replacing me
This tutorial will show you how to set up system encryption with plain dm-crypt.
Related
Disk Encryption
Dm-crypt with LUKS

This article focuses on system disk encryption using plain dm-crypt without LUKS.

dm-crypt is the standard device-mapper encryption functionality provided by the Linux kernel. It can be used directly by those who like to have full control over all aspects of partition and key management.

Plain dm-crypt vs LUKS format

For most use cases, dm-crypt with LUKS is by far the better option for both system encryption and encrypted partitions. Below are some considerations for choosing one over the other.

Advantages

  • dm-crypt does not require a header on the encrypted disk. This means that an unpartitioned, encrypted disk will be indistinguishable from a disk filled with random data. This may be useful in a country that can force you to give up an encryption key where a reasonable suspicion of encrypted data exists.
  • plain dm-crypt encrypted disks are more resilient to damage than LUKS encrypted disks, because of the one-to-one mapping of unencrypted data to encrypted data.

Disadvantages

  • dm-crypt does not allow multiple pass-phrases, nor does it allow changes to the pass-phase or key-file after initial set-up. LUKS allows for up to eight passphrases, and key-files and passphrases can be changed without having to re-encrypt the entire disk or partition.
  • plain dm-crypt requires manual configuration of encryption options each time a device is opened, whereas LUKS stores those details in its header.
  • LUKS uses pass-phrase salting and hash iteration, and as such can be more secure than plain dm-crypt. It is essential that a pass-phrase or key-file with very high entropy is used with dm-crypt.

See https://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions for further details.

Encrypting system partitions

A separate /boot partition is required, as it needs to remain unencrypted to be accessed by the bootloader. In the scenario that follows, it is assumed that no evidence of encryption is to be left on the main system drive, and so we install the /boot partition and the bootloader to a separate USB stick, and the encryption key to yet another USB stick. Throughout the guide, the system disk will be shown as /dev/sdX, the USB stick containing /boot will be shown as /dev/sdY, and the USB stick containing the encryption key will be shown as /dev/sdZ, where X, Y and Z represent their respective device letters.

Tip: The essential process of filling an encrypted drive can take over a day to complete on a multi-terrabyte disk. It is therefore suggested that the following steps, up until #Mount the partitions, be done from another installation rather than the Arch installation media.

Preparation

Safety first

We must first make absolutely sure we are targeting the correct disk:

# fdisk -l

Load the kernel module

 # modprobe dm-crypt

Setup encryption

Cryptsetup is used to create the mapping between an encrypted disk and a named device. Its form in this case is:

# cryptsetup <options> open --type plain <device> <name>
Options
Option Description Examples Default
--hash The hash is used to create the key from the passphrase or keyfile whirlpool, sha1, sha256, sha512, ripemd160 ripemd160
--cipher The cipher consists of three parts: cipher-chainmode-IV generator. Please see Wikipedia:Disk encryption theory for an explanation of these settings, and DMCrypt for some of the options available. aes-xts-plain64, twofish-cbc-essiv:sha256, serpent-cbc-plain aes-cbc-essiv:sha256
--key-size The key size (in bits). The size will depend on the cipher being used and also the chainmode in use. Xts mode will require twice the key size of cbc, which should be apparent from the output of cryptsetup benchmark. 128, 256, 512 256bits
--offset The offset from the beginning of the target disk from which to start the mapping 0 Unknown, but it does not appear to be 0.
--key-file The device or file to be used as a key. See here for further details. /dev/sdZ, /boot/keyfile.enc Uses passphrase instead.
--keyfile-offset Offset from the beginning of the key file (in bytes) from which to read. 2049 0
--keyfile-size Limits the bytes read from the key file. However, I have found that this is ignored when using plain dm-crypt. Instead, the size will depend on the key-size used. 512B 8192kB

Dm-crypt does not need a partition table and the existence of one could provide a reasonable suspicion that the drive is encrypted. We therefore set up the encryption directly on the physical disk. If a partition table already exists on the target disk, it will be wiped when we later fill the disk.

Example with default options

Using default options with the device /dev/sdX and using enc for the mapped name, we have:

# cryptsetup open --type plain /dev/sdX enc

You will then be prompted for a password twice, which should have very high entropy. See https://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions#5._Security_Aspects for details.

Example with custom options

If custom options are required, you may wish to test which encryption system works best on your system:

# cryptsetup benchmark

Using the device /dev/sdX, with the twofish-xts cipher with a 512 bit key size we have:

# cryptsetup --hash=sha512 --cipher=twofish-xts-plain64 --offset=0 --key-file=/dev/sdZ --key-size=512 open --type=plain /dev/sdX enc

Unlike encrypting with LUKS, the above command must be executed in full whenever the mapping needs to be re-established, so it is important to remember the cipher, hash and key file details. We can now check that the mapping has been made:

# fdisk -l

An entry should now exist for /dev/mapper/enc.

Fill the mapped device

Note: It is vital that the mapped device is filled with data. Without doing so, the encrypted data that is written to disk will be easily distinguishable from areas not yet written to.
Warning: The following operation will destroy all data on the underlying physical disk.

In this case, with /dev/mapper/enc, we use:

# dd if=/dev/zero of=/dev/mapper/enc

or

# cat /dev/zero > /dev/mapper/enc

Use of /dev/urandom is not required here, as anything written to the mapped device is passed through the encryption cipher before being written to disk.

When the process is finished, you may wish to check to see if any existing partition table has been wiped:

# fdisk -l
Note: The partition table will only have been wiped if the offset was set to 0. As a side effect of this, the disk will no longer be addressable by UUID, however it can still be addressed by physical ID (/dev/disk/by-id).

Install the system

Much of the following steps are identical to those in the Installation Guide. Where they differ is:

  • the target installation device is the mapped device under /dev/mapper/* instead of the physical device /dev/sdX;
  • /boot and the bootloader will be installed to a USB stick;
  • the initramfs hook encrypt is added to mkinitcpio.conf;
  • the details of the encryption are added to the kernel options in the bootloader.

Partition disks

See Partitioning for further details.

You may use fdisk to create a standard partition table on the mapped device:

# fdisk /dev/mapper/enc

However, a more flexible approach is to use LVM:

# pvcreate /dev/mapper/enc
# vgcreate store /dev/mapper/enc
# lvcreate -L 20G store -n root
# lvcreate -C y -L 10G store -n swap
# lvcreate -l +100%FREE store -n home

See Lvm#Installing_Arch_Linux_on_LVM for further details.

For the remainder of this guide we will use the simple LVM volume set created above, which will have created the volumes /dev/store/root, /dev/store/home and /dev/store/swap. The choice of volume group name and logical volume names are arbitrary.

The /boot partition can be installed on the standard vfat partition of a USB stick, if required. But if manual partitioning is needed, then a small 200MB partition is all that is required:

# fdisk /dev/sdY
> n
> p
> 1
> default (2048)
> +200M
> w
> q

Format the partitions

See File Systems#Format a device for further details.

In our example, we will simply use ext4 for root and home.

# mkfs.ext4 /dev/store/root
# mkfs.ext4 /dev/store/home

And for the /boot partition, if not already formatted as vfat, we choose a non-journalling file system to preserve the flash memory:

# mkfs.ext2 /dev/sdY1

And lastly the swap partition, if required:

# mkswap /dev/store/swap
# swapon /dev/store/swap

Mount the partitions

We are now in a position to mount the partitions and begin the standard Arch installation process.

# mount /dev/store/root /mnt
# mkdir /mnt/home
# mount /dev/store/home /mnt/home
# mkdir /mnt/boot
# mount /dev/sdY1 /mnt/boot

Install and configure the base system

Please follow Installation Guide#Install the base system until editing mkinitcpio.conf is required, then add encrypt to the HOOKS array as follows:

/etc/mkinitcpio.conf
HOOKS="base udev ... encrypt ... filesystems ..."

For this example we also require the lvm2 hook:

/etc/mkinitcpio.conf
HOOKS="base udev ... encrypt lvm2 ... filesystems ..."

Then rebuild the initramfs as per usual:

# mkinitcpio -p linux

Install and configure the bootloader

See Installation Guide#Install and configure a bootloader and then return to this guide.

The kernel arguments for initialising a plain dm-crypt disk are as follows:

cryptdevice=/dev/sdX:<mapped name>

Where /dev/sdX is the physical disk containing the encrypted data, and <mapped name> is the name once mapped to /dev/mapper/<mapped name>.

cryptkey=/path/to/keyfile
or
cryptkey=<device>:<offset>:<size>

Which one used will depend on whether the key has been written as a file to a partition, or as a bit stream to unpartitioned space. See here for details on different keyfiles.

crypto=<hash>:<cipher>:<keysize>:<offset>:<skip>

Here, the arguments hash, cipher, keysize, offset and skip relate directly to the cryptsetup options --hash, --cipher, --key-size, --offset and --skip.

Example with defaults

For a disk encrypted with just default options, we can use the following kernel arguments:

cryptdevice=/dev/sdX:enc crypto=::::

The crypto argument must still be specified, but each entry can be left blank. This will prompt for the pass-phrase on boot.

Example custom options

Assuming the key file is located on /dev/sdZ and the options are as used in the previous example, we have:

cryptdevice=/dev/sdX:enc cryptkey=/dev/sdZ:0:512 crypto=sha512:twofish-xts-plain64:512:0:

If using grub, this is added to /etc/default/grub:

/etc/default/grub
GRUB_CMDLINE_LINUX="cryptdevice=/dev/sdX:enc cryptkey=/dev/sdZ:0:512 crypto=sha512:twofish-xts-plain64:512:0:"

You may also wish to add:

/etc/default/grub
GRUB_CMDLINE_LINUX="... root=/dev/store/root"

Although it should not be necessary.

This can then be used to update grub.cfg

# grub-mkconfig -o /boot/grub/grub.cfg

The bootloader can then be installed on the same USB as the /boot partition:

# grub-install --recheck /dev/sdY

Post-installation

You may wish to remove the USB sticks after booting. Since the /boot partition is not usually needed, the following option can be added to the boot options in /etc/fstab:

/etc/fstab
# /dev/sdYn
UUID=************* /boot ext2 noauto,rw,noatime 0 2

However, when an update to the kernel or bootloader is required, the /boot partition must be present and mounted. As the entry in fstab already exists, it can be mounted simply with:

# mount /boot