The deadlock is hypothetical since libcryptsetup applications
usualy terminates after error. The deadlock could only emerge
in case where single process handles multiple crypt contexts.
The old API is still supported and because we support very old
OpenSSL, this is the best wrokaround for the warnings.
Once we switch to the new OpenSSL version requirement, we can rewrite
HMAC to new EVP_MAC API.
Reverts commit 96d83455ca partially. It is not necessary to
have specific crypt_activate_by_token_type call. Users
may use crypt_activate_by_token_pin with pin argument set to NULL
and achieve same goal as with crypt_activate_by_token_type.
Currently the "add" action adds the token to all keyslots, this
changes the behaviour to make sure the token is added to the first
keyslot that can be unlocked using the provided passphrase.
Test needs to work also in build environment
before installation takes place. For it we overload
crypt_token_external_path symbol from libcryptsetup
so that it can look for plugins in build environment.
[simplified by mbroz]
Search for token handlers in %{libdir}/cryptsetup directory
by default. Distros may change default location via
--with-luks2-external-tokens-path parameter during configuration.
Argon2 draft defines suggested parameters for disk encryption use, but LUKS2
approach is slightly different. We need to provide platform independent
values. The values in draft expects 64bit systems (suggesting using 6 GiB
of RAM), while we need to provide compatibility with all 32bit systems,
so allocating more than 4GiB memory is not option for LUKS2.
The maximal limit in LUKS2 stays for 4 GiB, and by default LUKS2
PBKDF benchmarking sets maximum to 1 GIB, prefering increase of CPU cost.
But for the minimal memory cost we had a quite low limit 32 MiB.
This patch increases the bechmarking value to 64 MiB (as minimal
suggested values in Argon2 RFC). For compatibility reasons we still
allow older limit if set by a parameter.
Cryptsetup LUKS2 was using Argon2 while there were two versions -
data independt (Argon2i) suitable for the KDF use case andm Argon2d
(data dependent), that is in princile unsuitable for LUKS2.
Later a new version Argon2id was introduced and this is now default
(and mandatory) algorithm as RFC Argon2 draft defines.
While Argon2id basically combines both approaches from Argon2i
and Argon2d (to provide bette side-channel resistence) it seems
reasonable to switch to Argon2id as default.
Fixes: #555
