Am Montag, dem 19.07.2021 um 13:10 +0200 schrieb Hannes Reinecke:

On 7/19/21 12:19 PM, Stephan Mueller wrote:

quoted

Am Montag, dem 19.07.2021 um 11:57 +0200 schrieb Hannes Reinecke:

quoted

On 7/19/21 10:51 AM, Stephan Mueller wrote:

quoted

Am Montag, dem 19.07.2021 um 10:15 +0200 schrieb Hannes Reinecke:

quoted

On 7/18/21 2:56 PM, Stephan Müller wrote:

quoted

Am Sonntag, 18. Juli 2021, 14:37:34 CEST schrieb Hannes Reinecke:

quoted

quoted

quoted

The key is also used when using the ffdhe algorithm.
Note: I _think_ that I need to use this key for the ffdhe
algorithm,
because the implementation I came up with is essentially plain
DH
with
pre-defined 'p', 'q' and 'g' values. But the DH implementation
also
requires a 'key', and for that I'm using this key here.

It might be that I'm completely off, and don't need to use a key
for
our
DH implementation. In that case you are correct.
(And that's why I said I'll need a review of the FFDHE
implementation).
But for now I'll need the key for FFDHE.

Do I understand you correctly that the dhchap_key is used as the
input
to
the 
DH - i.e. it is the remote public key then? It looks strange that
this
is
used 
for DH but then it is changed here by hashing it together with
something
else 
to form a new dhchap_key. Maybe that is what the protocol says.
But it
sounds 
strange to me, especially when you think that dhchap_key would be,
say,
2048 
bits if it is truly the remote public key and then after the
hashing
it is
256 
this dhchap_key cannot be used for FFC-DH.

Or are you using the dhchap_key for two different purposes?

It seems I miss something here.

No, not entirely. It's me who buggered it up.
I got carried away by the fact that there is a
crypto_dh_encode_key()
function, and thought I need to use it here.

Thank you for clarifying that. It sounds to me that there is no
defined
protocol (or if there, I would be wondering how the code would have
worked
with a different implementation). Would it make sense to first specify
a
protocol for authentication and have it discussed? I personally think
it
is a
bit difficult to fully understand the protocol from the code and
discuss
protocol-level items based on the code.

Oh, the protocol _is_ specified:

 
https://nvmexpress.org/wp-content/uploads/NVM-Express-Base-Specification-2_0-2021.06.02-Ratified-5.pdf

It's just that I have issues translating that spec onto what the kernel
provides.

according to the naming conventions there in figures 447 and following:

- x and y: DH private key (kernel calls it secret set with dh_set_secret
or
encoded into param.key)

But that's were I got confused; one needs a private key here, but there
is no obvious candidate for it. But reading it more closely I guess the
private key is just a random number (cf the spec: g^y mod p, where y is
a random number selected by the host that shall be at least 256 bits
long). So I'll fix it up with the next round.

Here comes the crux: the kernel has an ECC private key generation function
ecdh_set_secret triggered with crypto_kpp_set_secret using a NULL key, but it
has no FFC-DH counterpart.

That said, generating a random number is the most obvious choice, but not the
right one.

The correct one would be following SP800-56A rev 3 and here either section
5.6.1.1.3 or 5.6.1.1.4.

Ciao
Stephan

quoted

- g^x mod p  / g^y mod p: DH public keys from either end that is
communicated
over the wire (corresponding to the the DH private keys of x and y) - to
set
it, you initialize a dh request and set the public key to it with
kpp_request_set_input. After performing the
crypto_kpp_compute_shared_secret
you receive the shared secret

- g^xy mod p: DH shared secret - this is the one that is to be used for
the
subsequent hashing /HMAC operations as this is the one that is identical
on
both, the host and the controller.

Thanks. Will be checking the code if I do it correctly.

Cheers,

Hannes