Only basic corruptions of unused keyslot are fixable. This command will only change the LUKS header, not any key-slot data. To benchmark other ciphers or modes, you need to specify --cipher and --key-size options or --hash for KDF test. NOTE: This benchmark is using memory only and is only informative. You cannot directly predict real storage encryption speed from it. For testing block ciphers, this benchmark requires kernel userspace crypto API to be available introduced in Linux kernel 2.
The specified hash name is passed to the compiled-in crypto backend. Different backends may support different hashes. For luksFormat , the hash algorithm must provide at least bits of output, which excludes, e. Do not use a non-crypto hash like "crc32" as this breaks security. Values compatible with old version of cryptsetup are "ripemd" for open --type plain and "sha1" for luksFormat. The current default in the distributed sources is "aes-cbc-essiv:sha" for plain dm-crypt and "aes-xts-plain64" for LUKS.
If a hash is part of the cipher specification, then it is used as part of the IV generation. For XTS mode you can optionally set a key size of bits with the -s option. Key size for XTS mode is twice that for other modes for the same security level. XTS mode requires kernel 2. More information can be found in the FAQ.
If the name given is "-", then the passphrase will be read from stdin. In this case, reading will not stop at newline characters. With LUKS, passphrases supplied via --key-file are always the existing passphrases requested by a command, except in the case of luksFormat where --key-file is equivalent to the positional key file argument.
If you want to set a new passphrase via key file, you have to use a positional argument to luksAddKey. This option is useful to cut trailing newlines, for example.
If --keyfile-offset is also given, the size count starts after the offset. Works with all commands that accepts key files.
If the master key was taken from an existing LUKS header and all other parameters are the same, then the new header decrypts the data encrypted with the header the master key was taken from. Otherwise you can end up with a low-entropy or otherwise partially predictable master key which will compromise security.
For luksAddKey this allows adding a new passphrase without having to know an exiting one. For open this allows one to open the LUKS device without giving a passphrase. Use cryptsetup --help to show the compiled-in default random number generator.
This option can be used for open --type plain or luksFormat. Use cryptsetup --help to show the compiled-in defaults. Hence, if --offset n , and --skip s , sector n the first sector of encrypted device will get a sector number of s for the IV calculation.
If the -y option is not specified, this option also switches off the passphrase verification for luksFormat. If not specified, cryptsetup tries to use the topology info provided by kernel for the underlying device to get optimal alignment. If not available or the calculated value is a multiple of the default data is by default aligned to a 1MiB boundary i. For a detached LUKS header this option specifies the offset on the data device.
See also the --header option. WARNING: This command can have a negative security impact because it can make filesystem-level operations visible on the physical device.
For example, information leaking filesystem type, used space, etc. If in doubt, do not use it. A kernel version of 3. For earlier kernels this option is ignored. NOTE: This option is available only for low-level dm-crypt performance tuning, use only if you need a change to default dm-crypt behaviour.
Needs kernel 4. This option is only relevant for LUKS devices and can be used with the luksFormat , open , luksSuspend , luksResume , status and resize commands. For luksFormat with a file name as argument to --header, it has to exist and be large enough to contain the LUKS header. See the cryptsetup FAQ for header size calculation. For other commands that change the LUKS header e. If used with luksFormat , the --align-payload option is taken as absolute sector alignment on ciphertext device and can be zero.
In fact you can specify an arbitrary device as the ciphertext device for open with the --header option. Use with care. This option applies only to luksFormat , luksAddKey and luksChangeKey and is ignored if cryptsetup is built without password quality checking support. For more info about password quality check, see manual page for pwquality. Error codes are: 1 wrong parameters, 2 no permission bad passphrase , 3 out of memory, 4 wrong device specified, 5 device already exists or device is busy.
From a terminal : The passphrase is read until the first newline, i. The input without the newline character is processed with the default hash or the hash specified with --hash. The hash result will be truncated to the key size of the used cipher, or the size specified with -s. From stdin : Reading will continue until a newline or until the maximum input size is reached , with the trailing newline stripped. The maximum input size is defined by the same compiled-in default as for the maximum key file size and can be overwritten using --keyfile-size option.
The data read will be hashed with the default hash or the hash specified with --hash. For plain crypt device, the whole device size is used. Note that this does not change the raw device geometry, it just changes how many sectors of the raw device are represented in the mapped device. If cryptsetup detected volume key for active device loaded in kernel keyring service, resize action would first try to retrieve the key using a token and only if it failed it'd ask for a passphrase to unlock a keyslot LUKS or to derive a volume key again plain mode.
The kernel keyring is used by default for LUKS2 devices. No checks are performed, no metadata is used. There is no formatting operation. When the raw device is mapped opened , the usual device operations can be used on the mapped device, including filesystem creation. It adds a standardized header at the start of the device, a key-slot area directly behind the header and the bulk data area behind that.
The whole set is called a 'LUKS container'. For most purposes, both terms can be used interchangeably. LUKS can manage multiple passphrases that can be individually revoked or changed and that can be securely scrubbed from persistent media due to the use of anti-forensic stripes.
Passphrases are protected against brute-force and dictionary attacks by PBKDF2, which implements hash iteration and salting in one function. For activation, the format is already recognized automatically.
Each passphrase, also called a key in this document, is associated with one of 8 key- slots. Key operations that do not specify a slot affect the first slot that matches the supplied passphrase or the first empty slot if a new passphrase is added.
Note that if the second argument is present, then the passphrase is taken from the file given there, without the need to use the --key-file option.
Also note that for both forms of reading the passphrase from a file you can give '-' as file name, which results in the passphrase being read from stdin and the safety-question being skipped. To use LUKS2, specify --type luks2. First, the passphrase is searched in LUKS tokens. If it's not found in any token and also the passphrase is not supplied via --key-file, the command prompts for it interactively.
Needs kernel 2. After this operation you have to use luksResume to reinstate the encryption key and unblock the device or close to remove the mapped device. Prompts interactively for a passphrase if --key-file is not given. An existing passphrase must be supplied interactively or via --key-file. The new passphrase to be added can be specified interactively or read from the file given as positional argument.
The passphrase to be removed can be specified interactively, as the positional argument or via --key-file. Removing the last passphrase makes the LUKS container permanently inaccessible. The passphrase to be changed must be supplied interactively or via --key-file. The new passphrase can be supplied interactively or in a file given as positional argument.
If a key-slot is specified via --key-slot , the passphrase for that key-slot must be given and the new passphrase will overwrite the specified key-slot. If no key- slot is specified and there is still a free key-slot, then the new passphrase will be put into a free key-slot before the key-slot containing the old passphrase is purged. If there is no free key-slot, then the key-slot with the old passphrase is overwritten directly.
Except running in batch- mode -q a remaining passphrase must be supplied, either interactively or via --key-file. This command can remove the last remaining key-slot, but requires an interactive confirmation when doing so. Removing the last passphrase makes a LUKS container permanently inaccessible.
WARNING: If you read the passphrase from stdin without further argument or with '-' as an argument to --key-file , batch-mode -q will be implicitly switched on and no warning will be given when you remove the last remaining passphrase from a LUKS container.
NOTE: If there is no passphrase provided on stdin or through --key-file argument and batch-mode -q is active, the key-slot is removed without any other warning. You do not need to provide any password for this operation. Set new UUID if --uuid option is specified. Use option -v to get human-readable feedback. If the --dump-master-key option is used, the LUKS device master key is dumped instead of the keyslot info. Beware that the master key cannot be changed and can be used to decrypt the data stored in the LUKS container without a passphrase and even without the LUKS header.
This means that if the master key is compromised, the whole device has to be erased to prevent further access. Use this option carefully. To dump the master key, a passphrase has to be supplied, either interactively or via --key-file. WARNING: If --dump-master-key is used with --key-file and the argument to --key-file is '-', no validation question will be asked and no warning given.
Note: Using '-' as filename writes the header backup to a file named '-'. Also note that with a header backup you lose the ability to securely wipe the LUKS device by just overwriting the header and key- slots. You either need to securely erase all header backups in addition or overwrite the encrypted data area as well. The second option is less secure, as some sectors can survive, e.
Note: Using '-' as filename reads the header backup from a file named '-'. This command requires that the master key size and data offset of the LUKS header already on the device and of the header backup match. Alternatively, if there is no LUKS header on the device, the backup will also be written to it.
For the auto- activation, the passphrase must be stored in keyring with the specified description. Usually, the passphrase should be stored in user or user-session keyring. The token command is supported only for LUKS2. For adding new keyring token, option --key-description is mandatory. Also, new token is assigned to key slot specified with --key-slot option or to all active key slots in the case --key-slot option is omitted.
To remove existing token, specify the token ID which should be removed with --token-id option. Always create a header backup before performing this operation! The config command is supported only for LUKS2. The permanent options can be --priority to set priority normal, prefer, ignore for keyslot specified by --key-slot or --label and --subsystem.
Use --offset to specify device offset. Note that the units need to be specified in number of byte sectors. Use --skip to specify the IV offset. If the original device used an offset and but did not use it in IV sector calculations, you have to explicitly use --skip 0 in addition to the offset parameter.
Use --hash to override the default hash function for passphrase hashing otherwise it is detected according to key size. Cryptsetup should recognize all header variants, except legacy cipher chains using LRW encryption mode with 64 bits encryption block namely Blowfish in LRW mode is not recognized, this is limitation of kernel crypto API.
To recognize a VeraCrypt device use the --veracrypt option. The PIM value affects the number of iterations applied during key derivation. To map system device device with boot loader where the whole encrypted system resides use --tcrypt-system option.
You can use partition device as the parameter parameter must be real partition device, not an image in a file , then only this partition is mapped. If you have the whole TCRYPT device as a file image and you want to map multiple partition encrypted with system encryption, please create loopback mapping with partitions first losetup -P , see losetup 8 man page for more info , and use loop partition as the device parameter.
Original TrueCrypt uses reverse notation for some cascades. It means, that code applies block mode even inside cipher chain to prepare full block as input for another cipher. Inner mode applies only to cascades with Blowfish cipher. If the block size of all ciphers is the same, "outer CBC mode" is used and block output of one cipher is directly used as input for another in chain. Note that whitening and IV applies only once in chain here. Cascades in CBC mode are not supported in cryptsetup for activation because of missing kernel support but it is possible to decrypt header and analyze it.
Implementation of cipher chain for LRW and XTS mode is done by stacking separate kernel encryption devices on top of each other. For LRW, the tweaking key is always the same for all ciphers in chain while encryption keys are independent.
For XTS all keys, including tweaking, are independent. There are two sets of encryption keys. One is generated from header salt and password and is used to decrypt on-disk header. The second set contains the real master encryption keys stored in header. There are keys K,,1,,, K,,2,,, K,,3,, used for encryption algorithm corresponding to ciphers in chain if there is only one cipher or chain of two ciphers, remaining keys are omitted.
Also note that for both forms of reading the passphrase from file you can give '-' as file name, which results in the passphrase being read from stdin and the safety-question being skipped. If the passphrase is not supplied via --key-file, the command prompts for it interactively.
Needs kernel 2. After this operation you have to use luksResume to reinstate the encryption key and unblock the device or close to remove the mapped device. Prompts interactively for a passphrase if --key-file is not given. An existing passphrase must be supplied interactively or via --key-file. The new passphrase to be added can be specified interactively or read from the file given as positional argument.
The passphrase to be removed can be specified interactively, as positional argument or via --key-file. Removing the last passphrase makes the LUKS container permanently inaccessible. The passphrase to be changed must be supplied interactively or via --key-file. The new passphrase can be supplied interactively or in a file given as positional argument.
If a key-slot is specified via --key-slot , the passphrase for that key-slot must be given and the new passphrase will overwrite the specified key-slot. If no key- slot is specified and there is still a free key-slot, then the new passphrase will be put into a free key-slot before the key-slot containing the old passphrase is purged. If there is no free key-slot, then the key-slot with the old passphrase is overwritten directly. A remaining passphrase must be supplied, either interactively or via --key-file.
This command can remove the last remaining key-slot, but requires an interactive confirmation when doing so. Removing the last passphrase makes a LUKS container permanently inaccessible.
WARNING: If you read the passphrase from stdin without further argument or with '-' as argument to --key-file , batch-mode -q will be implicitely switched on and no warning will be given when you remove the last remaining passphrase from a LUKS container.
You do not need to provide any password for this operation. Set new UUID if --uuid option is specified. Use option -v to get human-readable feedback. If the --dump-master-key option is used, the LUKS device master key is dumped instead of the keyslot info.
Beware that the master key cannot be changed and can be used to decrypt the data stored in the LUKS container without a passphrase and even without the LUKS header. This means that if the master key is compromised, the whole device has to be erased to prevent further access. Use this option carefully.
In order to dump the master key, a passphrase has to be supplied, either interactively or via --key-file. WARNING: If --dump-master-key is used with --key-file and the argument to --key-file is '-', no validation question will be asked and no warning given.
Note: Using '-' as filename writes the header backup to a file named '-'. Also note that with a header backup you lose the ability to securely wipe the LUKS device by just overwriting the header and key- slots. You either need to securely erase all header backups in addition or overwrite the encrypted data area as well. The second option is less secure, as some sectors can survive, e. Note: Using '-' as filename reads the header backup from a file named '-'.
This command requires that the master key size and data offset of the LUKS header already on the device and of the header backup match. Alternatively, if there is no LUKS header on the device, the backup will also be written to it. Use --offset to specify device offset. Note that the units need to be specified in number of byte sectors. Use --skip to specify the IV offset. If the original device used an offset and but did not use it in IV sector calculations, you have to explicitly use --skip 0 in addition to the offset parameter.
Use --hash to override the default hash function for passphrase hashing otherwise it is detected according to key size. Cryptsetup should recognize all header variants, except legacy cipher chains using LRW encryption mode with 64 bits encryption block namely Blowfish in LRW mode is not recognized, this is limitation of kernel crypto API.
To map system device device with boot loader where the whole encrypted system resides use --tcrypt-system option. You can use partition device as the parameter parameter must be real partition device, not image in file , then only this partition is mapped. If you have whole TCRYPT device as a file image and you want to map multiple partition encrypted with system encryption, please create loopback mapping with partitions first losetup -P , see losetup 8 man page for more info , and use loop partition as the device parameter.
If you use whole base device as parameter, one device for the whole system encryption is mapped. This mode is available only for backward compatibility with older cryptsetup versions which mapped TCRYPT system encryption using whole device.
To use hidden header and map hidden device, if available , use --tcrypt-hidden option. To explicitly use backup secondary header, use --tcrypt-backup option. NOTE: There is no protection for a hidden volume if the outer volume is mounted. The reason is that if there were any protection, it would require some metadata describing what to protect in the outer volume and the hidden volume would become detectable. The keyfile parameter allows combination of file content with the passphrase and can be repeated.
For normal mapping it can cause destruction of hidden volume hidden volume appears as unused space for outer volume so this space can be discarded. Beware that the master key or concatenated master keys if cipher chain is used can be used to decrypt the data stored in the TCRYPT container without a passphrase.
Please note that cryptsetup does not use TrueCrypt code, please report all problems related to this compatibility extension to cryptsetup project. Currently supported only for LUKS device type. This command is useful to fix some known benign LUKS metadata header corruptions.
Only basic corruptions of unused keyslot are fixable. This command will only change the LUKS header, not any key-slot data.
0コメント