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: >>>>> 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. > > 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@xxxxxxx +49 911 74053 688 SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg HRB 36809 (AG Nürnberg), GF: Felix Imendörffer
