]>
Commit | Line | Data |
---|---|---|
e3dcc5a3 MB |
1 | dm-crypt |
2 | ========= | |
3 | ||
4 | Device-Mapper's "crypt" target provides transparent encryption of block devices | |
5 | using the kernel crypto API. | |
6 | ||
ed04d981 | 7 | For a more detailed description of supported parameters see: |
e44f23b3 | 8 | https://gitlab.com/cryptsetup/cryptsetup/wikis/DMCrypt |
ed04d981 | 9 | |
772ae5f5 MB |
10 | Parameters: <cipher> <key> <iv_offset> <device path> \ |
11 | <offset> [<#opt_params> <opt_params>] | |
e3dcc5a3 MB |
12 | |
13 | <cipher> | |
33d2f09f MB |
14 | Encryption cipher, encryption mode and Initial Vector (IV) generator. |
15 | ||
16 | The cipher specifications format is: | |
17 | cipher[:keycount]-chainmode-ivmode[:ivopts] | |
e3dcc5a3 | 18 | Examples: |
e3dcc5a3 | 19 | aes-cbc-essiv:sha256 |
33d2f09f MB |
20 | aes-xts-plain64 |
21 | serpent-xts-plain64 | |
22 | ||
23 | Cipher format also supports direct specification with kernel crypt API | |
24 | format (selected by capi: prefix). The IV specification is the same | |
25 | as for the first format type. | |
26 | This format is mainly used for specification of authenticated modes. | |
e3dcc5a3 | 27 | |
33d2f09f MB |
28 | The crypto API cipher specifications format is: |
29 | capi:cipher_api_spec-ivmode[:ivopts] | |
30 | Examples: | |
31 | capi:cbc(aes)-essiv:sha256 | |
32 | capi:xts(aes)-plain64 | |
33 | Examples of authenticated modes: | |
34 | capi:gcm(aes)-random | |
35 | capi:authenc(hmac(sha256),xts(aes))-random | |
36 | capi:rfc7539(chacha20,poly1305)-random | |
37 | ||
38 | The /proc/crypto contains a list of curently loaded crypto modes. | |
e3dcc5a3 MB |
39 | |
40 | <key> | |
c538f6ec OK |
41 | Key used for encryption. It is encoded either as a hexadecimal number |
42 | or it can be passed as <key_string> prefixed with single colon | |
43 | character (':') for keys residing in kernel keyring service. | |
ed04d981 MB |
44 | You can only use key sizes that are valid for the selected cipher |
45 | in combination with the selected iv mode. | |
46 | Note that for some iv modes the key string can contain additional | |
47 | keys (for example IV seed) so the key contains more parts concatenated | |
48 | into a single string. | |
e3dcc5a3 | 49 | |
c538f6ec OK |
50 | <key_string> |
51 | The kernel keyring key is identified by string in following format: | |
52 | <key_size>:<key_type>:<key_description>. | |
53 | ||
54 | <key_size> | |
55 | The encryption key size in bytes. The kernel key payload size must match | |
56 | the value passed in <key_size>. | |
57 | ||
58 | <key_type> | |
59 | Either 'logon' or 'user' kernel key type. | |
60 | ||
61 | <key_description> | |
62 | The kernel keyring key description crypt target should look for | |
63 | when loading key of <key_type>. | |
64 | ||
d1f96423 MB |
65 | <keycount> |
66 | Multi-key compatibility mode. You can define <keycount> keys and | |
67 | then sectors are encrypted according to their offsets (sector 0 uses key0; | |
68 | sector 1 uses key1 etc.). <keycount> must be a power of two. | |
69 | ||
e3dcc5a3 MB |
70 | <iv_offset> |
71 | The IV offset is a sector count that is added to the sector number | |
72 | before creating the IV. | |
73 | ||
74 | <device path> | |
75 | This is the device that is going to be used as backend and contains the | |
76 | encrypted data. You can specify it as a path like /dev/xxx or a device | |
77 | number <major>:<minor>. | |
78 | ||
79 | <offset> | |
80 | Starting sector within the device where the encrypted data begins. | |
81 | ||
772ae5f5 MB |
82 | <#opt_params> |
83 | Number of optional parameters. If there are no optional parameters, | |
84 | the optional paramaters section can be skipped or #opt_params can be zero. | |
85 | Otherwise #opt_params is the number of following arguments. | |
86 | ||
87 | Example of optional parameters section: | |
0f5d8e6e | 88 | 3 allow_discards same_cpu_crypt submit_from_crypt_cpus |
772ae5f5 MB |
89 | |
90 | allow_discards | |
91 | Block discard requests (a.k.a. TRIM) are passed through the crypt device. | |
92 | The default is to ignore discard requests. | |
93 | ||
94 | WARNING: Assess the specific security risks carefully before enabling this | |
95 | option. For example, allowing discards on encrypted devices may lead to | |
96 | the leak of information about the ciphertext device (filesystem type, | |
97 | used space etc.) if the discarded blocks can be located easily on the | |
98 | device later. | |
99 | ||
f3396c58 MP |
100 | same_cpu_crypt |
101 | Perform encryption using the same cpu that IO was submitted on. | |
102 | The default is to use an unbound workqueue so that encryption work | |
103 | is automatically balanced between available CPUs. | |
104 | ||
0f5d8e6e MP |
105 | submit_from_crypt_cpus |
106 | Disable offloading writes to a separate thread after encryption. | |
107 | There are some situations where offloading write bios from the | |
108 | encryption threads to a single thread degrades performance | |
109 | significantly. The default is to offload write bios to the same | |
110 | thread because it benefits CFQ to have writes submitted using the | |
111 | same context. | |
112 | ||
ef43aa38 | 113 | integrity:<bytes>:<type> |
33d2f09f MB |
114 | The device requires additional <bytes> metadata per-sector stored |
115 | in per-bio integrity structure. This metadata must by provided | |
116 | by underlying dm-integrity target. | |
ef43aa38 | 117 | |
33d2f09f | 118 | The <type> can be "none" if metadata is used only for persistent IV. |
ef43aa38 | 119 | |
33d2f09f MB |
120 | For Authenticated Encryption with Additional Data (AEAD) |
121 | the <type> is "aead". An AEAD mode additionally calculates and verifies | |
122 | integrity for the encrypted device. The additional space is then | |
123 | used for storing authentication tag (and persistent IV if needed). | |
ef43aa38 | 124 | |
8f0009a2 MB |
125 | sector_size:<bytes> |
126 | Use <bytes> as the encryption unit instead of 512 bytes sectors. | |
127 | This option can be in range 512 - 4096 bytes and must be power of two. | |
128 | Virtual device will announce this size as a minimal IO and logical sector. | |
129 | ||
130 | iv_large_sectors | |
131 | IV generators will use sector number counted in <sector_size> units | |
132 | instead of default 512 bytes sectors. | |
133 | ||
134 | For example, if <sector_size> is 4096 bytes, plain64 IV for the second | |
135 | sector will be 8 (without flag) and 1 if iv_large_sectors is present. | |
136 | The <iv_offset> must be multiple of <sector_size> (in 512 bytes units) | |
137 | if this flag is specified. | |
138 | ||
e3dcc5a3 MB |
139 | Example scripts |
140 | =============== | |
141 | LUKS (Linux Unified Key Setup) is now the preferred way to set up disk | |
142 | encryption with dm-crypt using the 'cryptsetup' utility, see | |
e44f23b3 | 143 | https://gitlab.com/cryptsetup/cryptsetup |
e3dcc5a3 MB |
144 | |
145 | [[ | |
146 | #!/bin/sh | |
147 | # Create a crypt device using dmsetup | |
95f21c5c | 148 | dmsetup create crypt1 --table "0 `blockdev --getsz $1` crypt aes-cbc-essiv:sha256 babebabebabebabebabebabebabebabe 0 $1 0" |
e3dcc5a3 MB |
149 | ]] |
150 | ||
c538f6ec OK |
151 | [[ |
152 | #!/bin/sh | |
153 | # Create a crypt device using dmsetup when encryption key is stored in keyring service | |
154 | dmsetup create crypt2 --table "0 `blockdev --getsize $1` crypt aes-cbc-essiv:sha256 :32:logon:my_prefix:my_key 0 $1 0" | |
155 | ]] | |
156 | ||
e3dcc5a3 MB |
157 | [[ |
158 | #!/bin/sh | |
159 | # Create a crypt device using cryptsetup and LUKS header with default cipher | |
160 | cryptsetup luksFormat $1 | |
161 | cryptsetup luksOpen $1 crypt1 | |
162 | ]] |