123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596 |
- dm-crypt
- =========
- Device-Mapper's "crypt" target provides transparent encryption of block devices
- using the kernel crypto API.
- For a more detailed description of supported parameters see:
- https://gitlab.com/cryptsetup/cryptsetup/wikis/DMCrypt
- Parameters: <cipher> <key> <iv_offset> <device path> \
- <offset> [<#opt_params> <opt_params>]
- <cipher>
- Encryption cipher and an optional IV generation mode.
- (In format cipher[:keycount]-chainmode-ivmode[:ivopts]).
- Examples:
- des
- aes-cbc-essiv:sha256
- twofish-ecb
- /proc/crypto contains supported crypto modes
- <key>
- Key used for encryption. It is encoded as a hexadecimal number.
- You can only use key sizes that are valid for the selected cipher
- in combination with the selected iv mode.
- Note that for some iv modes the key string can contain additional
- keys (for example IV seed) so the key contains more parts concatenated
- into a single string.
- <keycount>
- Multi-key compatibility mode. You can define <keycount> keys and
- then sectors are encrypted according to their offsets (sector 0 uses key0;
- sector 1 uses key1 etc.). <keycount> must be a power of two.
- <iv_offset>
- The IV offset is a sector count that is added to the sector number
- before creating the IV.
- <device path>
- This is the device that is going to be used as backend and contains the
- encrypted data. You can specify it as a path like /dev/xxx or a device
- number <major>:<minor>.
- <offset>
- Starting sector within the device where the encrypted data begins.
- <#opt_params>
- Number of optional parameters. If there are no optional parameters,
- the optional paramaters section can be skipped or #opt_params can be zero.
- Otherwise #opt_params is the number of following arguments.
- Example of optional parameters section:
- 3 allow_discards same_cpu_crypt submit_from_crypt_cpus
- allow_discards
- Block discard requests (a.k.a. TRIM) are passed through the crypt device.
- The default is to ignore discard requests.
- WARNING: Assess the specific security risks carefully before enabling this
- option. For example, allowing discards on encrypted devices may lead to
- the leak of information about the ciphertext device (filesystem type,
- used space etc.) if the discarded blocks can be located easily on the
- device later.
- same_cpu_crypt
- Perform encryption using the same cpu that IO was submitted on.
- The default is to use an unbound workqueue so that encryption work
- is automatically balanced between available CPUs.
- submit_from_crypt_cpus
- Disable offloading writes to a separate thread after encryption.
- There are some situations where offloading write bios from the
- encryption threads to a single thread degrades performance
- significantly. The default is to offload write bios to the same
- thread because it benefits CFQ to have writes submitted using the
- same context.
- Example scripts
- ===============
- LUKS (Linux Unified Key Setup) is now the preferred way to set up disk
- encryption with dm-crypt using the 'cryptsetup' utility, see
- https://gitlab.com/cryptsetup/cryptsetup
- [[
- #!/bin/sh
- # Create a crypt device using dmsetup
- dmsetup create crypt1 --table "0 `blockdev --getsize $1` crypt aes-cbc-essiv:sha256 babebabebabebabebabebabebabebabe 0 $1 0"
- ]]
- [[
- #!/bin/sh
- # Create a crypt device using cryptsetup and LUKS header with default cipher
- cryptsetup luksFormat $1
- cryptsetup luksOpen $1 crypt1
- ]]
|