Diffie-Hellman key exchange, also called exponential key exchange, is a method of * digital encryption* that uses numbers raised to specific powers to produce decryption

*s on the basis of components that are never directly transmitted, making the task of a would-be code breaker mathematically overwhelming.*

**key**Let’s say Alice and Bob want to communicate with each other without John knowing what they’re saying or sending. Anything Alice sends to Bob, John will receive, likewise, anything Bob sends to Alice, John will also receive. So how do Alice and Bob send anything to each other without John understanding? Well that’s where Diffie-Hellman comes in.

To start, Alice and Bob decide publicly (John will also get a copy) on two prime numbers, ** g** and

**. Generally**

*n***is a small prime number and**

*g***is quite large, usually 2000 or more commonly 4000 bits long. So now Alice, Bob and John all know these numbers.**

*n*Now Alice decides secretly on another number,** a**. and Bob decides secretly on a number,

**. Neither Alice nor Bob send these numbers, they are kept to themselves. Alice performs a calculation,**

*b***, we’ll call this**

*g ^ a mod n***, since it comes from**

*A***. Bob then performs**

*a***which we’ll call**

*g ^ b mod n***.**

*B*Alice sends Bob,** A**, and Bob sends Alice,

**. Note John now has 4 numbers,**

*B***and**

*A, B, g***but not**

*n***or**

*a***. Finally, for the heart of the trick. Alice takes Bob’s**

*b***and performs**

*B***. Similarly, Bob takes Alice’s**

*B ^ a mod n***and performs**

*A***. This results in the same number i.e.**

*A ^ b mod n***. They now have a shared number. Notice how John can’t figure out what these numbers are from the numbers he’s got.**

*B ^ a mod n = A ^ b mod n*Actually he can and its given a name called solving the discrete log problem. If we make ** n** very large this becomes an extremely computationally heavy problem to solve and simply isn’t worth the time to figure out. John would have to figure out

**or**

*a***from**

*b***or**

*A***which is simply far too time consuming.**

*B*So what can Alice and Bob do with this key they’ve just created together? Well they can use it to start encrypting messages they send to each other. A very simple example that should not be used anywhere as it’s extremely insecure is in encrypting their messages with a shift cipher (* Caesar cipher*) where the shift value is determined by the newly generated key. Both Alice and Bob can encrypt and decrypt the messages as they know the shift value but John can’t as he doesn’t have the key.

Diffie-Hellman key exchange is a cornerstone of applied cryptography, but it is often less secure than widely believed. The problems stem from the fact that the number field sieve for discrete log allows an attacker to perform a single precomputation that depends only on the group, after which computing individual logs in that group has a far lower cost. Although this fact is well known to cryptographers, it apparently has not been widely understood by system builders. Likewise, many cryptographers did not appreciate that the security of a large fraction of Internet communication depends on Diffie-Hellman key exchanges that use a few small, widely shared groups.

A key lesson from this state of affairs is that cryptographers and creators of practical systems need to work together more effectively. System builders should take responsibility for being aware of applicable cryptanalytic attacks. Cryptographers, for their part, should involve themselves in how crypto is actually being applied, such as through engagement with standards efforts and software review. Bridging the perilous gap that separates these communities will be essential for keeping future systems secure.

* The Logjam attack*: A man-in-the-middle can force TLS clients to use export-strength DH with any server that allows DHE_EXPORT. Then, by finding the 512-bit discrete log, the attacker can learn the session key and arbitrarily read or modify the contents. Data

^{fs}refers to False Start application data that some TLS clients send before receiving the server’s Finished message.