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.
