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

Chris Leech cleech at redhat.com
Tue Mar 3 14:47:56 PST 2026


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.

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.

- Chris




More information about the Linux-nvme mailing list