[PATCH] nvme-auth: Hash DH shared secret to create session key

[Martin George]

On Tue, 2026-03-10 at 18:21 -0700, Chris Leech wrote:
> The NVMe Base Specification 8.3.5.5.9 states that the session key Ks
> shall be computed from the ephemeral DH key by applying the hash
> function selected by the HashID parameter.
> 
> The current implementation stores the raw DH shared secret as the
> session key without hashing it. This causes redundant hash
> operations:
> 
> 1. Augmented challenge computation (section 8.3.5.5.4) requires
>    Ca = HMAC(H(g^xy mod p), C). The code compensates by hashing the
>    unhashed session key in nvme_auth_augmented_challenge() to produce
>    the correct result.
> 
> 2. PSK generation (section 8.3.5.5.9) requires PSK = HMAC(Ks, C1 ||
> C2)
>    where Ks should already be H(g^xy mod p). As the DH shared secret
>    is always larger than the HMAC block size, HMAC internally hashes
>    it before use, accidentally producing the correct result.
> 
> When using secure channel concatenation with bidirectional
> authentication, this results in hashing the DH value three times:
> twice
> for augmented challenge calculations and once during PSK generation.
> 

But secure channel concatenation is supported only with unidirectional
auth and not really with bidirectional auth, isn't it? As per NVMe base
spec 2.1, section 8.3.4.5.9 Generated PSK for TLS:
 
"The host may request secure channel concatenation with the TLS
protocol by setting the SC_C field in the AUTH_Negotiate message to
NEWTLSPSK while performing only unidirectional authentication. In this
case the host shall still send a challenge value C2 to the controller
and clear the sequence number S2 to 0h to indicate that controller
authentication is not requested."

-Martin