[Pkg-utopia-maintainers] Bug#928893: gnome-disk-utility: disk content permamently lost when changing LUKS password

[Guilhem Moulin]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-utopia-maintainers/attachments/20190720/296a8f57/attachment.sig>