mirror of
https://gitlab.com/cryptsetup/cryptsetup.git
synced 2025-12-05 16:00:05 +01:00
850 lines
33 KiB
Groff
850 lines
33 KiB
Groff
.TH CRYPTSETUP "8" "May 2012" "cryptsetup" "Maintenance Commands"
|
|
.SH NAME
|
|
cryptsetup - manage plain dm-crypt and LUKS encrypted volumes
|
|
.SH SYNOPSIS
|
|
.B cryptsetup <options> <action> <action args>
|
|
.SH DESCRIPTION
|
|
.PP
|
|
cryptsetup is used to conveniently setup dm-crypt managed
|
|
device-mapper mappings. These include plain dm-crypt volumes and
|
|
LUKS volumes. The difference is that LUKS uses a metadata header
|
|
and can hence offer more features than plain dm-crypt. On the other
|
|
hand, the header is visible and vulnerable to damage.
|
|
.SH PLAIN DM-CRYPT OR LUKS?
|
|
.PP
|
|
Unless you understand the cryptographic background well, use LUKS.
|
|
With plain dm-crypt there are a number of possible user errors
|
|
that massively decrease security. While LUKS cannot fix them
|
|
all, it can lessen the impact for many of them.
|
|
.SH WARNINGS
|
|
.PP
|
|
A lot of good information on the risks of using encrypted storage,
|
|
on handling problems and on security aspects can be found in the
|
|
\fICryptsetup FAQ\fR. Read it. Nonetheless, some risks deserve
|
|
to be mentioned here.
|
|
|
|
\fBBackup:\fR Storage media die. Encryption has no influence on that.
|
|
Backup is mandatory for encrypted data as well, if the data has any
|
|
worth. See the Cryptsetup FAQ for advice on how to do backup of an
|
|
encrypted volume.
|
|
|
|
\fBCharacter encoding:\fR If you enter a
|
|
passphrase with special symbols, the passphrase can change
|
|
depending character encoding. Keyboard settings can also change,
|
|
which can make blind input hard or impossible. For
|
|
example, switching from some ASCII 8-bit variant to UTF-8
|
|
can lead to a different binary encoding and hence different
|
|
passphrase seen by cryptsetup, even if what you see on
|
|
the terminal is exactly the same. It is therefore highly
|
|
recommended to select passphrase characters only from 7-bit
|
|
ASCII, as the encoding for 7-bit ASCII stays the same for
|
|
all ASCII variants and UTF-8.
|
|
|
|
\fBLUKS header:\fR If the header of a LUKS volume gets damaged,
|
|
all data is permanently lost unless you have a header-backup.
|
|
If a key-slot is damaged, it can only be restored from a header-backup
|
|
or if another active key-slot with known passphrase is undamaged.
|
|
Damaging the LUKS header is something people manage to do with
|
|
surprising frequency. This risk is the result of a trade-off
|
|
between security and safety, as LUKS is designed for fast and
|
|
secure wiping by just overwriting header and key-slot area.
|
|
|
|
.SH PLAIN MODE
|
|
Plain dm-crypt encrypts the device sector-by-sector with a
|
|
single, non-salted hash of the passphrase. No checks
|
|
are performed, no metadata is used. There is no formatting operation.
|
|
When the raw device is mapped (created), the usual device operations
|
|
can be used on the mapped device, including filesystem creation.
|
|
Mapped devices usually reside in /dev/mapper/<name>.
|
|
|
|
There are four operations:
|
|
|
|
\fIcreate\fR <name> <device>
|
|
.IP
|
|
Creates a mapping with <name> backed by device <device>.
|
|
|
|
\fB<options>\fR can be [\-\-hash, \-\-cipher, \-\-verify-passphrase,
|
|
\-\-key-file, \-\-keyfile-offset, \-\-key-size, \-\-offset, \-\-skip, \-\-size,
|
|
\-\-readonly, \-\-shared, \-\-allow-discards]
|
|
|
|
Example: 'cryptsetup create e1 /dev/sda10' maps the raw
|
|
encrypted device /dev/sda10 to the mapped (decrypted) device
|
|
/dev/mapper/e1, which can then be mounted, fsck-ed or have a
|
|
filesystem created on it.
|
|
.PP
|
|
\fIremove\fR <name>
|
|
.IP
|
|
Removes the existing mapping <name> and wipes the key from kernel memory.
|
|
.PP
|
|
\fIstatus\fR <name>
|
|
.IP
|
|
Reports the status for the mapping <name>.
|
|
.PP
|
|
\fIresize\fR <name>
|
|
.IP
|
|
Resizes an active mapping <name>.
|
|
|
|
If \-\-size (in sectors) is not specified, the size of the
|
|
underlying block device 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.
|
|
.SH LUKS EXTENSION
|
|
LUKS, the Linux Unified Key Setup, is a standard for disk encryption.
|
|
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'.
|
|
The device that a LUKS container resides on is called a 'LUKS device'.
|
|
For most purposes both terms can be used interchangeably. But
|
|
note that when the LUKS header is at a nonzero offset
|
|
in a device, then the device is not a LUKS device anymore, but
|
|
has a LUKS container stored in it at an offset.
|
|
|
|
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.
|
|
|
|
Each passphrase, also called a
|
|
.B 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.
|
|
|
|
The following are valid LUKS actions:
|
|
|
|
\fIluksFormat\fR <device> [<key file>]
|
|
.IP
|
|
Initializes a LUKS partition and sets the initial passphrase
|
|
(for key-slot 0),
|
|
either via prompting or via <key file>. 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 file you can
|
|
give '-' as file name, which results in the passphrase being read
|
|
from stdin and the safety-question being skipped.
|
|
|
|
You can only call luksFormat on a LUKS device that is not mapped.
|
|
|
|
\fB<options>\fR can be [\-\-cipher, \-\-verify-passphrase, \-\-key-size,
|
|
\-\-key-slot, \-\-key-file (takes precedence over optional second argument),
|
|
\-\-keyfile-offset, \-\-keyfile-size, \-\-use-random | \-\-use-urandom,
|
|
\-\-uuid,
|
|
\-\-master-key-file].
|
|
|
|
\fBWARNING:\fR Doing a luksFormat on an existing LUKS container will
|
|
make all data the old container permanently irretrievable, unless
|
|
you have a header backup.
|
|
.PP
|
|
\fIluksOpen\fR <device> <name>
|
|
.IP
|
|
Opens the LUKS device <device> and sets up a mapping <name> after
|
|
successful verification of the supplied passphrase.
|
|
If the passphrase is not supplied via \-\-key-file, the command
|
|
prompts for it interactively.
|
|
|
|
The <device> parameter can be also specified by LUKS UUID in the
|
|
format UUID=<uuid>, which uses the symlinks in /dev/disk/by-uuid.
|
|
|
|
\fB<options>\fR can be [\-\-key-file, \-\-keyfile-offset,
|
|
\-\-keyfile-size, \-\-readonly, \-\-test-passphrase,
|
|
\-\-allow-discards, \-\-header, \-\-key-slot, \-\-master-key-file].
|
|
.PP
|
|
\fIluksClose\fR <name>
|
|
.IP
|
|
identical to \fIremove\fR.
|
|
.PP
|
|
\fIluksSuspend\fR <name>
|
|
.IP
|
|
Suspends an active device (all IO operations will blocked
|
|
and accesses to the device will wait indefinitely)
|
|
and wipes the encryption
|
|
key from kernel memory. Needs kernel 2.6.19 or later.
|
|
|
|
After this operation you have to use \fIluksResume\fR to reinstate
|
|
the encryption key and unblock the device or \fIluksClose\fR to remove
|
|
the mapped device.
|
|
|
|
\fBWARNING:\fR never suspend the device on which the cryptsetup binary resides.
|
|
|
|
\fB<options>\fR can be [\-\-header].
|
|
.PP
|
|
\fIluksResume\fR <name>
|
|
.IP
|
|
Resumes a suspended device and reinstates the encryption key.
|
|
Prompts interactively for a passphrase if \-\-key-file is not given.
|
|
|
|
\fB<options>\fR can be [\-\-key-file, \-\-keyfile-size, \-\-header]
|
|
.PP
|
|
\fIluksAddKey\fR <device> [<key file with new key>]
|
|
.IP
|
|
adds a new passphrase. 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.
|
|
|
|
\fB<options>\fR can be [\-\-key-file, \-\-keyfile-offset,
|
|
\-\-keyfile-size, \-\-new-keyfile-offset,
|
|
\-\-new-keyfile-size, \-\-key-slot, \-\-master-key-file].
|
|
.PP
|
|
\fIluksRemoveKey\fR <device> [<key file with passphrase to be removed>]
|
|
.IP
|
|
Removes the supplied passphrase from the LUKS device. The
|
|
passphrase to be removed can be specified interactively,
|
|
as positional argument or via \-\-key-file.
|
|
|
|
\fB<options>\fR can be [\-\-key-file, \-\-keyfile-offset,
|
|
\-\-keyfile-size]
|
|
|
|
\fBWARNING:\fR 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. Removing
|
|
the last passphrase makes the LUKS container permanently
|
|
inaccessible.
|
|
.PP
|
|
\fIluksChangeKey\fR <device> [<new key file>]
|
|
.IP
|
|
Changes an existing passphrase. 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.
|
|
|
|
\fBWARNING:\fR If a key-slot is overwritten, a media failure
|
|
during this operation can cause the overwrite to fail after
|
|
the old passphrase has been wiped and make the LUKS container
|
|
inaccessible.
|
|
|
|
\fB<options>\fR can be [\-\-key-file, \-\-keyfile-offset,
|
|
\-\-keyfile-size, \-\-new-keyfile-offset,
|
|
\-\-new-keyfile-size, \-\-key-slot].
|
|
.PP
|
|
\fIluksKillSlot\fR <device> <key slot number>
|
|
.IP
|
|
Wipe the key-slot number <key slot> from the LUKS device. 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.
|
|
|
|
\fB<options>\fR can be [\-\-key-file, \-\-keyfile-offset, \-\-keyfile-size].
|
|
|
|
\fBWARNING:\fR 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. Removing
|
|
the last passphrase makes the LUKS container permanently
|
|
inaccessible.
|
|
.PP
|
|
\fIluksUUID\fR <device>
|
|
.IP
|
|
Print the UUID of a LUKS device.
|
|
.br
|
|
Set new UUID if \fI\-\-uuid\fR option is specified.
|
|
.PP
|
|
\fIisLuks\fR <device>
|
|
.IP
|
|
Returns true, if <device> is a LUKS device, false otherwise.
|
|
Use option \-v to get human-readable feedback. 'Command successful.'
|
|
means the device is a LUKS device.
|
|
.PP
|
|
\fIluksDump\fR <device>
|
|
.IP
|
|
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. 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.
|
|
|
|
\fB<options>\fR can be [\-\-dump-master-key, \-\-key-file,
|
|
\-\-keyfile-offset, \-\-keyfile-size].
|
|
|
|
\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 afterwards.
|
|
|
|
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
|
|
\fIrepair\fR <device>
|
|
.IP
|
|
Tries to repair the LUKS device metadata if possible.
|
|
|
|
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.
|
|
|
|
\fBWARNING:\fR Always create a binary backup of the original
|
|
header before calling this command.
|
|
.SH loop-AES EXTENSION
|
|
cryptsetup supports mapping loop-AES encrypted partition using
|
|
a compatibility mode.
|
|
.PP
|
|
\fIloopaesOpen\fR <device> <name> \-\-key-file <keyfile>
|
|
.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>
|
|
|
|
Use \fB\-\-key-file-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].
|
|
.PP
|
|
\fIloopaesClose\fR <name>
|
|
.IP
|
|
Identical to \fIremove\fR.
|
|
.PP
|
|
See also section 7 of the FAQ and \fBhttp://loop-aes.sourceforge.net\fR
|
|
for more information regarding loop-AES.
|
|
.SH MISCELLANEOUS
|
|
.PP
|
|
\fIbenchmark\fR <options>
|
|
.IP
|
|
Benchmarks ciphers. Without parameters it tries to measure few common
|
|
configurations.
|
|
|
|
To benchmark other ciphers or modes, you need to specify \fB\-\-cipher\fR
|
|
and \fB\-\-key-size\fR options.
|
|
|
|
\fBNOTE:\fR This benchmark is using memory only and is only informative.
|
|
You cannot directly predict real storage encryption speed from it.
|
|
|
|
This benchmark requires kernel userspace crypto API interface to be available
|
|
(kernel af_alg and af_skcipher modules, introduced in Linux kernel 2.6.38).
|
|
|
|
\fB<options>\fR can be [\-\-cipher, \-\-key-size].
|
|
.SH OPTIONS
|
|
.TP
|
|
.B "\-\-verbose, \-v"
|
|
Print more information on command execution.
|
|
.TP
|
|
.B "\-\-debug"
|
|
Run in debug mode with full diagnostic logs. Debug output
|
|
lines are always prefixed by '#'.
|
|
.TP
|
|
.B "\-\-hash, \-h \fI<hash-spec>\fR"
|
|
Specifies the passphrase hash for \fIcreate\fR and \fIloopaesOpen\fR.
|
|
|
|
Specifies the hash used in the LUKS key setup scheme and volume key digest
|
|
for \fIluksFormat\fR.
|
|
|
|
The specified hash name is passed to the compiled-in crypto backend.
|
|
Different backends may support different hashes.
|
|
For \fIluksFormat\fR, the hash
|
|
algorithm must provide at least 160 bits of output, which
|
|
excludes, e.g., MD5. Do not use a non-crypto hash like
|
|
\fB"crc32"\fR as this breaks security.
|
|
|
|
Values compatible with old version of cryptsetup are
|
|
\fB"ripemd160"\fR for \fIcreate\fR and
|
|
\fB"sha1"\fR for \fIluksFormat\fR.
|
|
|
|
Use \fIcryptsetup \-\-help\fR to show the defaults.
|
|
.TP
|
|
.B "\-\-cipher, \-c \fI<cipher-spec>\fR"
|
|
Set the cipher specification string.
|
|
|
|
\fIcryptsetup \-\-help\fR shows the compiled-in defaults.
|
|
The current default in the distributed sources is
|
|
"aes-cbc-essiv:sha256" for both plain dm-crypt and LUKS.
|
|
|
|
For XTS mode (a possible future default), use "aes-xts-plain"
|
|
or better "aes-xts-plain64"
|
|
as cipher specification and optionally set a key size of
|
|
512 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.6.24 or later and plain64 requires
|
|
kernel 2.6.33 or later. More information can be found in the FAQ.
|
|
.TP
|
|
.B "\-\-verify-passphrase, \-y"
|
|
When interactively asking for a passphrase, ask for it twice
|
|
and complain if both inputs do not match. Advised when creating
|
|
a regular mapping for the first time, or when running
|
|
\fIluksFormat\fR. Ignores on input from file or stdin.
|
|
.TP
|
|
.B "\-\-key-file, \-d \fIname\fR"
|
|
Read the passphrase from file.
|
|
|
|
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 \fIluksFormat\fR 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 \fIluksAddKey\fR.
|
|
|
|
See section \fBNOTES ON PASSPHRASE PROCESSING\fR for more information.
|
|
.TP
|
|
.B "\-\-keyfile-offset \fIvalue\fR"
|
|
Skip \fIvalue\fR bytes at the beginning of the key file.
|
|
Works with all commands that accepts key files.
|
|
.TP
|
|
.B "\-\-keyfile-size, \-l \fIvalue\fR"
|
|
Read a maximum of \fIvalue\fR bytes from the key file.
|
|
Default is to read the whole file up to the compiled-in
|
|
maximum that can be queried with \-\-help. Supplying more
|
|
data than the compiled-in maximum aborts the operation.
|
|
|
|
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.
|
|
.TP
|
|
.B "\-\-new-keyfile-offset \fIvalue\fR"
|
|
Skip \fIvalue\fR bytes at the start when
|
|
adding a new passphrase from key file with
|
|
\fIluksAddKey\fR.
|
|
.TP
|
|
.B "\-\-new-keyfile-size \fIvalue\fR"
|
|
Read a maximum of \fIvalue\fR bytes when adding
|
|
a new passphrase from key file with \fIluksAddKey\fR.
|
|
Default is to read the whole file up to the compiled-in
|
|
maximum length that can be queried with \-\-help.
|
|
Supplying more than the compiled in maximum aborts the
|
|
operation.
|
|
When \-\-new-keyfile-offset is also given, reading starts
|
|
after the offset.
|
|
.TP
|
|
.B "\-\-master-key-file"
|
|
Use a master key stored in a file.
|
|
|
|
For \fIluksFormat\fR this
|
|
allows creating a LUKS header with this specific
|
|
master key. 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.
|
|
|
|
For \fIluksAddKey\fR this allows adding a new passphrase
|
|
without having to know an exiting one.
|
|
|
|
For \fIluksOpen\fR this allows to open the LUKS device
|
|
without giving a passphrase.
|
|
.TP
|
|
.B "\-\-dump-master-key"
|
|
For \fIluksDump\fR this option includes the master key in the displayed
|
|
information. Use with care, as the master key can be used to
|
|
bypass the passphrases, see also option \-\-master-key-file.
|
|
.TP
|
|
.B "\-\-use-random"
|
|
.TP
|
|
.B "\-\-use-urandom"
|
|
For \fIluksFormat\fR these options define which kernel random number
|
|
generator will be used to create the master key (which is a
|
|
long-term key).
|
|
|
|
See \fBNOTES ON RANDOM NUMBER GENERATORS\fR for more
|
|
information. Use \fIcryptsetup \-\-help\fR
|
|
to show the compiled-in default random number generator.
|
|
|
|
\fBWARNING:\fR In a low-entropy situation (e.g. in an
|
|
embedded system), both selections are problematic.
|
|
Using /dev/urandom can lead to weak keys.
|
|
Using /dev/random can block a long time, potentially
|
|
forever, if not enough entropy can be harvested by
|
|
the kernel.
|
|
.TP
|
|
.B "\-\-key-slot, \-S <0-7>"
|
|
For LUKS operations that add key material, this options allows you
|
|
to specify which key slot is selected for the new key.
|
|
This option can be used for \fIluksFormat\fR,
|
|
and \fIluksAddKey\fR.
|
|
.br
|
|
In addition, for \fIluksOpen\fR, this option selects a
|
|
specific key-slot to compare the passphrase against.
|
|
If the given passphrase would only match a different key-slot,
|
|
the operation fails.
|
|
.TP
|
|
.B "\-\-key-size, \-s <bits>"
|
|
Sets key size in bits. The argument has to be a multiple of
|
|
8. The possible key-sizes are limited by the cipher and
|
|
mode used.
|
|
|
|
See /proc/crypto for more information. Note that key-size
|
|
in /proc/crypto is stated in bytes.
|
|
|
|
This option can be used for \fIcreate\fR or \fIluksFormat\fR. All
|
|
other LUKS actions will use the key-size specified in the LUKS header.
|
|
Use \fIcryptsetup \-\-help\fR to show the compiled-in defaults.
|
|
.TP
|
|
.B "\-\-size, \-b <number of 512 byte sectors>"
|
|
Force the size of the underlying device in sectors of 512 bytes.
|
|
This option is only relevant for the \fIcreate\fR and \fIresize\fR
|
|
actions.
|
|
.TP
|
|
.B "\-\-offset, \-o <number of 512 byte sectors>"
|
|
Start offset in the backend device in 512-byte sectors.
|
|
This option is only relevant for the \fIcreate\fR and \fIloopaesOpen\fR
|
|
actions.
|
|
.TP
|
|
.B "\-\-skip, \-p <number of 512 byte sectors>"
|
|
How many sectors of the encrypted data to skip at the beginning.
|
|
This option is only relevant for \fIcreate\fR and \fIloopaesOpen\fR action.
|
|
|
|
This is different from the \-\-offset options with respect to
|
|
the sector numbers used in IV calculation.
|
|
Using \-\-offset will shift the IV calculation by the same negative amount.
|
|
Hence, if \-\-offset \fIn\fR, sector \fIn\fR will get a sector
|
|
number of \fI0\fR for the IV calculation.
|
|
Using \-\-skip causes sector \fIn\fR to also be the first sector
|
|
of the mapped device, but with its number for IV generation is \fIn\fR.
|
|
.TP
|
|
.B "\-\-readonly, \-r"
|
|
set up a read-only mapping.
|
|
.TP
|
|
.B "\-\-shared"
|
|
Creates an additional mapping for one common
|
|
ciphertext device. Arbitrary mappings are supported.
|
|
This option is only relevant for the
|
|
\fIcreate\fR action. Use \-\-offset, \-\-size and \-\-skip to
|
|
specify the mapped area.
|
|
.TP
|
|
.B "\-\-iter-time, \-i <number of milliseconds>"
|
|
The number of milliseconds to spend with PBKDF2 passphrase processing.
|
|
This option is only relevant for LUKS operations that set or change
|
|
passphrases, such as \fIluksFormat\fR or \fIluksAddKey\fR.
|
|
Specifying 0 as parameter selects the compiled-in default.
|
|
.TP
|
|
.B "\-\-batch-mode, \-q"
|
|
Suppresses all confirmation questions. Use with care!
|
|
|
|
If the \-y option is not specified, this option also switches off
|
|
the passphrase verification for \fIluksFormat\fR.
|
|
.TP
|
|
.B "\-\-timeout, \-t <number of seconds>"
|
|
The number of seconds to wait before timeout on passphrase input
|
|
via terminal. It is relevant every time a passphrase is asked,
|
|
for example for \fIcreate\fR, \fIluksOpen\fR, \fIluksFormat\fR
|
|
or \fIluksAddKey\fR. It has no effect if used in conjunction
|
|
with \-\-key-file.
|
|
.br
|
|
This option is useful when the system
|
|
should not stall if the user does not input a passphrase,
|
|
e.g. during boot. The default is a value of 0 seconds,
|
|
which means to wait forever.
|
|
.TP
|
|
.B "\-\-tries, \-T"
|
|
How often the input of the passphrase shall be retried.
|
|
This option is relevant
|
|
every time a passphrase is asked, for example for
|
|
\fIcreate\fR, \fIluksOpen\fR, \fIluksFormat\fR
|
|
or \fIluksAddKey\fR. The default is 3 tries.
|
|
.TP
|
|
.B "\-\-align-payload <number of 512 byte sectors>"
|
|
Align payload at a boundary of \fIvalue\fR 512-byte sectors.
|
|
This option is relevant for \fIluksFormat\fR.
|
|
|
|
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.e. 2048 512-byte sectors).
|
|
|
|
For a detached LUKS header this option specifies the offset on the
|
|
data device. See also the \-\-header option.
|
|
.TP
|
|
.B "\-\-uuid=\fIUUID\fR"
|
|
Use the provided \fIUUID\fR for the \fIluksFormat\fR command
|
|
instead of generating new one. Changes the existing UUID when
|
|
used with the \fIluksUUID\fR command.
|
|
|
|
The UUID must be provided in the standard UUID format,
|
|
e.g. 12345678-1234-1234-1234-123456789abc.
|
|
.TP
|
|
.B "\-\-allow-discards\fR"
|
|
Allow the use of discard (TRIM) requests for device.
|
|
This option is only relevant for \fIcreate\fR, \fIluksOpen\fR
|
|
and \fIloopaesOpen\fR.
|
|
|
|
\fBWARNING:\fR 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. may be extractable from
|
|
the physical device if the discarded blocks can be located
|
|
later. If in doubt, do no use it.
|
|
|
|
A kernel version of 3.1 or later is needed. For earlier kernels
|
|
this option is ignored.
|
|
.TP
|
|
.B "\-\-test-passphrase\fR"
|
|
Do not activate device, just verify passphrase.
|
|
This option is only relevant for \fIluksOpen\fR.
|
|
.TP
|
|
.B "\-\-header\fR <device or file storing the LUKS header>"
|
|
Use a detached (separated) metadata device or file where the
|
|
LUKS header is stored. This options allows to store ciphertext
|
|
and LUKS header on different devices.
|
|
|
|
This option is only relevant for LUKS devices and can be
|
|
used with the \fIluksFormat\fR, \fIluksOpen\fR, \fIluksSuspend\fR,
|
|
\fIluksResume\fR, \fIstatus\fR and \fIresize\fR commands.
|
|
|
|
For \fIluksFormat\fR 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.g. \fIluksAddKey\fR),
|
|
specify the device or file with the LUKS header directly as the
|
|
LUKS device.
|
|
|
|
If used with \fIluksFormat\fR, the \-\-align-payload option is taken
|
|
as absolute sector alignment on ciphertext device and can be zero.
|
|
|
|
\fBWARNING:\fR There is no check whether the ciphertext device specified
|
|
actually belongs to the header given. In fact you can specify an
|
|
arbitrary device as the ciphertext device for \fIluksOpen\fR
|
|
with the \-\-header option. Use with care.
|
|
.TP
|
|
.B "\-\-version"
|
|
Show the program version.
|
|
.SH RETURN CODES
|
|
Cryptsetup returns 0 on success and a non-zero value on error.
|
|
|
|
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.
|
|
.SH NOTES ON PASSPHRASE PROCESSING FOR PLAIN MODE
|
|
Note that no iterated hashing or salting is done in plain mode.
|
|
If hashing is done, it is a single direct hash. This means that
|
|
low-entropy passphrases are easy to attack in plain mode.
|
|
|
|
\fBFrom a terminal\fR: The passphrase is read until the
|
|
first newline, i.e. '\\n'.
|
|
The input without the newline character is processed with
|
|
the default hash or the hash specified with \-\-hash.
|
|
The has result will be truncated to the key size
|
|
of the used cipher, or the size specified with \-s.
|
|
|
|
\fBFrom stdin\fR: 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.
|
|
The has result will be truncated to the key size
|
|
of the used cipher, or the size specified with \-s.
|
|
|
|
Note that if \-\-key-file=- is used for reading the key
|
|
from stdin, trailing newlines are not stripped from the input.
|
|
|
|
If "plain" is used as argument to \-\-hash, the input
|
|
data will not be hashed. Instead, it will be zero padded (if
|
|
shorter than the key size) or truncated (if longer than the
|
|
key size) and used directly as the binary key. This is useful for
|
|
directly specifying a binary key.
|
|
No warning will be given if the amount of data read from stdin is
|
|
less than the key size.
|
|
|
|
\fBFrom a key file\fR: It will be truncated to the
|
|
key size of the used cipher or the size given by \-s
|
|
and directly used as binary key.
|
|
if the key file is shorter than the key, cryptsetup
|
|
will quit with an error.
|
|
|
|
.SH NOTES ON PASSPHRASE PROCESSING FOR LUKS
|
|
LUKS uses PBKDF2 to protect against dictionary attacks
|
|
and to give some protection to low-entropy passphrases
|
|
(see RFC 2898 and the cryptsetup FAQ).
|
|
|
|
\fBFrom a terminal\fR: The passphrase is read until the
|
|
first newline and then processed by PBKDF2 without
|
|
the newline character.
|
|
|
|
\fBFrom stdin\fR:
|
|
LUKS will read passphrases from stdin up to the
|
|
first newline character or the compiled-in
|
|
maximum key file length. If \-\-keyfile-size is
|
|
given, it is ignored.
|
|
|
|
\fBFrom key file\fR:
|
|
The complete keyfile is read up to the compiled-in
|
|
maximum size. Newline characters do not terminate the
|
|
input. The \-\-keyfile-size option can be used to limit
|
|
what is read.
|
|
|
|
\fBPassphrase processing\fR:
|
|
Whenever a passphrase is added to a LUKS header (luksAddKey, luksFormat),
|
|
the user may specify how much the time the passphrase processing
|
|
should consume. The time is used to determine the iteration count
|
|
for PBKDF2 and higher times will offer better protection for
|
|
low-entropy passphrases, but luksOpen will take longer to
|
|
complete. For passphrases that have entropy higher than the
|
|
used key length, higher iteration times will not increase security.
|
|
|
|
The default setting of one second is sufficient for most
|
|
practical cases. The only exception is a low-entropy
|
|
passphrase used on a slow device.
|
|
.SH INCOHERENT BEHAVIOR FOR INVALID PASSPHRASES/KEYS
|
|
LUKS checks for a valid passphrase when an encrypted partition
|
|
is unlocked. The behavior of plain dm-crypt is different.
|
|
It will always decrypt with the passphrase given. If the
|
|
given passphrase is wrong, the device mapped by plain
|
|
dm-crypt will essentially still contain encrypted data and
|
|
will be unreadable.
|
|
.SH NOTES ON SUPPORTED CIPHERS, MODES, HASHES AND KEY SIZES
|
|
The available combinations of ciphers, modes, hashes and key sizes
|
|
depend on kernel support. See /proc/crypto for a list of available
|
|
options. You might need to load additional kernel crypto modules
|
|
in order to get more options.
|
|
|
|
For the \-\-hash option, if the crypto backend is libgcrypt,
|
|
then all algorithms supported by the gcrypt library are available.
|
|
For other crypto backends some algorithms may be missing.
|
|
.SH NOTES ON PASSPHRASES
|
|
Mathematics can't be bribed. Make sure you keep your passphrases safe.
|
|
There are a few nice tricks for constructing a fallback, when suddenly
|
|
out of the blue, your brain refuses to cooperate.
|
|
These fallbacks need LUKS, as it's only possible with LUKS
|
|
to have multiple passphrases. Still, if your attacker model does
|
|
not prevent it, storing your passphrase in a sealed envelope somewhere
|
|
may be a good idea as well.
|
|
.SH NOTES ON RANDOM NUMBER GENERATORS
|
|
Random Number Generators (RNG) used in cryptsetup are always the
|
|
kernel RNGs without any modifications or additions to data stream
|
|
produced.
|
|
|
|
There are two types of randomness cryptsetup/LUKS needs. One type
|
|
(which always uses /dev/urandom) is used for salts, the AF splitter
|
|
and for wiping deleted keyslots.
|
|
|
|
The second type is used for the volume (master) key. You can switch
|
|
between using /dev/random and /dev/urandom here, see
|
|
\fP\-\-use-random\fR and \fP\-\-use-urandom\fR
|
|
options. Using /dev/random on a system without enough entropy sources
|
|
can cause \fPluksFormat\fR to block until the requested amount of
|
|
random data is gathered. In a low-entropy situation (embedded system),
|
|
this can take a very long time and potentially forever. At the same
|
|
time, using /dev/urandom in a low-entropy situation will
|
|
produce low-quality keys. This is a serious problem, but solving
|
|
it is out of scope for a mere man-page.
|
|
See \fPurandom(4)\fR for more information.
|
|
.SH NOTES ON LOOPBACK DEVICE USE
|
|
Cryptsetup is usually used directly on a block device (disk
|
|
partition or LVM volume). However, if the device argument is a
|
|
file, cryptsetup tries to allocate a loopback device
|
|
and map it into this file. This mode requires Linux kernel 2.6.25
|
|
or more recent which supports the loop autoclear flag (loop device is
|
|
cleared on last close automatically). Of course, you can
|
|
always map a file to a loop-device manually. See the
|
|
cryptsetup FAQ for an example.
|
|
|
|
When device mapping is active, you can see the loop backing file in
|
|
the status command output. Also see losetup(8).
|
|
.SH DEPRECATED ACTIONS
|
|
.PP
|
|
The \fIreload\fR action is no longer supported.
|
|
Please use \fIdmsetup(8)\fR if you need to
|
|
directly manipulate with the device mapping table.
|
|
.PP
|
|
The \fIluksDelKey\fR was replaced with \fIluksKillSlot\fR.
|
|
.PP
|
|
.SH REPORTING BUGS
|
|
Report bugs, including ones in the documentation, on
|
|
the cryptsetup mailing list at <dm-crypt@saout.de>
|
|
or in the 'Issues' section on LUKS website.
|
|
Please attach the output of the failed command with the
|
|
\-\-debug option added.
|
|
.SH AUTHORS
|
|
cryptsetup originally written by Christophe Saout <christophe@saout.de>
|
|
.br
|
|
The LUKS extensions and original man page were written by
|
|
Clemens Fruhwirth <clemens@endorphin.org>.
|
|
.br
|
|
Man page extensions by Milan Broz <gmazyland@gmail.com>.
|
|
.br
|
|
Man page rewrite and extension by Arno Wagner <arno@wagner.name>.
|
|
.SH COPYRIGHT
|
|
Copyright \(co 2004 Christophe Saout
|
|
.br
|
|
Copyright \(co 2004-2006 Clemens Fruhwirth
|
|
.br
|
|
Copyright \(co 2009-2012 Red Hat, Inc.
|
|
.br
|
|
Copyright \(co 2012 Arno Wagner
|
|
|
|
This is free software; see the source for copying conditions. There is NO
|
|
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
|
|
.SH SEE ALSO
|
|
The LUKS website at \fBhttp://code.google.com/p/cryptsetup/\fR
|
|
|
|
The cryptsetup FAQ, contained in the distribution package and
|
|
online at
|
|
\fBhttp://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions\fR
|
|
|
|
The cryptsetup mailing list and list archive, see FAQ entry 1.6.
|
|
|
|
The LUKS on-disk format specification available at
|
|
\fBhttp://code.google.com/p/cryptsetup/wiki/Specification\fR
|