blob: ff1f87bf26e8ad10e7327ecd74a87cb3a6e64058 [file] [log] [blame]
Milan Broze3dcc5a2008-04-24 22:11:03 +01001dm-crypt
2=========
3
4Device-Mapper's "crypt" target provides transparent encryption of block devices
5using the kernel crypto API.
6
Milan Brozed04d982013-10-28 23:21:04 +01007For a more detailed description of supported parameters see:
Milan Broze44f23b2015-04-05 18:03:10 +02008https://gitlab.com/cryptsetup/cryptsetup/wikis/DMCrypt
Milan Brozed04d982013-10-28 23:21:04 +01009
Milan Broz772ae5f2011-08-02 12:32:08 +010010Parameters: <cipher> <key> <iv_offset> <device path> \
11 <offset> [<#opt_params> <opt_params>]
Milan Broze3dcc5a2008-04-24 22:11:03 +010012
13<cipher>
14 Encryption cipher and an optional IV generation mode.
Milan Brozed04d982013-10-28 23:21:04 +010015 (In format cipher[:keycount]-chainmode-ivmode[:ivopts]).
Milan Broze3dcc5a2008-04-24 22:11:03 +010016 Examples:
17 des
18 aes-cbc-essiv:sha256
19 twofish-ecb
20
21 /proc/crypto contains supported crypto modes
22
23<key>
Ondrej Kozinac538f6e2016-11-21 15:58:51 +010024 Key used for encryption. It is encoded either as a hexadecimal number
25 or it can be passed as <key_string> prefixed with single colon
26 character (':') for keys residing in kernel keyring service.
Milan Brozed04d982013-10-28 23:21:04 +010027 You can only use key sizes that are valid for the selected cipher
28 in combination with the selected iv mode.
29 Note that for some iv modes the key string can contain additional
30 keys (for example IV seed) so the key contains more parts concatenated
31 into a single string.
Milan Broze3dcc5a2008-04-24 22:11:03 +010032
Ondrej Kozinac538f6e2016-11-21 15:58:51 +010033<key_string>
34 The kernel keyring key is identified by string in following format:
35 <key_size>:<key_type>:<key_description>.
36
37<key_size>
38 The encryption key size in bytes. The kernel key payload size must match
39 the value passed in <key_size>.
40
41<key_type>
42 Either 'logon' or 'user' kernel key type.
43
44<key_description>
45 The kernel keyring key description crypt target should look for
46 when loading key of <key_type>.
47
Milan Brozd1f96422011-01-13 19:59:54 +000048<keycount>
49 Multi-key compatibility mode. You can define <keycount> keys and
50 then sectors are encrypted according to their offsets (sector 0 uses key0;
51 sector 1 uses key1 etc.). <keycount> must be a power of two.
52
Milan Broze3dcc5a2008-04-24 22:11:03 +010053<iv_offset>
54 The IV offset is a sector count that is added to the sector number
55 before creating the IV.
56
57<device path>
58 This is the device that is going to be used as backend and contains the
59 encrypted data. You can specify it as a path like /dev/xxx or a device
60 number <major>:<minor>.
61
62<offset>
63 Starting sector within the device where the encrypted data begins.
64
Milan Broz772ae5f2011-08-02 12:32:08 +010065<#opt_params>
66 Number of optional parameters. If there are no optional parameters,
67 the optional paramaters section can be skipped or #opt_params can be zero.
68 Otherwise #opt_params is the number of following arguments.
69
70 Example of optional parameters section:
Mikulas Patocka0f5d8e62015-02-13 08:27:08 -050071 3 allow_discards same_cpu_crypt submit_from_crypt_cpus
Milan Broz772ae5f2011-08-02 12:32:08 +010072
73allow_discards
74 Block discard requests (a.k.a. TRIM) are passed through the crypt device.
75 The default is to ignore discard requests.
76
77 WARNING: Assess the specific security risks carefully before enabling this
78 option. For example, allowing discards on encrypted devices may lead to
79 the leak of information about the ciphertext device (filesystem type,
80 used space etc.) if the discarded blocks can be located easily on the
81 device later.
82
Mikulas Patockaf3396c582015-02-13 08:23:09 -050083same_cpu_crypt
84 Perform encryption using the same cpu that IO was submitted on.
85 The default is to use an unbound workqueue so that encryption work
86 is automatically balanced between available CPUs.
87
Mikulas Patocka0f5d8e62015-02-13 08:27:08 -050088submit_from_crypt_cpus
89 Disable offloading writes to a separate thread after encryption.
90 There are some situations where offloading write bios from the
91 encryption threads to a single thread degrades performance
92 significantly. The default is to offload write bios to the same
93 thread because it benefits CFQ to have writes submitted using the
94 same context.
95
Milan Broze3dcc5a2008-04-24 22:11:03 +010096Example scripts
97===============
98LUKS (Linux Unified Key Setup) is now the preferred way to set up disk
99encryption with dm-crypt using the 'cryptsetup' utility, see
Milan Broze44f23b2015-04-05 18:03:10 +0200100https://gitlab.com/cryptsetup/cryptsetup
Milan Broze3dcc5a2008-04-24 22:11:03 +0100101
102[[
103#!/bin/sh
104# Create a crypt device using dmsetup
Michael Witten95f21c52016-09-01 19:38:30 +0000105dmsetup create crypt1 --table "0 `blockdev --getsz $1` crypt aes-cbc-essiv:sha256 babebabebabebabebabebabebabebabe 0 $1 0"
Milan Broze3dcc5a2008-04-24 22:11:03 +0100106]]
107
108[[
109#!/bin/sh
Ondrej Kozinac538f6e2016-11-21 15:58:51 +0100110# Create a crypt device using dmsetup when encryption key is stored in keyring service
111dmsetup create crypt2 --table "0 `blockdev --getsize $1` crypt aes-cbc-essiv:sha256 :32:logon:my_prefix:my_key 0 $1 0"
112]]
113
114[[
115#!/bin/sh
Milan Broze3dcc5a2008-04-24 22:11:03 +0100116# Create a crypt device using cryptsetup and LUKS header with default cipher
117cryptsetup luksFormat $1
118cryptsetup luksOpen $1 crypt1
119]]