How can one guarantee that the generated DH secret key is of certain length? Say 256bit. Actually, prime length is not enough since the remainder of the last process, the modulus, may result in too small number.
2
-
$\begingroup$ Key derivation functions such as HKDF might be your missing piece. $\endgroup$– DannyNiuApr 28, 2019 at 15:15
-
$\begingroup$ I didn't find a source stating that SSH uses HKDF. SSH makes intensive use of DH. Is it part of DH process itself? What is the source of this information. Even worse, HKDF itself needs predefined set of algorithms to be agreed on among the communicating parties. $\endgroup$– m.nasimApr 28, 2019 at 15:19
Add a comment
|
1 Answer
$\begingroup$
$\endgroup$
8
Once you have computed a DH shared secret, $g^{ab}$, you always hash the result, $k = H(g^{ab})$, before (authenticating it and) using it as a secret key—and preferably, hash the entire transcript of the conversation so far that went into it, like $k = H(g^a, g^b, g^{ab})$, to prevent an adversary from tweaking any part of the handshake that is not authenticated.
The hash $H$ is sometimes called a key derivation function, and there are standard examples like HKDF, often with an extract/expand structure: let $k = \operatorname{HKDF-Extract}(g^a, g^b, g^{ab})$ be the master shared secret key, and then derive subkeys for different purposes by $k_1 = \operatorname{HKDF-Expand}_k(\text{‘first purpose’})$, $k_2 = \operatorname{HKDF-Expand}_k(\text{‘second purpose’})$, etc.
answered Apr 28, 2019 at 15:24
-
$\begingroup$ actually, Diffie-Hellman article on Wikipedia does not mention any thing about the use of HKDF. The only near feasible thing is the PK form of DH, and even it is an optional to avoid MitM attack. Also, HKDF being a standard or not is no the problem. The problem is that i didn't communicate with the remote party that i am going to make use of standard X or standard Y. $\endgroup$– m.nasimApr 28, 2019 at 15:46
-
1$\begingroup$ @m.nasim Wikipedia is a very bad resource for cryptography engineering. There are many reasons to hash the DH shared secret, and it has been standard practice for a long time, even if not directly using HKDF—for example, SSH and TLS predated HKDF but nevertheless hash the DH shared secret before using it as a key. $\endgroup$ Apr 28, 2019 at 15:49
-
$\begingroup$ @m.nasim Don't negotiate it dynamically. Choose HKDF-SHA256 or something in the protocol, from the beginning, and then always use HKDF-SHA256 in all the software implementing the protocol. Then, when you actually run the software and follow the protocol, there is no question to be resolved between the two parties about what KDF to use: it's HKDF-SHA256. $\endgroup$ Apr 28, 2019 at 15:50
-
$\begingroup$ Is there any of SSH RFCs mentioning that use of HKDF. I am 100% sure that KDF is never being negotiated. What if SHA2-256 has been attacked? this means that all SSH implementations should be recompiled and redistributed. IS there a source for that info? $\endgroup$– m.nasimApr 28, 2019 at 15:54
-
$\begingroup$ @m.nasim No, SSH does not use HKDF. Like I said: ‘SSH and TLS predated HKDF but nevertheless hash the DH shared secret before using it as a key.’ They hash the shared secret, just not with HKDF per se. If there are weaknesses in SHA-2, we will indeed deploy updates to protocols, but until they are, it is a disastrous mistake to prematurely optimize that redeployment with ‘algorithm agility’, which means ‘lots of opportunities for an attacker to trick you into using an insecure algorithm’. $\endgroup$ Apr 28, 2019 at 16:00