1
$\begingroup$

We have Alice and Bob. The man in the middle can manipulate(remove, add something etc.) A sent from Alice and B sent from Bob, how can he figure out what the common key K(A,B) is, without knowing kpr(a) and kpr(b)? Everything is based on Elliptic Curves.

$\endgroup$

migrated from security.stackexchange.com May 26 '16 at 18:35

This question came from our site for information security professionals.

  • 3
    $\begingroup$ Why are you asking? Do you know that or ask if the MITM can get this info? Is this a homework assigment? Any starting points that you have thought of already? $\endgroup$ – Jan Doggen May 23 '16 at 17:50
  • $\begingroup$ Question is: How can he figure out the common key? I think he cant, but can someone prove that he can do it? $\endgroup$ – Sick654 May 23 '16 at 18:26
  • $\begingroup$ Figuring out the common key is not possible; that's what DH is supposed to protect. Posing as either one of the two partners is however possible, generating a different common key for each connection. Now Alice and Bob think they share a common key but they are actually sharing a different "common key" with Mallory (who will probably share it with Mickey). $\endgroup$ – Maarten Bodewes May 27 '16 at 8:27
6
$\begingroup$

Diffie-Hellman (and variants such as ECDH) protect against passive eavesdroppers, but not (at least by themselves) against active man-in-the-middle attacks. An active MITM can substitute his own keys for Alice and Bob's keys during the initial exchange, something like this:

Alice -> Bob (intercepted by Mallory): Hi Bob, I'm Alice and here's my public key: [Alice's public key]

Mallory -> Bob: Hi Bob, I'm Alice and here's my public key: [Mallory's public key]

Bob -> Alice (intercepted by Mallory): Pleased to meet you Alice, I'm Bob and here's my public key: [Bob's public key]

Mallory -> Alice: Pleased to meet you Alice, I'm Bob and here's my public key: [Mallory's public key]

Alice then computes a shared key based on her private key and "Bob" (actually Mallory)'s public key, and uses that to encrypt data to/from "Bob" (actually Mallory). Similarly, Bob computes a shared key he thinks is shared with Alice, but is actually shared with Mallory. Mallory uses the two public keys and his own private keys to compute both shared keys, and uses them to decrypt and reencrypt the messages passing between Alice and Bob.

This is why it's important to couple DH key exchange with some sort of authentication. For instance, in TLS's ephemeral DH and ECDH modes, the server signs its DH parameters (including its DH public key) to insure that they haven't been tampered with.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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