Diffie–Hellman key exchange
Diffie–Hellman key exchange (D–H) ^{[nb 1]} is a specific method of securely exchanging cryptographic keys over a public channel and was one of the first publickey protocols as originally conceptualized by Ralph Merkle and named after Whitfield Diffie and Martin Hellman.^{[1]}^{[2]} D–H is one of the earliest practical examples of public key exchange implemented within the field of cryptography.
Traditionally, secure encrypted communication between two parties required that they first exchange keys by some secure physical channel, such as paper key lists transported by a trusted courier. The Diffie–Hellman key exchange method allows two parties that have no prior knowledge of each other to jointly establish a shared secret key over an insecure channel. This key can then be used to encrypt subsequent communications using a symmetric key cipher.
Diffie–Hellman is used to secure a variety of Internet services. However, research published in October 2015 suggests that the parameters in use for many D–H Internet applications at that time are not strong enough to prevent compromise by very wellfunded attackers, such as the security services of large governments.^{[3]}
The scheme was first published by Whitfield Diffie and Martin Hellman in 1976,^{[2]} but in 1997 it was revealed that James H. Ellis,^{[4]} Clifford Cocks and Malcolm J. Williamson of GCHQ, the British signals intelligence agency, had previously shown how publickey cryptography could be achieved.^{[5]}
Although Diffie–Hellman key agreement itself is a nonauthenticated keyagreement protocol, it provides the basis for a variety of authenticated protocols, and is used to provide forward secrecy in Transport Layer Security's ephemeral modes (referred to as EDH or DHE depending on the cipher suite).
The method was followed shortly afterwards by RSA, an implementation of publickey cryptography using asymmetric algorithms.
Template:US patent,^{[6]} from 1977, is now expired and describes the nowpublic domain algorithm. It credits Hellman, Diffie, and Merkle as inventors.
Name
In 2002, Hellman suggested the algorithm be called Diffie–Hellman–Merkle key exchange in recognition of Ralph Merkle's contribution to the invention of publickey cryptography (Hellman, 2002), writing:
 The system...has since become known as Diffie–Hellman key exchange. While that system was first described in a paper by Diffie and me, it is a public key distribution system, a concept developed by Merkle, and hence should be called 'Diffie–Hellman–Merkle key exchange' if names are to be associated with it. I hope this small pulpit might help in that endeavor to recognize Merkle's equal contribution to the invention of public key cryptography.^{[7]}
Description
General overview
Diffie–Hellman Key Exchange establishes a shared secret between two parties that can be used for secret communication for exchanging data over a public network. The following conceptual diagram illustrates the general idea of the key exchange by using colors instead of very large numbers.
The process begins by having the two parties, Alice and Bob, agree on an arbitrary starting color that does not need to be kept secret (but should be different every time^{[8]}); in this example the color is yellow. Each of them selects a secret color–red and aqua respectively–that they keep to themselves. The crucial part of the process is that Alice and Bob now mix their secret color together with their mutually shared color, resulting in orange and blue mixtures respectively, then publicly exchange the two mixed colors. Finally, each of the two mix together the color they received from the partner with their own private color. The result is a final color mixture (brown) that is identical to the partner's color mixture.
If another party (usually named Eve in cryptology publications, Eve being a thirdparty who is considered to be an eavesdropper) had been listening in on the exchange, it would be computationally difficult for that person to determine the common secret color; in fact, when using large numbers rather than colors, this action is likely very difficult for modern supercomputers to do in a reasonable amount of time.
Cryptographic explanation
The simplest and the original implementation of the protocol uses the multiplicative group of integers modulo p, where p is prime, and g is a primitive root modulo p. These two values are chosen in this way to ensure that the resulting shared secret can take on any value from 1 to p–1. Here is an example of the protocol, with nonsecret values in blue, and secret values in red.
 Alice and Bob agree to use a modulus p = 23 and base g = 5 (which is a primitive root modulo 23).
 Alice chooses a secret integer a = 6, then sends Bob A = g^{a} mod p
 A = 5^{6} mod 23 = 8
 Bob chooses a secret integer b = 15, then sends Alice B = g^{b} mod p
 B = 5^{15} mod 23 = 19
 Alice computes s = B^{a} mod p
 s = 19^{6} mod 23 = 2
 Bob computes s = A^{b} mod p
 s = 8^{15} mod 23 = 2
 Alice and Bob now share a secret (the number 2).
