It appears that the textbook version of Diffie-Hellman is susceptible to man in the middle attack and the use of digital signatures could prevent this attack from occurring.

Digital signatures could be implemented during the Diffie-Hellman key exchange in the following way

  1. Alice has a pair of public/private key (SKa,PKa).
  2. Bob has a pair of public/private key(SKb,PKb).
  3. Alice generates her secret key Ka uses her private key SKa to sign (g^Ka) to produce Signature s(m)
  4. Alice uses Bob public key PKb to encrypt her secret key Ka.
  5. Alice sends over encrypted Ka and s(m) over to Bob
  6. Bob will use his private key SKb to decrypt encrypted Ka to get C and use Alice public key PKa on s(m) to get D
  7. Bob authenticates by ensuring that the C == D

I have three questions with regard to this

  1. Is this how authenticated diffie-hellman key exchange using digital signatures is normally done? If not, how is it normally done?
  2. Why do we bother with this form of key exchange where the sender and receiver must send their keys to each other before using the combined key when we can just encrypt the key using the senders private key followed by the receiver public key and send it to the other party?
  3. Are there any flaws with my implementation of authenticated Diffie-Hellman key exchange?

1 Answer 1


Your description is a bit confused and appears to be wrong. In particular, we see Alice computing here Diffie-Hellman half gKA and then proceed to send... her Diffie-Hellman secret KA to Bob, which is not at all what she should do.

Plain Diffie-Hellman works the following way:

  • Alice generates (randomly) her secret KA and computes gKA.
  • Bob generates (randomly) his secret KB and computes gKB.
  • Alice sends gKA to Bob.
  • Bob sends gKB to Alice.
  • Alice computes (gKB)KA, using her secret KA and the value sent by Bob.
  • Bob computes (gKA)KB, using his secret KB and the value sent by Alice.

By the magic of mathematics, Alice and Bob ends up with the same value, which is the shared secret that they thereafter use for whatever cryptography they need to talk to each other.

For the authenticated variant, the same computations are done; but Alice and Bob also own asymmetric key pairs usable for digital signatures, and they use them: Alice signs whatever she sends to Bob, and Bob verifies that signature (using Alice's public key). Similarly, Bob signs what he sends to Alice, and Alice verifies that signature (using Bob's public key).

Note that a no point whatsoever does Alice send KA (he "DH secret") to Bob in any form. Neither does Bob send KB to Alice. And there is no encryption anywhere. You may encounter many tutorials that purport to explain digital signatures in terms of encryption (usually as "encryption with the private key"). These explanation are remnants of older times (the late 1970s, in fact, in the original Disco era) and are, in fact, plain wrong and very confusing. So don't think in those terms. Signatures are signatures, encryption is encryption.

Authenticated DH is what is done in, for instance, in SSL/TLS with the "DHE" cipher suites. It is also what happens in SSH (version 2).

There are two main reasons for using such an "ephemeral" Diffie-Hellman ("ephemeral" because Alice and Bob generate their DH secrets KA and KB on the fly):

  • The "permanent" key pairs owned by Alice and Bob may be unfit for anything else than signatures. A source of confusion (again) is that there is not one algorithm called RSA; there are at least two, one for encryption and one for signatures, and they appear to be able to use the same kind of key pairs. However, even if a RSA key pair can be used both for encryption and signatures, there are good reasons not to do so. There are also other signature algorithms (e.g. ECDSA) whose keys cannot be used (at least not easily) for encryption.

  • Using ephemeral DH secrets provides Forward Secrecy, which is good. Namely, the permanent keys of Alice and Bob must be stored somewhere; so they could, potentially, be stolen afterwards. With simple RSA-based key exchange (no DH, Alice encrypts a random session key with Bob's public key and Bob decrypts it), the ulterior key thief could use it to decrypt a past session. With the DH and the signatures, this issue does not occur; even if Alice's and Bob's signature private keys are revealed afterwards, their past communications cannot be decrypted. The whole concept of forward secrecy revolves around the idea that the "DH secrets", being generated on-the-fly, kept in RAM only, and destroyed immediately after completion of the DH key exchange, are immune to ulterior theft.

  • Thanks , this is an excellent answer , appreciate it from the bottom of my heart Commented Nov 18, 2014 at 17:33
  • "for the authenticated variant, Alice and Bob also own asymmetric key pairs usable for digital signatures". If we do that then there is no way to prove that PK_Alice belongs to Alice.
    – dimitris93
    Commented Oct 26, 2016 at 21:45
  • Resurrection: What forces the MITM to forward Alice's public key to Bob and Bob's public key to Alice?
    – SDiv
    Commented Jun 30, 2017 at 22:19
  • @SDiv in something like TLS, you usually only authenticate the DH parameters in one direction - server to client - because the client already has the server's public key from the server's X.509 TLS certificate. The client trusts that the certificate contains the correct key because it can verify the name against the site it's connecting to, and the signature (on the certificate) can be verified against the certificate using the public key of the issuing certificate authority. If the MITM sent their own certificate, or modified the server's cert to have thie own pubkey, it wouldn't verify.
    – CBHacking
    Commented Dec 20, 2023 at 0:09
  • @CBHacking So, without third party authentication or a trusted link, DH is susceptible to MITM?
    – SDiv
    Commented Dec 22, 2023 at 16:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .