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

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

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.

Thanks
Stephan