Both Alice and Bob have arrived at the same value s, because, under mod p,
<math>A^b\bmod\,p = g^{ab}\bmod\,p = g^{ba}\bmod\,p = B^a\bmod\,p</math>^{[9]}
More specifically,
<math>(g^{a}\bmod\,p)^{b}\bmod\,p = (g^{b}\bmod\,p)^{a}\bmod\,p</math>
Note that only a, b, and (g^{ab} mod p = g^{ba} mod p) are kept secret. All the other values – p, g, g^{a} mod p, and g^{b} mod p – are sent in the clear. Once Alice and Bob compute the shared secret they can use it as an encryption key, known only to them, for sending messages across the same open communications channel.
Of course, much larger values of a, b, and p would be needed to make this example secure, since there are only 23 possible results of n mod 23. However, if p is a prime of at least 600 digits, then even the fastest modern computers cannot find a given only g, p and g^{a} mod p. Such a problem is called the discrete logarithm problem.^{[3]} The computation of g^{a} mod p is known as modular exponentiation and can be done efficiently even for large numbers. Note that g need not be large at all, and in practice is usually a small integer (like 2, 3, ...).
Secrecy chart
The chart below depicts who knows what, again with nonsecret values in blue, and secret values in red. Here Eve is an eavesdropper—she watches what is sent between Alice and Bob, but she does not alter the contents of their communications.
 g = public (prime) base, known to Alice, Bob, and Eve. g = 5
 p = public (prime) modulus, known to Alice, Bob, and Eve. p = 23
 a = Alice's private key, known only to Alice. a = 6
 b = Bob's private key known only to Bob. b = 15
 A = Alice's public key, known to Alice, Bob, and Eve. A = g^{a} mod p = 8
 B = Bob's public key, known to Alice, Bob, and Eve. B = g^{b} mod p = 19



Now s is the shared secret key and it is known to both Alice and Bob, but not to Eve.
Note: It should be difficult for Alice to solve for Bob's private key or for Bob to solve for Alice's private key. If it is not difficult for Alice to solve for Bob's private key (or vice versa), Eve may simply substitute her own private / public key pair, plug Bob's public key into her private key, produce a fake shared secret key, and solve for Bob's private key (and use that to solve for the shared secret key. Eve may attempt to choose a public / private key pair that will make it easy for her to solve for Bob's private key).
Another demonstration of DiffieHellman (also using numbers too small for practical use) is given here.^{[10]}
Generalization to finite cyclic groups
Here is a more general description of the protocol:^{[11]}
 Alice and Bob agree on a finite cyclic group G of order n and a generating element g in G. (This is usually done long before the rest of the protocol; g is assumed to be known by all attackers.) The group G is written multiplicatively.
 Alice picks a random natural number a, where 1 ≤ a < n, and sends g^{a} to Bob.
 Bob picks a random natural number b, which is also 1 ≤ b < n, and sends g^{b} to Alice.
 Alice computes (g^{b})^{a}.
 Bob computes (g^{a})^{b}.
Both Alice and Bob are now in possession of the group element g^{ab}, which can serve as the shared secret key. The group G satisfies the requisite condition for secure communication if there is not an efficient algorithm for determining g^{ab} given g, g^{a}, and g^{b}.
For example, the Elliptic curve Diffie–Hellman protocol is variant that uses elliptic curves instead of the multiplicative group of integers modulo p. Variants using hyperelliptic curves have also been proposed. The Supersingular isogeny key exchange is a DiffieHellman variant that has been designed to be secure against quantum computers.
Operation with more than two parties
Diffie–Hellman key agreement is not limited to negotiating a key shared by only two participants. Any number of users can take part in an agreement by performing iterations of the agreement protocol and exchanging intermediate data (which does not itself need to be kept secret). For example, Alice, Bob, and Carol could participate in a Diffie–Hellman agreement as follows, with all operations taken to be modulo p:
 The parties agree on the algorithm parameters p and g.
 The parties generate their private keys, named a, b, and c.
 Alice computes g^{a} and sends it to Bob.
 Bob computes (g^{a})^{b} = g^{ab} and sends it to Carol.
 Carol computes (g^{ab})^{c} = g^{abc} and uses it as her secret.
 Bob computes g^{b} and sends it to Carol.
 Carol computes (g^{b})^{c} = g^{bc} and sends it to Alice.
 Alice computes (g^{bc})^{a} = g^{bca} = g^{abc} and uses it as her secret.
 Carol computes g^{c} and sends it to Alice.
 Alice computes (g^{c})^{a} = g^{ca} and sends it to Bob.
 Bob computes (g^{ca})^{b} = g^{cab} = g^{abc} and uses it as his secret.
