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.
Due to nature of recent change in GCC10 that silently
broken symbol versioning, let's be a bit pedantic
and test all symbols are available in all versions that
meant to be exported to users.
The new dm-integrity option in kernel 5.13 can restart
recalculation from the beginning of the device.
It can be used to change the integrity checksum function.
This patch adds support to libcryptsetup for this flag
and adds --integrity-recalculate-rest option to integritysetup.
Fixes: #631.
In ideal system nothing should touch test devices, but to make tests
more robust, we should expect that something is still scanning devices
after activation. So replace all checks for CRYPT_ACTIVE to allow
also CRYPT_BUSY.
(Fixes some problems seen in #633)
We support most recent crypto algorithms, so this
is only addition of the Blake hash family.
Kernel and gcrypt crypto backend supports all variants,
OpenSSL only Blake2b-512 and Blake2s-256.
There is no useable support for NSS and Nettle yet.
Crypto backend supports kernel notation e.g. "blake2b-512"
that is translated to the library backend names.
Some stable kernels started to return buffer from terminal
in partial buffers of maximal size 64 bytes.
This breaks all passphrases longer than 64 characters entered
through interactive input (for all crypto formats).
(The problem is probably fixed in more recent kernels, but
the read() call can always return a partial read here.)
This patch also fixes wrong password limit, the last character
of passphrase of maximal size was never handled.
Now the maximal passphrase length is really 512 characters.
Fixes: #627.
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.
FEC (Forward Error Correction) data should cover the whole data area,
hashes (Merkle tree) and optionally additional metadata (located after hash area).
Unfortunately, if FEC data is stored in the same file as hash, the calculation
wrongly used the whole file size thus overlaps with FEC area itself.
This produces unusable and too large FEC data.
(There is not a problem if FEC image is a separate image.)
This patch fixes the problem, introducing FEC blocks calculation as:
-If hash device is in a separate image, metadata covers the whole rest of the image after hash area.
(Unchanged behaviour.)
-If hash and FEC device is in the image, metadata ends on the FEC area offset.
This should probably fix several issues reported with FEC wrong calculations.
Fixes: #554
If FEC was enabled, the error for bad root hash was replaced
by error correction (datga were ok, only root hash was wrong).
Do not run recovery test if root hash is incorrect.
To avoid confusion, use just one lib include and specify sub-directories
for format inclusions.
This should also help some analysis tools to find proper includes.
Add API call that can directly print JSON metadata area from LUKS2 device.
For commandline it also adds --dump-json-metadata option for luksDump action.
Note that the binary metadata (UUID, version etc) is not part of this output.
(We reserve flags parameter to be able to add this later.)
Fixes: #511
The code expects that change key is done in-place if there is not
a free space in keyslot area for safe key swap.
This patch makes the code behaves the same as in LUKS1,
luksChangeKey now works the same.
With JSON, we can actually retain the slot number in all cases
(except user intentionally set new slot #).
This patch changes the crypt_keyslot_change_by_passphrase() API
call to retain keyslot number for LUKS2.
Fixes: #464
This patch adds support for Linux kernel (since version 5.11) dm-integrity
fixes that disables integrity recalculation if keyed algorithms (HMAC) is used.
Original dm-integrity superblock version <=4 is recalculation offset
field not protected by HMAC. An attacker can move this pointer and force
the kernel to recalculate the data area, ignoring original HMAC tags.
N.B. dm-integrity was not intended to protect against intentional changes.
Better use authenticated encryption (AEAD) in combination with dm-crypt.
It is designed to protect against random data corruption caused by hardware
or storage medium faults.
Despite that, we try to keep the system secure if keyed algorithms are used.
There are two possible keyed algorithms in dm-integrity - algorithm used
to protect journal and superblock (--journal-integrity) and algorithms
for protecting data (--integrity).
The dm-integrity superblock is guarded by --journal-integrity, so if you want
to protect data with HMAC, you should always also use HMAC for --journal-integrity.
The keys are independent. If HMAC is used for data but not for the journal,
recalculation is disabled by default.
For new kernel dm-integrity, the HMAC option also uses salt in superblock
to avoid an easy way to distinguish that the HMAC key is the same for two devices
(if data are the same).
The new HMAC and superblock are enabled automatically if the kernel supports it
(you can see superblock version 5 and fix_hmac flag in dump command).
If you need to use (insecure) backward compatibility, then two new integritysetup
options are introduced:
Use --integrity-legacy-recalc (instead of --integrity-recalc) to allow recalculation
on legacy devices.
Use --integrity-legacy-hmac in format action to force old insecure version
format (with HMAC).
Libcryptsetup API also introduces flags
CRYPT_COMPAT_LEGACY_INTEGRITY_HMAC and
CRYPT_COMPAT_LEGACY_INTEGRITY_RECALC
to set these through crypt_set_compatibility() call.
LUKS2 decryption is currently not supported for devices
with LUKS2 metadata placed in head of data devices. The decryption
still works correctly, but resulting plaintext device has data on
unexpected (original) offset. For example at offset of 16MiB in case
of default LUKS2 header.
Fixes: #614.
crypt_header_is_detached checks if initialized LUKS context uses detached header
(LUKS header located on a different device than data.)
This is a runtime attribute, it does not say if a LUKS device requires detached header.
If user knows which particular PBKDF2 hash or cipher is used for
True/VeraCrypt container, using --hash of --cipher option in tcryptDump
and tcryptOpen can scan only these variants.
Note for the cipher it means substring (all cipher chains containing
the cipher are tried).
For example, you can use
cryptsetup tcryptDump --hash sha512 <container>
Note: for speed up, usually the hash option matters, cipher variants
are scanned very quickly.
Use witch care, in a script it can reveal some sensitive attribute
of the container.
Fixes#608.
