# How does Diffie-Hellman key exchange work? [closed]

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?

## closed as too broad by e-sushi, Gilles, DrLecter, archie, D.W.Aug 15 '14 at 3:29

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

• 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.) – e-sushi Aug 13 '14 at 17:25
• DH is combined with a shared secret, such as a prior session key, to prevent MITM. – Jeff-Inventor ChromeOS Aug 13 '14 at 23:33

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.

• Should perfect sharing secrecy be perfect forward secrecy, or are the terms synonymous? – Maarten Bodewes Aug 14 '14 at 15:52