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

[Eric Biggers]

On Tue, Mar 03, 2026 at 02:47:56PM -0800, Chris Leech wrote:
> 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.
> 
> I'm doing some testing with a patch to immediatly hash the DH value
> after the kpp request is complete, fixing nvme_auth_generate_psk(),
> while removing the hashing step from nvme_auth_augmented_challenge().
> That only allows the use of KS as the raw DH output is not saved.

Yes, that's the right way to do it.

> But, I think things are saved by DH values always being larger than the
> HMAC block size and therefor hashed within hmac_shaXXX_preparekey().
> Maybe more lucky than correct, but the same result.

Interesting.  Yes, that might work, but only by accident.

- Eric