Kernel could reject HMAC without a key during format, we must set a key here as well.
Because there is no data area (device size is 8 sectors), it is actually never used,
so we can use zeroed key here.
The real HMAC key is used later during device activation with the real size.
- add --pbkdf* option descriptions
- few clarifications wrt LUKS2 format
- alter note about limited support for LUKS2. It's 1:1
with LUKS1 format currently, but tokens are not yet
transfered to new LUKS2 header for reencrypted device.
- few minor corrections
The code must not set global table with KDF variants but
it shuld calculate local iterations count.
Also PIM is not used for old Trucrypt modes, do not use it there.
Also fix leak of PIM iteration count to debug log.
Fixes issue #366 and issue #367.
Recent kernel changes disallows to use keyed-hash algorithms
without settting the key.
Unfortunately, dm-integrity fails too late (during IO, not on init).
For now fix just the test.
- adapt tests to new features (luks2 keyslot change, pbkdf params)
- add tests for fixes (max keyslot)
- speed up tests significantly by add minimal forced values everywhere.
The change in keyfile processing caused that special loopAES
keyfiles are no longer read from stdin if key-file argument is "-".
Fix it by using /dev/stdin in cryptsetup if "-" is detected.
(The libcryptsetup API no longer parses spacial meaning of "-" internally).
Fixes#364.
This fixes crypt_keyslot_add_by_key where we were unable to store
keyslot (unbound to segment) with different key_size.
The code used (new) volume key size implicitly which could be wrong
if new size was not compatible with cipher parameter for keyslot area.
Add yet another flawed dm-crypt test (keyring)
and test crypt_get_volume_key_size works
as expected after LUKS2 crypt_format (before
adding first keyslot).
For now, crypto API quietly used cipher witout IV if a cipher
algorithm wihtou IV specificaton was used (e.g. aes-xts).
This caused fail later during activation.
This patch allows only two specific backed use without specified IV
(ECB mode and NULL cipher).
Also check cipher string early during parsing of CLI options.
cryptsetup now requires dm-crypt v1.18.1 or higher
to use kernel keyring service for passing VKs.
Also, relevant API functions fail if CRYPT_ACTIVATE_KEYRING_KEY
is set, but library is not allowed to use kernel keyring for
VK.
When loading first dm-crypt table (or action that triggers dm-crypt
module load) we do not know dm-crypt version yet. Let's assume all
kernels before 4.15.0 are flawed and reject VK load via kernel keyring
service.
When dm-crypt is already in kernel, check for correct target version
instead (v1.18.1 or later).
Upstream dm-crypt v1.15.0 through v1.18.0 contains
serious bug in kernel key processing that may cause
data corruption for ciphers using essiv, tcw and lmk IVs.
Patch adds patch number processing to DM version checks.
The keyfile interface was designed, well, for keyfiles.
Unfortunately, a keyfile can be placed on a device and the size_t offset
can overflow.
We have to introduce new set of fucntions that allows 64bit offsets even on 32bit systems:
- crypt_resume_by_keyfile_device_offset
- crypt_keyslot_add_by_keyfile_device_offset
- crypt_activate_by_keyfile_device_offset
- crypt_keyfile_device_read
The new functions have added _device_ in name.
Old functions are just internall wrappers around these.
Also cryptsetup --keyfile-offset and --new-keyfile-offset must now
process 64bit offsets.
For more info see issue 359.