An eavesdropper has been able to see g^{a}, g^{b}, g^{c}, g^{ab}, g^{ac}, and g^{bc}, but cannot use any combination of these to efficiently reproduce g^{abc}.
To extend this mechanism to larger groups, two basic principles must be followed:
 Starting with an "empty" key consisting only of g, the secret is made by raising the current value to every participant’s private exponent once, in any order (the first such exponentiation yields the participant’s own public key).
 Any intermediate value (having up to N1 exponents applied, where N is the number of participants in the group) may be revealed publicly, but the final value (having had all N exponents applied) constitutes the shared secret and hence must never be revealed publicly. Thus, each user must obtain their copy of the secret by applying their own private key last (otherwise there would be no way for the last contributor to communicate the final key to its recipient, as that last contributor would have turned the key into the very secret the group wished to protect).
These principles leave open various options for choosing in which order participants contribute to keys. The simplest and most obvious solution is to arrange the N participants in a circle and have N keys rotate around the circle, until eventually every key has been contributed to by all N participants (ending with its owner) and each participant has contributed to N keys (ending with their own). However, this requires that every participant perform N modular exponentiations.
By choosing a more optimal order, and relying on the fact that keys can be duplicated, it is possible to reduce the number of modular exponentiations performed by each participant to Template:Nowrap using a divideandconquerstyle approach, given here for eight participants:
 Participants A, B, C, and D each perform one exponentiation, yielding g^{abcd}; this value is sent to E, F, G, and H. In return, participants A, B, C, and D receive g^{efgh}.
 Participants A and B each perform one exponentiation, yielding g^{efghab}, which they send to C and D, while C and D do the same, yielding g^{efghcd}, which they send to A and B.
 Participant A performs an exponentiation, yielding g^{efghcda}, which it sends to B; similarly, B sends g^{efghcdb} to A. C and D do similarly.
 Participant A performs one final exponentiation, yielding the secret g^{efghcdba} = g^{abcdefgh}, while B does the same to get g^{efghcdab} = g^{abcdefgh}; again, C and D do similarly.
 Participants E through H simultaneously perform the same operations using g^{abcd} as their starting point.
Once this operation has been completed all participants will possess the secret g^{abcdefgh}, but each participant will have performed only four modular exponentiations, rather than the eight implied by a simple circular arrangement.
Security
The protocol is considered secure against eavesdroppers if G and g are chosen properly. In particular, the order of the group G must be large, particularly if the same group is used for large amounts of traffic. The eavesdropper ("Eve") has to solve the Diffie–Hellman problem to obtain g^{ab}. This is currently considered difficult for groups whose order is large enough. An efficient algorithm to solve the discrete logarithm problem would make it easy to compute a or b and solve the Diffie–Hellman problem, making this and many other public key cryptosystems insecure. Fields of small characteristic may be less secure.^{[12]}
The order of G should have a large prime factor to prevent use of the Pohlig–Hellman algorithm to obtain a or b. For this reason, a Sophie Germain prime q is sometimes used to calculate Template:Nowrap, called a safe prime, since the order of G is then only divisible by 2 and q. g is then sometimes chosen to generate the order q subgroup of G, rather than G, so that the Legendre symbol of g^{a} never reveals the low order bit of a. A protocol using such a choice is for example IKEv2.^{[13]}
g is often a small integer such as 2. Because of the random selfreducibility of the discrete logarithm problem a small g is equally secure as any other generator of the same group.
If Alice and Bob use random number generators whose outputs are not completely random and can be predicted to some extent, then Eve's task is much easier.
In the original description, the Diffie–Hellman exchange by itself does not provide authentication of the communicating parties and is thus vulnerable to a maninthemiddle attack. Mallory may establish two distinct key exchanges, one with Alice and the other with Bob, effectively masquerading as Alice to Bob, and vice versa, allowing her to decrypt, then reencrypt, the messages passed between them. Note that Mallory must continue to be in the middle, transferring messages every time Alice and Bob communicate. If she is ever absent, her previous presence is then revealed to Alice and Bob. They will know that all of their private conversations had been intercepted and decoded by someone in the channel.
A method to authenticate the communicating parties to each other is generally needed to prevent this type of attack. Variants of Diffie–Hellman, such as STS protocol, may be used instead to avoid these types of attacks.
Practical attacks on Internet traffic
The number field sieve algorithm, which is generally the most effective in solving the discrete logarithm problem, consists of four computational steps. The first three steps only depend on the order of the group G, not on the specific number whose finite log is desired.^{[14]} It turns out that much Internet traffic uses one of a handful of groups that are of order 1024 bits or less.^{[15]} By precomputing the first three steps of the number field sieve for the most common groups, an attacker need only carry out the last step, which is much less computationally expensive than the first three steps, to obtain a specific logarithm. The Logjam attack used this vulnerability to compromise a variety of Internet services that allowed the use of groups whose order was a 512bit prime number, so called export grade. The authors needed several thousand CPU cores for a week to precompute data for a single 512bit prime. Once that was done, however, individual logarithms could be solved in about a minute using two 18core Intel Xeon CPUs.^{[3]}
As estimated by the authors behind the Logjam attack, the much more difficult precomputation needed to solve the discrete log problem for a 1024bit prime would cost on the order of $100 million, well within the budget of large national intelligence agency such as the U.S. National Security Agency (NSA). The Logjam authors speculate that precomputation against widely reused 1024bit D–H primes is behind claims in leaked NSA documents that NSA is able to break much of current cryptography.^{[3]}
To avoid these vulnerabilities, authors recommend use of elliptic curve cryptography, for which no similar attack is known. Failing that, they recommend that the order, p, of the Diffie–Hellman group should be at least 2048 bits. They estimate that the precomputation required for a 2048bit prime is 10^{9} more difficult than for 1024bit primes.^{[3]}
If NSA is breaking Diffie–Hellman, but has not pushed for US sites to upgrade to longer keys, then it would be an example of NSA's NOBUS policy of not closing security holes that NSA believes only they can exploit.
Other uses
Encryption
Public key encryption schemes based on the Diffie–Hellman key exchange have been proposed. The first such scheme is the ElGamal encryption. A more modern variant is the Integrated Encryption Scheme.
Forward secrecy
Protocols that achieve forward secrecy generate new key pairs for each session and discard them at the end of the session. The Diffie–Hellman key exchange is a frequent choice for such protocols, because of its fast key generation.
Passwordauthenticated key agreement
When Alice and Bob share a password, they may use a passwordauthenticated key agreement (PK) form of Diffie–Hellman to prevent maninthemiddle attacks. One simple scheme is to compare the hash of s concatenated with the password calculated independently on both ends of channel. A feature of these schemes is that an attacker can only test one specific password on each iteration with the other party, and so the system provides good security with relatively weak passwords. This approach is described in ITUT Recommendation X.1035, which is used by the G.hn home networking standard.
An example of such a protocol is the Secure Remote Password Protocol.
Public key
It is also possible to use Diffie–Hellman as part of a public key infrastructure, allowing Bob to encrypt a message so that only Alice will be able to decrypt it, with no prior communication between them other than Bob having trusted knowledge of Alice's public key. Alice's public key is <math>(g^a \bmod{p}, g, p)</math>. To send her a message, Bob chooses a random b and then sends Alice <math>g^b \bmod p</math> (unencrypted) together with the message encrypted with symmetric key <math>(g^a)^b \bmod{p}</math>. Only Alice can determine the symmetric key and hence decrypt the message because only she has a (the private key). A preshared public key also prevents maninthemiddle attacks.
In practice, Diffie–Hellman is not used in this way, with RSA being the dominant public key algorithm. This is largely for historical and commercial reasons^{[citation needed]}, namely that RSA Security created a certificate authority for key signing that became Verisign. Diffie–Hellman cannot be used to sign certificates. However, the ElGamal and DSA signature algorithms are mathematically related to it, as well as MQV, STS and the IKE component of the IPsec protocol suite for securing Internet Protocol communications.
Notes
 ↑ Synonyms of Diffie–Hellman key exchange include:
 Diffie–Hellman–Merkle key exchange
 Diffie–Hellman key agreement
 Diffie–Hellman key establishment
 Diffie–Hellman key negotiation
 Exponential key exchange
 Diffie–Hellman protocol
 Diffie–Hellman handshake
References
General references
 Template:Cite book
 Template:Cite techreport
 Template:Cite techreport
 The History of NonSecret Encryption JH Ellis 1987 (28K PDF file) (HTML version)
 The First Ten Years of PublicKey Cryptography Whitfield Diffie, Proceedings of the IEEE, vol. 76, no. 5, May 1988, pp: 560–577 (1.9MB PDF file)
 Menezes, Alfred; van Oorschot, Paul; Vanstone, Scott (1997). Handbook of Applied Cryptography Boca Raton, Florida: CRC Press. Template:ISBN. (Available online)
 Singh, Simon (1999) The Code Book: the evolution of secrecy from Mary Queen of Scots to quantum cryptography New York: Doubleday Template:ISBN
 An Overview of Public Key Cryptography Martin E. Hellman, IEEE Communications Magazine, May 2002, pp:42–49. (123kB PDF file)
External links
 Oral history interview with Martin Hellman, Charles Babbage Institute, University of Minnesota. Leading cryptography scholar Martin Hellman discusses the circumstances and fundamental insights of his invention of public key cryptography with collaborators Whitfield Diffie and Ralph Merkle at Stanford University in the mid1970s.
 RFC 2631 – Diffie–Hellman Key Agreement Method. E. Rescorla. June 1999.
 RFC 3526 – More Modular Exponential (MODP) DiffieHellman groups for Internet Key Exchange (IKE). T. Kivinen, M. Kojo, SSH Communications Security. May 2003.
 Summary of ANSI X9.42: Agreement of Symmetric Keys Using Discrete Logarithm Cryptography (64K PDF file) (Description of ANSI 9 Standards)
 Diffie–Hellman Key Exchange – A NonMathematician’s Explanation by Keith Palmgren
 Crypt::DH Perl module from CPAN
 Handson Diffie–Hellman demonstration
 C implementation using GNU Multiple Precision Arithmetic Library
 Diffie Hellman in 2 lines of Perl (using dc)
 Smart Account Management (SAcct) (using DH key exchange to derive session key)
 DiffieHellman Key Exchange  A YouTube video by Khan Academy faculty member Brit Cruise
 Talk by Martin Hellman in 2007, YouTube video
 Crypto dream team Diffie & Hellman wins $1M 2015 Turing Award (a.k.a. "Nobel Prize of Computing")
Template:Portal Template:Cryptography navbox
 ↑ Template:Cite journal
 ↑ ^{2.0} ^{2.1} Template:Cite journal
 ↑ ^{3.0} ^{3.1} ^{3.2} ^{3.3} ^{3.4} Adrian, David; Bhargavan, Karthikeyan; Durumeric, Zakir; Gaudry, Pierrick; Green, Matthew; Halderman, J. Alex; Heninger, Nadia; Springall, Drew et al. (October 2015). "Imperfect Forward Secrecy: How DiffieHellman Fails in Practice". https://weakdh.org/imperfectforwardsecrecyccs15.pdf.
 ↑ Ellis, J. H. (January 1970). "The possibility of NonSecret digital encryption". CESG Research Report. http://cryptocellar.web.cern.ch/cryptocellar/cesg/possnse.pdf.
 ↑ "GCHQ trio recognised for key to secure shopping online". 5 October 2010. http://www.bbc.co.uk/news/ukenglandgloucestershire11475101. Retrieved 5 August 2014.
 ↑ Template:Cite patent
 ↑ Template:Citation
 ↑ "Imperfect Forward Secrecy: How DiffieHellman Fails in Practice". https://weakdh.org/imperfectforwardsecrecyccs15.pdf. Retrieved 30 October 2015.
 ↑ Template:Citation
 ↑ Template:Citation
 ↑ Template:Citation
 ↑ Template:Cite conference
 ↑ C. Kaufman (Microsoft) (December 2005). "RFC 4306 Internet Key Exchange (IKEv2) Protocol". Internet Engineering Task Force (IETF). http://www.ietf.org/rfc/rfc4306.txt.
 ↑ Whitfield Diffie, Paul C. Van Oorschot, and Michael J. Wiener "Authentication and Authenticated Key Exchanges", in Designs, Codes and Cryptography, 2, 107125 (1992), Section 5.2, available as Appendix B to Template:US patent
 ↑ https://weakdh.org/imperfectforwardsecrecyccs15.pdf