The function is supposed to check if manipulated
active dm-crypt device matches the on-disk metadata.
Unfortunately it did not take into account differences
between normal cipher specification (aes-xts-plain64)
and capi format specification (capi:xts(aes)-plain64).
The internal query function always converted capi format
in normal format and therefor failed if capi format was
used in metadata.
Fixes: #759.
- Do not require any libraries installed, download everything
from upstream git, statically compile (use include, libs and pkg-config
from local directory under tests/fuzz).
Script should work both from OSS-Fuzz and locally.
- Do not require local protobuf (only staticallly compiled, see above).
- Add README.md (TBD, still not finished).
- Fix make dist and distcheck.
- Remove common.[ch] as we can use internal function.
This makes fuzzers also C++ only (remove CFLAGS from Makefile).
In LUKS1 there is only one hash algorithm specification,
it cannot happen, that AF hash algorithm is not
available, as it is used immediately before in PBKDF2.
In LUKS2 this can be completely different algorithm, so
it make sense to print a visible warning for user.
For example, Whirlpool and RIPEMD160 is now in OpenSSL legacy
provider which can be unavailable, see #773.)
This patch adds a message only, the code already fails with -EINVAL.
In practice luksAddKey action does two operations. It unlocks existing
device volume key and stores unlocked volume key in a new keyslot.
Previously the options were limited to key files and passphrases.
With this patch user may combine freely following options:
To unlock keyslot with volume key user may:
- provide existing passphrase via interactive prompt (default method)
- use --key-file option to provide file with a valid passphrase to existing keyslot
- provide volume key directly via --volume-key-file
- unlock keyslot via all available LUKS2 tokens by --token-only
- unlock keyslot via specific token with --token-id
- unlock keyslot via specific token type by --token-type
To provide the passphrase for a new keyslot user may:
- provide existing passphrase via interactive prompt (default method)
- use --new-keyfile parameter or positional parameter to read the
passphrase from file.
- use --new-token-id to select specific LUKS2 token to get passphrase
for new keyslot. New keyslot is assigned to selected token id if
operation is succesfull.
Fixes: #725.
The crypt_keyslot_add_by_keyslot_context & associated
helper functions allow more options when adding new
keyslot. For example there was no simple way of
adding new LUKS2 keyslot when the only active keyslot
could be unlocked by passphrase (KEK) provided by LUKS2 token
(plugin). Now all available options for unlocking keyslots
may also be used when creating new keyslot and it combine
as called needs.
The available methods (keyslot contexts) are:
passphrase, keyfile, key (binary representation) and LUSK2 token.
