RIPEMD160 is not even allowed any more as an option when creating an
encrypted file container using VeraCrypt. when encryption the system
partition/drive, it is below SHA256 in the list of options.
the order is like that since VeraCrypt version 1.0f (2014-12-30,
see https://www.veracrypt.fr/en/Release%20Notes.html).
If last write in move area failed, the keyslot is in fact destroyed.
We need to at least ensure that the whole area is there
(so write fails only for hard errors).
- do not run general LUKS2 format validation from inside the specific one
- validate luks2 json object only
- temporary move digests count restrictions, going to be fixed in next
commit
This patch fixes several problems:
- pbkdf benchmark should be run with keyslot encryption key length
instead volume key length
- run LUKS2 keyslot validation on final keyslot json object instead
temporary stub created in keyslot_alloc
- replace whole json kdf object during keyslot update. We left behind
old parameters from old pbkdf during transition to differnt type
A keyslot not bound to any segment can store any key for any purpose.
To easily check slot status, new enum value is introduced.
This status is valid only for LUKS2, so the functions are backward compatible
with LUKS1.
We can't wipe (overwrite with random noise) wrapped key in
kernel. Such keys are usually structured and not only random
bytes.
Also it doesn't make sense to wipe these keys. They are supposed
to be protected (encrypted) by keys sealed in hardware.
TODO: tests: 1) with header, 2) without header (dm-crypt only),
3) arch with working paes cipher (at least).
Some ciphers and key sizes created on-disk metadata that cannot be used.
Use the same test for length-preserving cipher as LUKS1.
Also check if key for integrity algorithm is not too small.
Fixes#373.
The kernel 4.17 will include a new dm-verity flag that
instructs kernel to verify data blocks only once.
This patch adds support for it to libcryptsetup and veritysetup.
This flag can be dangerous; if you can control underlying device
(you can change its content after it was verified) it will no longer
prevent reading tampered data and also it does not prevent to silent
data corrruptions that appears after the block was once read.
