Re: [PATCH AUTOSEL 5.10 021/101] fscrypt: allow 256-bit master keys with AES-256-XTS

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

 



On Mon, Nov 08, 2021 at 05:48:40PM -0800, Eric Biggers wrote:
On Mon, Nov 08, 2021 at 12:47:11PM -0500, Sasha Levin wrote:
From: Eric Biggers <ebiggers@xxxxxxxxxx>

[ Upstream commit 7f595d6a6cdc336834552069a2e0a4f6d4756ddf ]

fscrypt currently requires a 512-bit master key when AES-256-XTS is
used, since AES-256-XTS keys are 512-bit and fscrypt requires that the
master key be at least as long any key that will be derived from it.

However, this is overly strict because AES-256-XTS doesn't actually have
a 512-bit security strength, but rather 256-bit.  The fact that XTS
takes twice the expected key size is a quirk of the XTS mode.  It is
sufficient to use 256 bits of entropy for AES-256-XTS, provided that it
is first properly expanded into a 512-bit key, which HKDF-SHA512 does.

Therefore, relax the check of the master key size to use the security
strength of the derived key rather than the size of the derived key
(except for v1 encryption policies, which don't use HKDF).

Besides making things more flexible for userspace, this is needed in
order for the use of a KDF which only takes a 256-bit key to be
introduced into the fscrypt key hierarchy.  This will happen with
hardware-wrapped keys support, as all known hardware which supports that
feature uses an SP800-108 KDF using AES-256-CMAC, so the wrapped keys
are wrapped 256-bit AES keys.  Moreover, there is interest in fscrypt
supporting the same type of AES-256-CMAC based KDF in software as an
alternative to HKDF-SHA512.  There is no security problem with such
features, so fix the key length check to work properly with them.

Reviewed-by: Paul Crowley <paulcrowley@xxxxxxxxxx>
Link: https://lore.kernel.org/r/20210921030303.5598-1-ebiggers@xxxxxxxxxx
Signed-off-by: Eric Biggers <ebiggers@xxxxxxxxxx>
Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

I don't expect any problem with backporting this, but I don't see how this
follows the stable kernel rules (Documentation/process/stable-kernel-rules.rst).
I don't see what distinguishes this patch from ones that don't get picked up by
AUTOSEL; it seems pretty arbitrary to me.

It is, to some extent. My understanding was that this is a minor fix to
make something that should have worked, work.

--
Thanks,
Sasha



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux