Re: [PATCH 09/11] nvmet: Implement basic In-Band Authentication

On 7/19/21 1:52 PM, Stephan Mueller wrote:

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

quoted

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.

Oh fsck. Of course. Would've been too easy.
Well, more coding required then. Let's see how it goes.
But thanks for your help!

(And I wouldn't say no if someone would step in an provide a 'real'
FFDHE crypto algorithm; now that the parameters are already present :-)

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		           Kernel Storage Architect
hare@suse.de			                  +49 911 74053 688
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), GF: Felix Imendörffer