Re: [RFC PATCH v2 2/2] dm-inlinecrypt: add target for inline block device encryption

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/17/24 10:28 PM, Eric Biggers wrote:
On Thu, Oct 17, 2024 at 10:17:04PM +0200, Milan Broz wrote:
On 10/17/24 9:44 PM, Eric Biggers wrote:
On Wed, Oct 16, 2024 at 04:27:48PM -0700, Eric Biggers wrote:
Add a new device-mapper target "dm-inlinecrypt" that is similar to
dm-crypt but uses the blk-crypto API instead of the regular crypto API.
This allows it to take advantage of inline encryption hardware such as
that commonly built into UFS host controllers.

A slight difference in behavior vs. dm-crypt that I just became aware of:
dm-crypt allows XTS keys whose first half equals the second half, i.e.
cipher key == tweak key.  dm-inlinecrypt typically will not allow this.  Inline
encryption hardware typically rejects such keys, and blk-crypto-fallback rejects
them too because it uses CRYPTO_TFM_REQ_FORBID_WEAK_KEYS.

IMO, rejecting these weak keys is desirable, and the fact that dm-inlinecrypt
fixes this issue with dm-crypt will just need to be documented.

Hm, I thought this is already rejected in crypto API (at least in FIPS mode)...

It should be rejected exactly as you described even for dm-crypt,
just the check should be (IMO) part of crypto API (set keys), not dm-crypt itself.

And here I think we should not be backward "compatible" as it is security issue,
both XTS keys just must not be the same.


In "FIPS mode" such keys are always rejected, but otherwise it is opt-in via the
flag CRYPTO_TFM_REQ_FORBID_WEAK_KEYS.  dm-crypt doesn't use that flag.

We could certainly try to fix that in dm-crypt, though I expect that some
dm-crypt users have started relying on such keys.  It is a common misconception
that XTS is secure when the two halves of the key are the same.

Ah, ok, I missed that weak keys flag.

We never did that in cryptsetup (including LUKS and plain with hashed passwords),
with the exception for benchmark (where it it was not a real key, just all zeroes,
and was fixed years ago as it did not work in FIPS) -- and obviously the case when
user set the key explicitly.

The same check is now in VeraCrypt (that uses dm-crypt on Linux).
I know about several broken HW crypto, but actually no dm-crypt user.

IMO we should set CRYPTO_TFM_REQ_FORBID_WEAK_KEYS by default. We can always introduce
flag to disable it, but I would really like to know if there are any real users....

Milan





[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux