Diffie-Hellman key exchange
Diffie-Hellman key exchange method — allows two or more parties to negotiate a secret encryption key without transferring it, or any data that might lead to it, over the network.
In this article the data transferred over the network is in blue color, the secret data that never leaves the party is in red.
First, parties MUST agree on a pair of public keys, typically abbreviated as p and g.
Where p — stands for Prime and MUST be a prime number,
and g — goes for Generator and MUST be a Primitive root modulo p.
Each party generates its own random private secret number n which must be greater than 1 and less than p.
Both sides calculate hash for public exchange using gn mod p formula. The same formula is used to calculate the shared secret where other party’s hash is used as generator (g).
There are no way to reverse calculate the value of n from the formula result. The fact that g is primary root modulo p means that for any value from 1 till p - 1 put in place of n the formula will yield different result, what means that it would take an eavesdropper (the spying party) up to p attempts to brute-force the secret value. Whereas nowadays (January 2020) the recommended size of p is — 2048 bits, a number that in decimal representation could take up to 617 digits. For a comparison the number to describe a total number of atoms of the entire universe would fit in 83 digits according to universetoday.com.
At the end the entire exchange method, assuming there are two parties and their private keys abbreviated as a and be b, looks like this:
The practical example
As a practical example let’s assume there is Alice and Bob who need to negotiate a shared secret key, and there is Eve who’s spying to their conversation. Obviously, for the sake of simplicity we are not going to use 617 digits long p.
-
Alice and Bob agree to use public keys p = 23 and g = 5
-
Alice generates random private secret number a = 6, and sends to Bob a has of it A, which is ga mod p, in this example 56 mod 23 = 8
-
Bob generates random private secret number b = 13, and sends to Alice a has of it B, which is gb mod p, in this example 513 mod 23 = 21
-
Alice calculates shared secret s, which is s = Ba mod P, in this example 216 mod 23 = 18
-
Bob calculates shared secret s, which is s = Ab mod P, in this example 813 mod 23 = 18
As result
-
Alice knows: p = 23, g = 5, A = 8, B = 21, a = 6, s = 18
-
Bob knows: p = 23, g = 5, A = 8, B = 21, b = 13, s = 18
-
Eve knows: p = 23, g = 5, A = 8, B = 21,
Both parties never shared a private secret numbers and ended up with the same shared secret key. The data that Eve got, gives her no clue about the shared secret, except that it can be any value greater than 1 and less than 23.
About key size
Various resources talk about key size, however the term itself is not explicitly mentioned in official RFC. The best clarification I found was by Xian Mu. He describes two key sizes in DH:
- discrete log group size — goes for p.
- discrete log key size — goes for private secrets, like a and b.
Actual key size recommendations for today can be found at keylength.com
Real world use
Since its publication in 1976 till nowadays it grew up to de facto standard in a shared key negotiation. The most popular protocols such as SSH2 and TLS are using DH to negotiate symmetric encryption key, whereas asymmetric encryption (SSH keys and X.509 certificates) is used for server identity verification.
In august 2018 — TLS 1.3 was released, where the RSA key exchange was kicked out in favor of DH.
In March 2016 — Whitfield Diffie and Martin Hellman received ACM A.M. Turing Award for revolutionizing internet security and becoming a real pain in the ass for NSA.