181 lines
7.2 KiB
Text
181 lines
7.2 KiB
Text
Cryptsetup 2.3.5 Release Notes
|
|
==============================
|
|
Stable bug-fix release with minor extensions.
|
|
|
|
All users of cryptsetup 2.x and later should upgrade to this version.
|
|
|
|
Changes since version 2.3.4
|
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
|
|
* Fix partial reads of passphrase from an interactive terminal.
|
|
Some stable kernels (5.3.11) started to return buffer from a terminal
|
|
in parts of maximal size 64 bytes.
|
|
This breaks the reading of passphrases longer than 64 characters
|
|
entered through an interactive terminal. The change is already fixed
|
|
in later kernel releases, but tools now support such partial read from
|
|
terminal properly.
|
|
|
|
* Fix maximal length of password entered through a terminal.
|
|
Now the maximal interactive passphrase length is exactly
|
|
512 characters (not 511).
|
|
|
|
* integritysetup: support new dm-integrity HMAC recalculation options.
|
|
|
|
In older kernels (since version 4.19), an attacker can force
|
|
an automatic recalculation of integrity tags by modifying
|
|
the dm-integrity superblock.
|
|
This is a problem with a keyed algorithms (HMAC), where it expects
|
|
nobody can trigger such recalculation without the key.
|
|
(Automatic recalculation will start after the next activation.)
|
|
|
|
Note that dm-integrity in standalone mode was *not* supposed
|
|
to provide cryptographic data integrity protection.
|
|
Despite that, we try to keep the system secure if keyed algorithms
|
|
are used.
|
|
Thank Daniel Glöckner for the original report of this problem.
|
|
|
|
Authenticated encryption that provides data integrity protection (in
|
|
combination with dm-crypt and LUKS2) is not affected by this problem.
|
|
|
|
The fix in the kernel for this problem contains two parts.
|
|
|
|
Firstly, the dm-integrity kernel module disables integrity
|
|
recalculation if keyed algorithms (HMAC) are used.
|
|
This change is included in long-term stable kernels.
|
|
|
|
Secondly, since the kernel version 5.11, dm-integrity introduces
|
|
modified protection where a journal-integrity algorithm guards
|
|
superblock; also, journal sections are protected. An attacker cannot
|
|
copy sectors from one journal section to another, and the superblock
|
|
also contains salt to prevent header replacement from another device.
|
|
|
|
If you want to protect data with HMAC, you should always also use HMAC
|
|
for --journal-integrity. Keys can be independent.
|
|
If HMAC is used for data but not for the journal, the recalculation
|
|
option is disabled.
|
|
|
|
If you need to use (insecure) backward compatibility implementation,
|
|
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
|
|
HMAC format.
|
|
|
|
Libcryptsetup API also introduces flags
|
|
CRYPT_COMPAT_LEGACY_INTEGRITY_HMAC and
|
|
CRYPT_COMPAT_LEGACY_INTEGRITY_RECALC
|
|
to set these through crypt_set_compatibility() call.
|
|
|
|
* integritysetup: display of recalculating sector in dump command.
|
|
|
|
* veritysetup: fix verity FEC if stored in the same image with hashes.
|
|
|
|
Optional 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
|
|
the FEC area itself. This produced unusable and too large FEC data.
|
|
There is no problem if the FEC image is a separate image.
|
|
|
|
The problem is now fixed, introducing FEC blocks calculation as:
|
|
- If the hash device is in a separate image, metadata covers the
|
|
whole rest of the image after the hash area. (Unchanged behavior.)
|
|
- If hash and FEC device is in the image, metadata ends on the FEC
|
|
area offset.
|
|
|
|
Note: there is also a fix for FEC in the dm-verity kernel (on the way
|
|
to stable kernels) that fixes error correction with larger RS roots.
|
|
|
|
* veritysetup: run FEC repair check even if root hash fails.
|
|
|
|
Note: The userspace FEC verify command reports are only informational
|
|
for now. Code does not check verity hash after FEC recovery in
|
|
userspace. The Reed-Solomon decoder can then report the possibility
|
|
that it fixed data even if parity is too damaged.
|
|
This will be fixed in the next major release.
|
|
|
|
* veritysetup: do not process hash image if hash area is empty.
|
|
|
|
Sometimes the device is so small that there is only a root hash
|
|
needed, and the hash area is not used.
|
|
Also, the size of the hash image is not increased for hash block
|
|
alignment in this case.
|
|
|
|
* veritysetup: store verity hash algorithm in superblock in lowercase.
|
|
|
|
Otherwise, the kernel could refuse the activation of the device.
|
|
|
|
* bitlk: fix a crash if the device disappears during BitLocker scan.
|
|
|
|
* bitlk: show a better error when trying to open an NTFS device.
|
|
|
|
Both BitLocker version 1 and NTFS have the same signature.
|
|
If a user opens an NTFS device without BitLocker, it now correctly
|
|
informs that it is not a BITLK device.
|
|
|
|
* bitlk: add support for startup key protected VMKs.
|
|
|
|
The startup key can be provided in --key-file option for open command.
|
|
|
|
* Fix LUKS1 repair code (regression since version 1.7.x).
|
|
|
|
We cannot trust possibly broken keyslots metadata in repair, so the
|
|
code recalculates them instead.
|
|
This makes the repair code working again when the master boot record
|
|
signature overwrites the LUKS header.
|
|
|
|
* Fix luksKeyChange for LUKS2 with assigned tokens.
|
|
|
|
The token references are now correctly assigned to the new keyslot
|
|
number.
|
|
|
|
* Fix cryptsetup resize using LUKS2 tokens.
|
|
|
|
Code needlessly asked for passphrase even though volume key was
|
|
already unlocked via LUKS2 token.
|
|
|
|
* Print a visible error if device resize is not supported.
|
|
|
|
* Add error message when suspending wrong non-LUKS device.
|
|
|
|
* Fix default XTS mode key size in reencryption.
|
|
|
|
The same luksFormat logic (double key size because XTS uses two keys)
|
|
is applied in the reencryption code.
|
|
|
|
* Rephrase missing locking directory warning and move it to debug level.
|
|
|
|
The system should later provide a safe transition to tempdir
|
|
configuration, so creating locking directory inside libcryptsetup
|
|
call is safe.
|
|
|
|
* Many fixes for the use of cipher_null (empty debug cipher).
|
|
|
|
Support for this empty cipher was intended as a debug feature and for
|
|
measuring performance overhead. Unfortunately, many systems started to
|
|
use it as an "empty shell" for LUKS (to enable encryption later).
|
|
|
|
This use is very dangerous and it creates a false sense of security.
|
|
|
|
Anyway, to not break such systems, we try to support these
|
|
configurations.
|
|
Using cipher_null in any production system is strongly discouraged!
|
|
|
|
Fixes include:
|
|
- allow LUKS resume for a device with cipher_null.
|
|
- do not upload key in keyring when data cipher is null.
|
|
- switch to default cipher when reencrypting cipher_null device.
|
|
- replace possible bogus cipher_null keyslots before reencryption.
|
|
- fix broken detection of null cipher in LUKS2.
|
|
cipher_null is no longer possible to be used in keyslot encryption
|
|
in LUKS2, it can be used only for data for debugging purposes.
|
|
|
|
* Fixes for libpasswdqc 2.0.x (optional passphrase quality check).
|
|
|
|
* Fixes for problems discovered by various tools for code analysis.
|
|
|
|
Fixes include a rework of libpopt command line option string leaks.
|
|
|
|
* Various fixes to man pages.
|