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
_______________________________________________ Pkg-utopia-maintainers mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-utopia-maintainers
