When user provides --token-type or specific --token-id
prefer token PIN query over passphrase query (if token
handler responds with 'PIN needed').
Fixes: #670.
Commit 0113ac2d broke test passphrase mode when
device was in LUKS2 reencryption.
Previously --test-passphrase parameter automatically raised
CRYPT_ACTIVATE_ALLOW_UNBOUND_KEY flag. It did not make sense
when users mostly want to test whether device can be activated by
provided passphrase or not. Raise the aforementioned flag only
if user requested it either by --unbound parameter or when
specific keyslot was selected.
Reported in: https://bugzilla.redhat.com/show_bug.cgi?id=2056439Fixes: #716.
Abort action luksResume early if device is not suspended.
We would needlesly ask for passphrase or load cryptsetup
plugins only to fail later in crypt_resume_by_* API.
OpenSSL now enforces minimal parameters for PBKDF2 according to SP 800-132
key length (112 bits), minimal salt length (128 bits) and minimal number
of iterations (1000).
Our benchmark violates this, causeing cryptsetup misbehave for luksFormat.
Just inrease tet salt to 16 bytes here, it will little bit influence benchmark,
but there is no way back.
Currently, token import and token add actions will fail if you use the
--token-id option to specify a token ID that is already in use, but there
are scenarios where you might genuinely want to replace an existing token
in a single atomic operation.
A use case for this might be for a keyslot that is protected by a
TPM, where you store the TPM sealed key and associated metadata as a
token and you want to update the PCR policy associated with the sealed
object or make other changes to it. Currently this requires importing a
new token and then removing the old token.
Instead, add a --token-replace option to allow token import and token
add to replace an existing token if you try to add or import one with an
ID that is already in use.
Currently LUKS2 decryption cannot perform data decryption
with data shift. Even though we can decrypt devices with
data offset > 0 in LUKS2 metadata it does not make much
sense. Such devices cannot be easily mounted after decryption
is finished due to said data offset (fs superblock is moved
typicaly by 16MiBs).
1) Crypsetup repair should try to call crypt_repair() even
if crypt_load is ok - it has no validate system unlike LUKS2
and some errors cannot be hard load errors.
2) Move ECB fix to repair code, do not try magic on load that
no longer works.
And do not use ECB :)
Fixes: #664
While adding or importing new token and assigning immediately to
keyslot it would be useful to provide specific error message
directly from cryptsetup utility when keyslot does not exist.
This reverts commit 367cb7a761
and retains original crypt_reencrypt() symbol marked as deprecated
in favour of new crypt_reencrypt_run(). This makes cryptsetup 2.4.0
release fully backward compatible.
crypt_activate_by_token (and _pin variant) now returns -ENOANO
instead -EAGAIN in case token handler identifies specific token
requires PIN to sucessfully complete token based activation.
-EAGAIN is now used for special case when additional system
resources are missing (HW token, other device, system daemon,
etc).
While TrueCrypt is no longer developed and supported since 2014,
VeraCrypt devices (as a successor of TrueCrypt) are much more
used today.
This patch switch default to scan for VeraCrypt signature, making
--veracrypt option obsolete (ignored by default as it is default).
If you need to disable VeraCrypt support, use new option
--disable-veracrypt.
Reencryption did not take into account adjusted xts
key size configuration option. This patch fix the
issue by using same logic as in luksFormat with xts
mode selected for data encryption.
By default when reencrypting LUKS2 device we regenerate only
the volume key. But if the device was 'encrypted' by cipher_null
this change did not make sense. The key was always empty.
Change the behaviour so that unless user specifies --cipher
parameter on command line, we change data encryption cipher
to default when old segment cipher was cipher_null.
By mistake LUKS2 allowed keyslots 'not-so-encrypted' by
cipher_null (only explicitly requested by --cipher or
--keyslot-cipher parameters). If we encounter
such old key during reencryption let's replace the cipher
for new keyslot with default LUKS2 keyslot cipher.
