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: >>> Am Montag, dem 19.07.2021 um 10:15 +0200 schrieb Hannes Reinecke: >>>> On 7/18/21 2:56 PM, Stephan Müller wrote: >>>>> Am Sonntag, 18. Juli 2021, 14:37:34 CEST schrieb Hannes Reinecke: >>> >>>>>> 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. > - 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 -- Dr. Hannes Reinecke Kernel Storage Architect hare@xxxxxxx +49 911 74053 688 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg HRB 36809 (AG Nürnberg), GF: Felix Imendörffer
