Reaching maximal keyfile size is already reported as error.
Note that interactive really means user entering password.
For all other us there is keyfile processing.
Related: #933
For 32bit platforms size_t is 32bit integer and unfortunately
our maximum hard limit overflows by 1.
Stop validation if this happens (it cannot be passed to malloc()
and similar functions anyway).
There should be no compatibility change, as such memory
is not allocatable on 32bit anyway.
Other platforms have 64bit size_t.
NOTE: This is possibly an incompatible change as it changes text output.
Since the support of --sector-size option, the description "sectors"
became ambiguous as it usually means 512-byte sectors (device-mapper unit).
Major confusion occurs when the sector size is 4096 bytes while units display
is in 512-bytes.
Unfortunately, there is no clear compatible way, so this patch adds
[512-byte units] marker and also additional byte size value.
All other fields that display units are changed to use the "[units]" format.
The integrity format is also unified with the common style with ':' as a separator.
Fixes: #884.
For now, we used zeroed key for dm-integrity format, as there was not
data area. In future, there can be wrapped key scheme, that will require
to setup real key even in this situation.
This patch modifies the integrity format flow that the real key is used
during format.
Mostly based on code from Ingo Franzki <ifranzki@linux.ibm.com>
This patch add support for setting of integrity key size
for LUKS2 devices.
It adds new (optional) JSON "key_size" attribute in segment.integrity JSON object.
If not set, the code use hash length size (backward compatible).
For LUKS2, we do not allow smaller keys than 128 bits.
Mostly based on code from Ingo Franzki <ifranzki@linux.ibm.com>
This patch implement support for setting specific integrity key size
option in dm-crypt, available since dm-crypt version 1.28.0.
This can be used for setting non-standard HMAC key length.
Mostly based on code from Ingo Franzki <ifranzki@linux.ibm.com>
There is no functional change in this patch except it avoids
strange confusion during some static tests.
The cd->type must be set in this function anyway.
This is only preparation for an extension later, however, the volume
keys should not be unloaded unconditionally from keyring.
Note that all other places dropping keys already check that keys
were uploaded through key ID setting.
(And for suspend unconditional unlink make sense too.)
The key_decripion always contains only a key name,
keyring then contains type of keyring as defned un keyring utils.
For now, only LOGON type is used in commands, it will be extended later.
The luks2_internal.h contains specific JSON implementations while
luks2.h is generic. Code outside of luks2/ dir should not use internals.
Also luks2.h includes functions prototypes that are used from setup.c.
There was a bug in both crypt_token_assign_keyslot and
crypt_token_unsassign_keyslot where CRYPT_ANY_TOKEN
special value could be passed in token parameter.
It would correctly assign/unassign all tokens to/from
the specified keyslot (or from any in case of CRYPT_ANY_SLOT),
but it returned -1 (CRYPT_ANY_TOKEN) which fited error return
values as per API documentation.
We fixed that by not supporting CRYPT_ANY_TOKEN since it does
not make much sense. It can be workarounded by iterating over
all available tokens and calling crypt_token_assign_keyslot or
crypt_token_unassign_keyslot accodingly.
Fixes: #914.
Thsi patch avoids this cppcheck warning:
Error: CPPCHECK_WARNING (CWE-457): [#def1]
cryptsetup-main/lib/crypto_backend/argon2/blake2/blake2b.c:369: warning[uninitvar]: Uninitialized variable: out_buffer
It is a false positive, but wiping buffer is cheap a and similar approach is used
in other Argon2 implementations (OpenSSL).
This patch avoid warning in constant-time base64 function:
Error: CPPCHECK_WARNING (CWE-190): [#def2]
cryptsetup-main/lib/crypto_backend/argon2/encoding.c:86: error[integerOverflow]: Signed integer overflow for expression ''0'-52'.
The (x + ('0' - 52)) can be rewritten to (x - (52 - '0')) with the same effect.
Similar solution used in https://github.com/pornin/CTTK/blob/master/src/base64.c
After switching to reencryption by keyslot context,
the digest was not properly verified before crash recovery.
We need to reverify reencryption digest after metadata
reloads unconditionally.