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.

  • $\begingroup$ Key derivation functions such as HKDF might be your missing piece. $\endgroup$
    – DannyNiu
    Commented Apr 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.nasim
    Commented Apr 28, 2019 at 15:19

1 Answer 1


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.

  • $\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.nasim
    Commented Apr 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$ Commented 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$ Commented 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.nasim
    Commented Apr 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$ Commented Apr 28, 2019 at 16:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.