As we all know, the Diffie-Hellman key exchange protocol without authentication is vulnerable to a man-in-the-middle attack. And if we use STS(Station-to-Station protocol) instead, it would be secure.

My question is: Suppose we use a variant of Diffie-Hellman key exchange protocol with signatures like this:

  1. Alice $\rightarrow$ Bob : $Bx = g^{Ax} ,S_a(Bx)$
  2. Alice $\leftarrow$ Bob : $By = g^{Ay} ,S_b(By)$

Then they have a shared key $g^{(Ax\ \times\ Ay)}$.

It's like STS but not the same.

  1. So is it secure against man-in-the-middle attack?

  2. Suppose Eve is an active man-in-the-middle, will Eve be able to decrypt Alice's or Bob's message later on? (Suppose Alice and Bob won't send Ax,Ay in this channel)

  • $\begingroup$ No. When exchanging keys the key itself doesnt matter. It's the combination of the own private part and the received public part that makes it strong. When someone intercepts both public parts he/she got nothing $\endgroup$
    – BlueWizard
    Commented Apr 21, 2016 at 14:56
  • $\begingroup$ So can Eve make a replay attack on this protocol? $\endgroup$
    – Nathaniel
    Commented Apr 21, 2016 at 15:41

3 Answers 3


Short answer: No, it is not vulnerable to man-in-the-middle attacks, assuming that Alice and Bob each have the right signature verification key of the other party.

Yet, the man-in-the-middle attack could have taken place at the moment of exchanging the signature verification key. So if $sig_{X}$ is party X's signature key, the attack on the exchange itself could go as follows (using your notations):

Alice $\rightarrow$ Eve : $Bx = g^{Ax}, \mathsf{Sign}(sig_{Alice}, Bx) $

Eve $\rightarrow$ Bob : $Bx^\prime = g^{Ax^\prime}, \mathsf{Sign}(sig_{Eve}, Bx^\prime)$


Bob $\rightarrow$ Eve : $By = g^{Ay}, \mathsf{Sign}(sig_{Bob}, By) $

Eve $\rightarrow$ Alice : $By^\prime = g^{Ay^\prime}, \mathsf{Sign}(sig_{Eve}, By^\prime)$

Alice and Bob would accept the transcript, believing they are actually talking to each other (since they respectively believe that $sig_{Eve}$ is the other's actual signing key). As a result, the protocol would be exactly as secure as unauthenticated DH exchange.

On the other hand, if Alice (for instance) received Bob's key in a "verifiable" manner, for example via trusted certification authorities, or during a face-to-face meeting with Bob that attack could not happen: Alice would detect that $\mathsf{Sign}(sig_{Eve}, By^\prime)$ was not actually signed by Bob. In practice (in Tor for instance), at least one of the parties has the certified public encryption key of the other and sends its half of DH encrypted. That is considered secure.

Also, in any case, as pointed in kodlu's answer, the protocol is vulnerable to replay attacks.


It is secure against private key exposure but not against replay attacks by Eve. A three-way protocol avoids this, and doesn't need to use timestamps. The description below is from Delfs and Knebl's book Introduction to Cryptography.

Each user, say Alice, has a key pair $(e_A, d_A)$ for encryption and another key pair $(s_A, v_A)$ for digital signatures.

It is assumed that everyone has access to Alice’s authentic public keys, $e_A$ and $v_A$, for encryption and the verification of signatures. Define the signature algorithm as the pair $Sign(),Verify(),$ the encryption algorithm is DH, using public key $e_A$, e.g.

  1. Alice chooses $r_A$ at random, sets $t_1 := (B, r_A)$ (where $B$ represents Bob’s identity), $s_1 := Sign_{s_A}(t_1)$ and sends $(t_1, s_1)$ to Bob.
  2. Bob verifies Alice’s signature, checks that he is the intended recipient, chooses $r_B$ and a session key $k$ at random, encrypts the session key with Alice’s public key, $c := E_{e_A}(k)$, sets $t_2 := (A, r_A, r_B, c)$, signs $t_2$ to get $s_2 := Sign_{s_B}(t_2)$ and sends $(t_2, s_2)$ to Alice.
  3. Alice verifies Bobs signature, checks that she is the intended recipient and that the $r_A$ she received matches the $r_A$ from step 1 (this prevents replay attacks). If both verifications pass, she is convinced that her communication partner is Bob. Now Alice decrypts the session key $k$, sets $t_3 := (B, r_B)$, $s_3 := Sign_{s_A}(t_3)$ and sends $(t_3, s_3)$ to Bob.
  4. Bob verifies Alice’s signature and checks that the $r_B$ he received matches the $r_B$ from step 2 (this again prevents replay attacks). If both verifications pass, Bob and Alice use $k$ as the session key.

Here is how it can be Vulnerable.

Alice: $x$ Bob $y$ Eve $z$

Alice$\rightarrow$ $g^x$ $\rightarrow$ Eve->$g^z$->Bob

Bob$\rightarrow$ $g^y$$\rightarrow$Eve$\rightarrow$ $g^z$$\rightarrow$Alice

What Alice thinks key is $g^{(xz)}$ what Bob thinks the key is $g^{(zy)}$ Eve can compute both of these values $(g^x)^z$ and $(g^y)^z$

This is why we need Certificate Authorities, as how do you KNOW what is indeed Alice's key or Bobs key? Your modification to Diffie-Hellman still needs a CA.

  • $\begingroup$ But Eve can't sign her g^z, therefore Alice and Bob would not accept it... $\endgroup$
    – Nathaniel
    Commented Apr 21, 2016 at 23:28
  • $\begingroup$ If you are using a signature scheme, then there are other things you can do. If we assume that Bob knows Alice's public key and not Eves, then yes you are right. But you need a Certificate Authority to make this happen. If you are using Diffe Hellman KEY exchange, you still need a Certificate authority $\endgroup$ Commented Apr 24, 2016 at 21:29
  • $\begingroup$ If you are talking about a Diffie Hellman exchange for symmetric MACs, then Eve still sign with her key because she can verify signatures and sign messages herself. So she can through out the tag send by Bob, then she can sign it herself and it will verify to Alice $\endgroup$ Commented Apr 24, 2016 at 21:30

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.