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

[Hannes Reinecke]

On 7/19/21 1:52 PM, Stephan Mueller wrote:
> Am Montag, dem 19.07.2021 um 13:10 +0200 schrieb Hannes Reinecke:
>> On 7/19/21 12:19 PM, Stephan Mueller wrote:
>>> Am Montag, dem 19.07.2021 um 11:57 +0200 schrieb Hannes Reinecke:
>>>> On 7/19/21 10:51 AM, Stephan Mueller wrote:
[ .. ]
>>>>>
>>>>> 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.
> 
Hmm. Okay. But after having read section 5.6.1.1.4, I still do have some
questions.

Assume we will be using a bit length of 512 for FFDHE, then we will
trivially pass Step 2 for all supported FFDHE groups (the maximum
symmetric-equivalent strength for ffdhe8192 is 192 bits).

>From my understanding, the random number generator will fill out all
available bytes in the string (and nothing more), so we trivially
satisfy step 3 and 4.

And as q is always larger than the random number, step 6 reduces to
'if (c > 2^N - 2)', ie we just need to check if the random number is a
string of 0xff characters. Which hardly is a random number at all, so
it'll be impossible to get this.

Which then would mean that our 'x' is simply the random number + 1,
which arguably is slightly pointless (one more than a random number is
as random as the number itself), so I do feel justified with just
returning a random number here.

Am I wrong with that reasoning?

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		           Kernel Storage Architect
hare at 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