On Sat, 20 Jul 2019 at 06:01:35 -0300, Guilhem Moulin wrote: > LUKS2_get_volume_key_size() fails because the key size is specified in > the ‘keyslots’ object of LUKSv2's JSON header [0], and that object is > the empty array at that point.
Forgot to add another data point which supports my claim: with a LUKSv2 device with two active key slots (#0 unlocked by passphrase “test” and #1 unlocked by a random passphrase), LUKS2_get_volume_key_size() succeeds and so does crypt_keyslot_add_by_volume_key(). $ cryptsetup luksFormat --pbkdf-force-iterations 4 --pbkdf-memory 32 \ --type luks2 -q /tmp/disk.img <<<test $ cryptsetup luksAddKey --pbkdf-force-iterations 4 --pbkdf-memory 32 \ --new-keyfile-size 32 /tmp/disk.img /dev/urandom <<<test $ ./928893 /tmp/disk.img "test" "test2" Works fine. The first (index #0) key slot is updated with the new passphrase, while the other (random) one is left unchanged. It works because by the time crypt_keyslot_add_by_volume_key() is called there is a bound (ie assigned to a segment) keyslot left, and the volume key size can be obtained from its ‘key_size’ JSON field. Just filed a bug against cryptsetup / libcryptsetup: https://gitlab.com/cryptsetup/cryptsetup/issues/466 However as far as libblockdev is concerned, FWIW I fully support intrigeri's cherry-pick of upstream's 34ed7be. Adding a key slot *after* having removed it can have very nasty consequences (entire device lost), and that not just for LUKSv2. -- Guilhem.
signature.asc
Description: PGP signature