Re: [PATCH 04/21] nvme-auth: common: add KUnit tests for TLS key derivation

[Chris Leech <cleech@redhat.com>]

Hi Eric, I'm reviewing your patches but just wanted to say thank you for
the details on this comment and respond to them quickly.

On Mon, Mar 02, 2026 at 04:26:49PM -0800, Eric Biggers wrote:
> On Mon, Mar 02, 2026 at 11:04:43AM +0100, Hannes Reinecke wrote:
> > Which discrepancies do you see between the specified algorithm
> > and the implementation?
> 
> I'm looking at the latest NVM Express Base Specification, v2.3.
> 
> First, there's the following:
> 
>     The host computes KS as the hash of the ephemeral DH key resulting
>     from the combination of the random value y selected by the host with
>     the DH exponential (i.e., gx mod p) received from the controller
>     (i.e., KS = H((gx mod p)y mod p) = H(gxy mod p)).
> 
> The actual code skips that step when deriving the PSK, and just
> considers the DH value directly to be "KS" and uses it directly as an
> HMAC key.  That is something that should never be done.  DH values are
> not uniformly distributed and must not be used directly as keys.

We might have an issue with the secure concatantion generated PSK here,
and a shortage of independant implementations to catch this in testing.
I'll take a closer look at it, but at a glance I think I agree.

> Second, the only mention of HKDF is in section 8.3.5.6.2.  Assuming that
> corresponds to what was attempted to be implemented in
> nvme_auth_derive_tls_psk(), it does not match because (at least) the
> specified label does not match the one used in the code.

The AVE stuff in NVMe 8.3.5.6 is _not_ what nvme_auth_derive_tls_psk() is
doing. Most of the TLS handling is specific to TCP as a fabric
transport, and is in the seperate "NVM Express NVMe over TCP Transport
Specification".  In this case, section 3.6.1.3 "TLS PSK and PSK Identity
Derivation".

I'm fairly certain that's sorted now, after some confusion caused by the NVMe
specs calling for HKDF-Expand-Label vs. HKDF-Expand.

- Chris

> Those are just a couple things I noticed in a very quick glance.
> 
> (There's also the key reuse bug I pointed out before.  But it sounds
> like that's a bug in the spec, not the code.)
> 
> - Eric
>