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. - Eric
