For compatibility reasons, cryptsetup uses key size in BITS
while integritysetup in BYTES.
The help is confusing here, this patch fixes it.
Thanks Daniel Tang for notification.
This patch extends available options for LUKS2 reencryption
initialization.
When no specific keyslot is selected by --key-slot option, all active
keyslots needs to be refreshed. With current patch user does not
have to provide passphrase via interactive prompt when token is
available and can unlock assigned keyslot. Only keyslots not assigned
to tokens (and unlocked by tokens) must be provided with passphrase.
Furthermore user may directly narrow down selection of keyslots
suitable for reencryption by specifying either --token-id, --token-type
or --token-only option. In that case only keyslots associated to the
specific token (--token-id) or specific type (--token-type) or any token
specified in LUKS2 metadata (--token-only) will be used for
reencryption and refreshed with new volume key. All other keyslots will
not be refreshed and will be erased after reencryption is finished. The token
association will be carried over to refreshed keyslots.
The third new method available in this patch is support for reencryption
by passing volume keys directly. The LUKS2 device may be reencrypted
by passing volume keys by --volume-key-file, --new-volume-key-file,
--volume-key-keyring or --new-volume-key-keyring options. With this
options user may reencrypt device with no active keyslots. If there's
any active keyslot and volume keys are passed directly user may enforce
volume key based reencryption by passing --force-no-keyslots option.
If --force-no-keyslots option is passed all active keyslots will be
erased after reencryption operation is finished and the device may be
unlocked only by passing new volume key directly.
Fixes: #774, #780.
TrueCrypt/VeraCrypt supports full system encryption (only a partition
table is not encrypted) or system partition encryption
(only a system partition is encrypted).
The metadata header then contains the offset and size of the encrypted area.
Cryptsetup needs to know the specific partition offset to calculate encryption parameters.
To properly map a partition, you must specify a real partition device so cryptsetup can calculate this offset.
As user can specify various combination, we need to determine the proper
IV and data offsets.
The logic for CRYPT_TCRYPT_SYSTEM_HEADER flag should be (in this order):
- if data device is a real partition, calculate offset from it.
- if --header is a real partition , calculate offset from it.
- if device is a real disk, try to search for partition using decrypted offset and size
(works only for system partition-only encryption).
- if data and metadata (header) device is the same, map whole encrypted area
(this is the ost confusing for user)
- if data and metadata (header) divice differs, expect data image contains
only partition (setting offset to 0, but using IV offset from header).
There are still situation that can end with wrong mapping, but user now has the option
to setup it properly.
Also this patch fixes use of stored encryption size in header,
so we do not map larger area.
Fixes:#889
We can not link internal VK kernel key in custom user
keyring. There are two reasons for it:
The internal VK kernel key description can not be
acquired via API and it may change over time
(LUKS2 reencryption).
With recent SED OPAL support volume key becomes a 'blob'
containing up to two keys (dm-crypt key for SWE and key
for unlocking SED OPAL locking range). The internal
kernel key contains only dm-crypt (if required) but
custom user keyring needs to be provided with whole
volume key (blob).
Added user specified key description for the linked key
in custom user keyring. The linked key can be reached by
the specified description after successful activation (resume).
Add --volume-key-keyring option, which takes a name of a key in keyring,
which will be used as a VK during device activation. The key can be
specified in keyctl-compatible syntax "%<key_type>:<key_name>".
If a user explicitly specifies PBKDF parameters (like iterations,
used memory of threads), do not limit them, even if it can cause
resource exhaustion.
The only limits are hard limits per the PBKDF algorithm.
The force options were mostly used for decreasing parameters,
but it should work even opposite - despite the fact it can mean
shooting yourself in the foot (OOM).
Fixes: #812
In practice luksAddKey action does two operations. It unlocks existing
device volume key and stores unlocked volume key in a new keyslot.
Previously the options were limited to key files and passphrases.
With this patch user may combine freely following options:
To unlock keyslot with volume key user may:
- provide existing passphrase via interactive prompt (default method)
- use --key-file option to provide file with a valid passphrase to existing keyslot
- provide volume key directly via --volume-key-file
- unlock keyslot via all available LUKS2 tokens by --token-only
- unlock keyslot via specific token with --token-id
- unlock keyslot via specific token type by --token-type
To provide the passphrase for a new keyslot user may:
- provide existing passphrase via interactive prompt (default method)
- use --new-keyfile parameter or positional parameter to read the
passphrase from file.
- use --new-token-id to select specific LUKS2 token to get passphrase
for new keyslot. New keyslot is assigned to selected token id if
operation is succesfull.
Fixes: #725.
