Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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)

share|improve this question
    
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 – Jonas Dralle Apr 21 at 14:56
    
So can Eve make a replay attack on this protocol? – Nathaniel Apr 21 at 15:41
up vote 1 down vote accepted

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)$

then

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.

share|improve this answer

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.
share|improve this answer

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.

share|improve this answer
    
But Eve can't sign her g^z, therefore Alice and Bob would not accept it... – Nathaniel Apr 21 at 23:28
    
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 – Cpt Wobbles Apr 24 at 21:29
    
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 – Cpt Wobbles Apr 24 at 21:30

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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