We can't easily distinguish between a passphrase and other
protectors like recovery passphrase or startup key during
activation so we can't stop when attempted passphrase activation
fails because a binary startup key can't be conveted to UTF-16
during KDF.
Right now, cryptsetup makes an attempt to include the correct
definitions in all of its header files, allowing the headers to
compile regardless of the context in which they are included.
A few files were missed, this change fixes them by adding the minimal
set of #includes needed to get them to compile.
Signed-off-by: Joe Richey <joerichey@google.com>
cipher[31] and cipher_mode[31] buffers were passed to
crypt_parse_name_and_mode() routine where sscanf(s, "%31[^-]-%31s",
cipher, cipher_mode) was called.
In corner case it could cause terminating 0 byte written beyond
respective arrays.
Keep it simple. If there's not enough memory we can't validate
segments. The LUKS2 specification does not recommend to continue
processing LUKS2 metadata if it can not be properly validated.
In case LUKS2 backup segment creates gap in between last regular
segment and backup segment report invalid metadata imediately. We stop
on first error so there's no need to allocate large memory on heap
(we may ran with mlock(MCL_FUTURE) set).
Example:
- total segments count is 3
- regular segments have keys "0" and "1"
- first backup segment has key "42"
Segments are validated in hdr_validate_segments. Gaps in segment keys
are detected when collecting offsets. But if an invalid segment is very
large, larger than count, it could happen that cryptsetup is unable to
allocate enough memory, not giving a clue about what actually is the
problem.
Therefore check for gaps even if not enough memory is available. This
gives much more information with debug output enabled.
Obviously cryptsetup still fails if segments are perfectly fine but not
enough RAM available. But at that stage, the user knows that it's the
fault of the system, not of an invalid segment.
These performance options, introduced in kernel 5.9, configures
dm-crypt to bypass read or write workqueues and run encryption
synchronously.
Also support persistent storage of these flags for LUKS2.
If users want to use blake2b/blake2s, the kernel algorithm name
includes dash - like "blake2s-256".
Because we use dash as a separator, this patch adds an exception
for this case.
Fixes: #581.
TrueCrypt/VeraCrypt always use 512-bytes sector for encryption,
but for devices with a larger native sector it stores this value in header.
This patch allows activating of such devices, basically ignoring
the mentioned sector size in header (it only must be multiple
of 512-bytes sector).
Fixes: #580.
When creating LUKS2 header with specified --offset much larger
then LUKS2 header size we needlessly also wipe (allocate up to
--offset) much larger file than needed.
We've assumed that first 4 bytes of the decrypted key data is the
size of the key + metadata. Looks like this isn't true and only
first two bytes contain the size and the other two bytes are
unknown data, possibly related to reencryption and/or passphrase
change.
Fixes: #575
The EBOIV initialization vector is intended to be used
internally with BitLocker devices (for CBC mode).
It can be used in some specific cases for other devices.
This patch adds userspace implementation duplicating
the same EBOIV as the dm-crypt kernel.
Fixes: #562
We need to use the iv_large_sectors flag and correct sector size
for the crypt segments for these devices. Used sector size is
read from the device header. This commit also adds two new test
images with 4k sectors.
Fixes: #557
* TRUE/FALSE are not defined anymore. 1 and 0 are used instead.
* json_object_get_uint64() and json_object_new_uint64() are part
of the upstream API now.
Kernel 5.7 adds support for optional discard/TRIM operation
for dm-integrity (available only for internal hash, not for LUKS2
with integrity).
This patch adds support for the new option.
Previous fix for longer passhphrases increased maximal
passphrase length even if it was not needed, for example
if used with SHA256 hash in combination with keyfiles.
This patch tries to fix the problem, so some older volumes
can be opened again.
Also some test images are added for regression testing.
Fixes: #542.
There might be a trailing newline added by the text editor when
the recovery passphrase was passed using the '--key-file' option
so we'll remove it before trying to use the passphrase.
Some kernels show invalid dm-integrity table if suberblock
contains "recalculate" bit.
We can workaround that by setting recalculate option in table
(kernel uses bits from superblock anyway), so the table displayed
is always correct.
Fixes: #538
If crypto backend is missing support for hash algorithms used
in PBKDF2 during slot derivatiom the fail was not visible.
Print at least error message to user in this case.
Fixes: #536
