+Dump the header information of a LUKS device.
+
+If the \-\-dump\-master\-key option is used, the LUKS device master key is
+dumped instead of the keyslot info. Together with \-\-master\-key\-file option,
+master key is dumped to a file instead of standard output. Beware that the
+master key cannot be changed without reencryption 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 or reencrypted 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.
+
+To dump unbound key (LUKS2 format only), \-\-unbound parameter, specific \-\-key-slot
+id and proper passphrase has to be supplied, either interactively or via \-\-key\-file.
+Optional \-\-master\-key\-file parameter enables unbound keyslot dump to a file.
+
+\fB<options>\fR can be [\-\-dump\-master\-key, \-\-key\-file,
+\-\-keyfile\-offset, \-\-keyfile\-size, \-\-header, \-\-disable\-locks,
+\-\-master\-key\-file, \-\-type, \-\-unbound, \-\-key-slot].
+
+\fBWARNING:\fR 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.
+.PP
+\fIluksHeaderBackup\fR <device> \-\-header\-backup\-file <file>
+.IP
+Stores a binary backup of the LUKS header and keyslot area.
+.br
+Note: Using '-' as filename writes the header backup to a file named '-'.
+
+\fBWARNING:\fR This backup file and a passphrase valid
+at the time of backup allows decryption of the
+LUKS data area, even if the passphrase was later changed or
+removed from the LUKS device. 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.g. due to defect management.
+.PP
+\fIluksHeaderRestore\fR <device> \-\-header\-backup\-file <file>
+.IP
+Restores a binary backup of the LUKS header and keyslot area
+from the specified file.
+.br
+Note: Using '-' as filename reads the header backup from a file named '-'.
+
+\fBWARNING:\fR Header and keyslots will be replaced, only
+the passphrases from the backup will work afterward.
+
+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.
+.PP
+\fItoken\fR <add|remove|import|export> <device>
+.IP
+Action \fIadd\fR creates new keyring token to enable auto-activation of the device.
+For the auto-activation, the passphrase must be stored in keyring with the specified
+description. Usually, the passphrase should be stored in \fIuser\fR or
+\fIuser-session\fR keyring.
+The \fItoken\fR 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.
+
+\fBWARNING:\fR The action \fItoken remove\fR removes any token type, not just \fIkeyring\fR
+type from token slot specified by \-\-token\-id option.
+
+Action \fIimport\fR can store arbitrary valid token json in LUKS2 header. It may be passed via
+standard input or via file passed in \-\-json\-file option. If you specify \-\-key\-slot then
+successfully imported token is also assigned to the key slot.
+
+Action \fIexport\fR writes requested token json to a file passed with \-\-json\-file or
+to standard output.
+
+\fB<options>\fR can be [\-\-header, \-\-token\-id, \-\-key\-slot, \-\-key\-description,
+\-\-disable\-locks, \-\-disable\-keyring, \-\-json\-file].
+.PP
+\fIconvert\fR <device> \-\-type <format>
+.IP
+Converts the device between LUKS1 and LUKS2 format (if possible).
+The conversion will not be performed if there is an additional LUKS2 feature or LUKS1 has
+unsupported header size.
+
+Conversion (both directions) must be performed on inactive device. There must not be active
+dm-crypt mapping established for LUKS header requested for conversion.
+
+\fB\-\-type\fR option is mandatory with following accepted values: \fIluks1\fR or \fIluks2\fR.
+
+\fBWARNING:\fR The \fIconvert\fR action can destroy the LUKS header in the case of a crash
+during conversion or if a media error occurs.
+Always create a header backup before performing this operation!
+
+\fB<options>\fR can be [\-\-header, \-\-type].
+.PP
+\fIconfig\fR <device>
+.IP
+Set permanent configuration options (store to LUKS header).
+The \fIconfig\fR command is supported only for LUKS2.
+
+The permanent options can be \fI\-\-priority\fR to set priority (normal, prefer, ignore)
+for keyslot (specified by \fI\-\-key\-slot\fR) or \fI\-\-label\fR and \fI\-\-subsystem\fR.
+
+\fB<options>\fR can be [\-\-priority, \-\-label, \-\-subsystem, \-\-key\-slot, \-\-header].
+
+.SH loop-AES EXTENSION
+cryptsetup supports mapping loop-AES encrypted partition using
+a compatibility mode.
+.PP
+\fIopen\fR \-\-type loopaes <device> <name> \-\-key\-file <keyfile>
+.br
+\fIloopaesOpen\fR <device> <name> \-\-key\-file <keyfile> (\fBold syntax\fR)
+.IP
+Opens the loop-AES <device> and sets up a mapping <name>.
+
+If the key file is encrypted with GnuPG, then you have to use
+\-\-key\-file=\- and decrypt it before use, e.g. like this:
+.br
+gpg \-\-decrypt <keyfile> | cryptsetup loopaesOpen \-\-key\-file=\-
+<device> <name>
+
+\fBWARNING:\fR The loop-AES extension cannot use the direct input of key file
+on real terminal because the keys are separated by end-of-line and only part
+of the multi-key file would be read.
+.br
+If you need it in script, just use the pipe redirection:
+.br
+echo $keyfile | cryptsetup loopaesOpen \-\-key\-file=\- <device> <name>
+
+Use \fB\-\-keyfile\-size\fR to specify the proper key length if needed.
+
+Use \fB\-\-offset\fR to specify device offset. Note that the units
+need to be specified in number of 512 byte sectors.
+
+Use \fB\-\-skip\fR 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 \fB\-\-skip 0\fR in addition to the offset
+parameter.
+
+Use \fB\-\-hash\fR to override the default hash function for
+passphrase hashing (otherwise it is detected according to key
+size).
+
+\fB<options>\fR can be [\-\-key\-file, \-\-key\-size, \-\-offset, \-\-skip,
+\-\-hash, \-\-readonly, \-\-allow\-discards, \-\-refresh].
+.PP
+See also section 7 of the FAQ and \fBhttp://loop-aes.sourceforge.net\fR
+for more information regarding loop-AES.
+.SH TCRYPT (TrueCrypt-compatible and VeraCrypt) EXTENSION
+cryptsetup supports mapping of TrueCrypt, tcplay or VeraCrypt
+(with \fB\-\-veracrypt\fR option) encrypted partition
+using a native Linux kernel API.
+Header formatting and TCRYPT header change is not supported, cryptsetup
+never changes TCRYPT header on-device.
+
+TCRYPT extension requires kernel userspace
+crypto API to be available (introduced in Linux kernel 2.6.38).
+If you are configuring kernel yourself, enable
+"User-space interface for symmetric key cipher algorithms" in
+"Cryptographic API" section (CRYPTO_USER_API_SKCIPHER .config option).
+
+Because TCRYPT header is encrypted, you have to always provide valid
+passphrase and keyfiles.
+
+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 \fB\-\-veracrypt\fR option.
+VeraCrypt is just extension of TrueCrypt header with increased
+iteration count so unlocking can take quite a lot of time (in comparison
+with TCRYPT device).
+
+To open a VeraCrypt device with a custom Personal Iteration Multiplier (PIM)
+value, \fBadditionally to \-\-veracrypt \fR use either the
+\fB\-\-veracrypt\-pim=<PIM>\fR option to directly specify the PIM on the command-
+line or use \fB\-\-veracrypt\-query\-pim\fR to be prompted for the PIM.
+
+The PIM value affects the number of iterations applied during key derivation. Please refer to
+\fBhttps://www.veracrypt.fr/en/Personal%20Iterations%20Multiplier%20%28PIM%29.html\fR
+for more detailed information.
+
+\fBNOTE:\fR Activation with \fBtcryptOpen\fR is supported only for cipher chains
+using LRW or XTS encryption modes.
+
+The \fBtcryptDump\fR command should work for all recognized TCRYPT devices
+and doesn't require superuser privilege.
+
+To map system device (device with boot loader where the whole encrypted
+system resides) use \fB\-\-tcrypt\-system\fR 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 (\fBlosetup \-P\fR, see \fPlosetup(8)\fR man page for more info),
+and use loop partition as the device parameter.
+
+If you use the whole base device as a 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 the whole device.
+
+To use hidden header (and map hidden device, if available),
+use \fB\-\-tcrypt\-hidden\fR option.
+
+To explicitly use backup (secondary) header, use \fB\-\-tcrypt\-backup\fR
+option.
+
+\fBNOTE:\fR 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.
+
+.PP
+\fIopen\fR \-\-type tcrypt <device> <name>
+.br
+\fItcryptOpen\fR <device> <name> (\fBold syntax\fR)
+.IP
+Opens the TCRYPT (a TrueCrypt-compatible) <device> and sets up
+a mapping <name>.
+
+\fB<options>\fR can be [\-\-key\-file, \-\-tcrypt\-hidden,
+\-\-tcrypt\-system, \-\-tcrypt\-backup, \-\-readonly, \-\-test\-passphrase,
+\-\-allow-discards, \-\-veracrypt, \-\-veracrypt\-pim, \-\-veracrypt\-query\-pim].
+
+The keyfile parameter allows a combination of file content with the
+passphrase and can be repeated. Note that using keyfiles is compatible
+with TCRYPT and is different from LUKS keyfile logic.
+
+\fBWARNING:\fR Option \fB\-\-allow\-discards\fR cannot be combined with
+option \fB\-\-tcrypt\-hidden\fR. For normal mapping, it can cause
+the \fBdestruction of hidden volume\fR (hidden volume appears as unused space
+for outer volume so this space can be discarded).
+
+.PP
+\fItcryptDump\fR <device>
+.IP
+Dump the header information of a TCRYPT device.
+
+If the \-\-dump\-master\-key option is used, the TCRYPT device master key
+is dumped instead of TCRYPT header info. 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.
+This means that if the master key is compromised, the whole device has
+to be erased to prevent further access. Use this option carefully.
+
+\fB<options>\fR can be [\-\-dump\-master\-key, \-\-key\-file,
+\-\-tcrypt\-hidden, \-\-tcrypt\-system, \-\-tcrypt\-backup].
+
+The keyfile parameter allows a combination of file content with the
+passphrase and can be repeated.
+.PP
+See also \fBhttps://en.wikipedia.org/wiki/TrueCrypt\fR for more information regarding
+TrueCrypt.
+
+Please note that cryptsetup does not use TrueCrypt code, please report
+all problems related to this compatibility extension to the cryptsetup project.
+
+.SH BITLK (Windows BitLocker-compatible) EXTENSION (EXPERIMENTAL)
+cryptsetup supports mapping of BitLocker and BitLocker to Go encrypted partition
+using a native Linux kernel API.
+Header formatting and BITLK header changes are not supported, cryptsetup
+never changes BITLK header on-device.
+
+\fBWARNING:\fR This extension is EXPERIMENTAL.
+
+BITLK extension requires kernel userspace crypto API to be available
+(for details see TCRYPT section).
+
+Cryptsetup should recognize all BITLK header variants, except legacy
+header used in Windows Vista systems and partially decrypted BitLocker devices.
+Activation of legacy devices encrypted in CBC mode requires at least
+Linux kernel version 5.3 and for devices using Elephant diffuser kernel 5.6.
+
+The \fBbitlkDump\fR command should work for all recognized BITLK devices
+and doesn't require superuser privilege.
+
+For unlocking with the \fBopen\fR a password or a recovery passphrase must
+be provided. Other unlocking methods (TPM, SmartCard) are not supported.
+