-3
$\begingroup$

I've been learning about cryptography lately and I'm failing to understand how Diffie-Hellman key exchange works. Can someone please demonstrate using mathematical notation (and if possible, pseudocode) how this works?

I'm also failing to understand how it prevents man-in-the-middle attacks. If Oscar is sitting in the middle of the conversation, can't he just change which keys the actual users communicate (with him) with, thereby installing himself as a broker for the entire session?

$\endgroup$
2
  • 4
    $\begingroup$ What research have you done? After all, the related Wikipedia article provides exactly what you’re asking for: a cryptographic explanation, pseudo-code, and a “secrecy chart” which explains what Eve (=your Oscar) knows and what Eve (=your Oscar) can’t learn when residing in a MITM position. (Please note that we generally expect you to do “a significant amount of research” before asking here, including searching the internet and this site. At worst it will help you frame a better question; at best it will answer it.) $\endgroup$
    – e-sushi
    Aug 13, 2014 at 17:25
  • $\begingroup$ DH is combined with a shared secret, such as a prior session key, to prevent MITM. $\endgroup$ Aug 13, 2014 at 23:33

1 Answer 1

3
$\begingroup$

How does Diffie-Hellman prevent a man-in-the-middle attack?

Answer: Diffie-Hellman does not prevent a man-in-the-middle attack.

If you're using Diffie-Hellman without any sort of authentication, then Oscar can certainly change the keys. When he does that, what's effectively happen is that Alice and Bob aren't actually negotiating keys; Alice is negotiating with Oscar (and generating one set of keys), and Oscar is negotiating with Bob (and generating another set of keys). If Oscar wants, he can proceed to allow Alice and Bob to communicate (by decrypting any traffic from Alice, and then re-encrypting it with Bob's keys; of course, he can record and/or modify the traffic at whim).

Because of this, it is considered fundamental that whenever you use Diffie-Hellman, you include something that performs authentication; that is, something that allows Alice to confirm that Bob is on the other end of the encrypted connection. Some schemes that have actually been used in practice:

  • Bob signs his Diffie-Hellman public value; if Alice has Bob's public key (or alternatively, Bob has a certificate that Alice can validate), Oscar is unable to duplicate that.

  • Alice and Bob share a secret value that is used to generate a MAC of the Diffie-Hellman public value (or the shared secret), and nothing else.

Now, the obvious question is: Alice and Bob can share a key using either public keys, or a preexisting shared secret; what does Diffie-Hellman bring to the table? The answer to that is Perfect Shared Secrecy: If Alice and Bob used Diffie-Hellman (and zeroized the private exponents and the shared secret when they are done with them) then Oscar cannot decrypt the transcript, even if he later discovers all of Alice's and Bob's secret values.

In contrast, you could use public key encryption to transport a shared key from one side to the other, however if someone later discovers the private key (e.g. it gets leaked), then he can go back, and decrypt a transcript of the connection.

$\endgroup$
1
  • $\begingroup$ Should perfect sharing secrecy be perfect forward secrecy, or are the terms synonymous? $\endgroup$ Aug 14, 2014 at 15:52

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