Re: [PATCH 0/5] lib/crypto: add HKDF and convert fscrypt and NVMe

Thanks for the detailed explanation, and sorry for the slow reply.

I see your point now, and I agree that adding a generic HKDF implementation=
 probably would not buy us much here.
I can still see some value in having a shared, well-tested implementation, =
but I agree it=E2=80=99s probably not worth it in this case.

Thanks again for taking the time to review this.

> On 07/21/2026 5:06 PM CEST Eric Biggers <[email protected]> wrote:
>=20
> =20
> Hi Marco,
>=20
> On Tue, Jul 21, 2026 at 04:06:39PM +0200, Marco Baffo wrote:
> > fscrypt and NVMe authentication each carry private HKDF
> > implementations. Add HKDF-SHA256, HKDF-SHA384, and HKDF-SHA512
> > functions to lib/crypto and convert both users.
> >=20
> > Patches 1-4 are intended for review and inclusion.
> >=20
> > Patch 5 is RFC only and is not intended to be applied. It shows how
> > the OVPN epoch-key code currently under development can use the new
> > HKDF API. That patch has an additional dependency on the OVPN epoch
> > series. It is included here to allow the API to be reviewed against
> > a third user. The OVPN conversion will be submitted separately once
> > its prerequisite code is ready.
> >=20
> > HKDF-Expand accepts info as an array of segments and processes them as
> > if concatenated. This preserves the byte ordering used by fscrypt and
> > allows NVMe to encode HkdfLabel without allocating a temporary buffer.
> >=20
> > HKDF-Extract produces a prepared HMAC key, avoiding repeated key setup
> > when the same PRK is expanded more than once. The implementation uses
> > the direct HMAC library functions and neither allocates memory nor
> > returns errors.
> >=20
> > The series is intended for the libcrypto tree. Patches 3 and 4 need
> > review from the fscrypt and NVMe maintainers, respectively.
> >=20
> > Tested with:
> >=20
> > - HKDF KUnit tests
> > - NVMe authentication KUnit tests
> > - kvm-xfstests smoketest on ext4
> > - kvm-xfstests generic/582, generic/583, and generic/584 on ext4 and f2=
fs
> > - kvm-xfstests encrypt group on ext4 and f2fs
> >=20
> > The following shortlog and diffstat refers only to the first 4 patches.
> >=20
> > Marco Baffo (4):
> >   lib/crypto: add HKDF-SHA{256,384,512}
> >   lib/crypto: tests: add HKDF KUnit tests
> >   fscrypt: use HKDF library functions
> >   nvme-auth: use HKDF library functions for TLS PSK derivation
> >=20
> >  drivers/nvme/common/auth.c    | 120 ++++++++-------
> >  fs/crypto/hkdf.c              |  56 ++-----
> >  include/crypto/hkdf.h         | 131 ++++++++++++++++
> >  lib/crypto/.kunitconfig       |   1 +
> >  lib/crypto/Makefile           |   4 +-
> >  lib/crypto/hkdf-sha256.c      |  22 +++
> >  lib/crypto/hkdf-sha512.c      |  34 +++++
> >  lib/crypto/hkdf-template.h    |  97 ++++++++++++
> >  lib/crypto/tests/Kconfig      |   8 +
> >  lib/crypto/tests/Makefile     |   1 +
> >  lib/crypto/tests/hkdf_kunit.c | 276 ++++++++++++++++++++++++++++++++++
> >  11 files changed, 653 insertions(+), 97 deletions(-)
> >  create mode 100644 include/crypto/hkdf.h
> >  create mode 100644 lib/crypto/hkdf-sha256.c
> >  create mode 100644 lib/crypto/hkdf-sha512.c
> >  create mode 100644 lib/crypto/hkdf-template.h
> >  create mode 100644 lib/crypto/tests/hkdf_kunit.c
>=20
> If we're going to reintroduce an HKDF library, this is probably the way
> to do it (no crypto_shash dependency).
>=20
> But I think the positive diffstat makes having an HKDF library at all in
> the kernel still kind of questionable.  HKDF is just a wrapper around
> HMAC and it can "unroll" to as little as 1-2 HMAC calls.  It's not
> really like the other crypto algorithms where the implementations can be
> very complex and we often have multiple arch-specific implementations.
>=20
> In drivers/nvme/common/auth.c, using the library actually ended up as
> more code than not using it.
>=20
> And in fs/crypto/hkdf.c this patchset only saves a bit (with some of the
> savings coming from deleting helpful comments).
>=20
> In the ovpn case, the extraction step isn't actually used.  Nor are
> multiple expansion iterations needed, since all the keys needing to be
> derived are at most the hash size.  So vs. using hmac_sha256_* directly
> it saves maybe 10-15 lines?  (Note that the diffstat in patch 5 isn't
> directly relevant, as the starting point was crypto_shash.)
>=20
> So then we end up with quite a bit of additional code in lib/crypto/, to
> support users where the diffstat is basically neutral.
>=20
> And this is only HKDF, so this hardly solves key derivation in general.
> Plenty of KDFs don't use HKDF at all, either ones based on block ciphers
> or stream ciphers, or newer hash functions that aren't vulnerable to
> length extension attacks so don't require the HMAC layer.  There are
> lots of other KDFs implemented in the kernel in various places.  Just to
> pick a couple random examples, extract_entropy() in
> drivers/char/random.c is doing a KDF, tcp_ao_calc_traffic_key() in
> net/ipv4/tcp_ao.c is doing a KDF.  Do those need to be libraries too?
>=20
> So overall I would suggest it might be best to hold off on this for now
> and just call the hmac_sha256_* functions directly from
> ovpn_expand_label().  (And again, only one iteration is actually needed
> there, so it doesn't even need to be the full HKDF-Expand.)
>=20
> - Eric