Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

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?

share|improve this question

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

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

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

1 Answer 1

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.

share|improve this answer
    
Should perfect sharing secrecy be perfect forward secrecy, or are the terms synonymous? –  Maarten Bodewes - owlstead Aug 14 at 15:52

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