The Diffie–Hellman protocol is a cryptographic protocol that allows parties to generate a shared secret cryptographic key by exchanging data over an insecure channel. The resulting key can be used to both encrypt and decrypt messages by means of symmetric algorithms.
The Diffie–Hellman method solves one of the main problems of symmetric encryption — secure key transmission. The protocol is named after U.S. cryptographers Whitfield Diffie and Martin Hellman, who were the first to publish a working algorithm for public key exchange over a network. The scheme they proposed is applied in many encrypted communication standards and software, such as Gnu Privacy Guard (GnuPG, GPG), VPN protocols, SSH, TLS, etc.
How Diffie–Hellman works
At the heart of the protocol is the concept of partial key exchange, formulated by US cryptographer Ralph Merkle and implemented by Diffie and Hellman in the form of a cryptographic algorithm with a public key. Under this scheme, each party to the exchange:
- Generates a random natural number — their private key;
- Agrees with the remote party on the public parameters to be used to create a secret key;
- Computes the public key based on the private key and the public parameters;
- Exchanges public keys with the remote party;
- Computes the shared secret key using the remote party’s public key, their own private key, and the public parameters.
The Diffie–Hellman method can be applied to any number of exchange parties, not just two. To obtain the shared secret key, all parties to the exchange take turns computing keys using the common public parameters, public keys received from other parties, and their respective private keys.
Diffie–Hellman implementations
Depending on the lifetime of the private keys, there are two options for implementing the Diffie–Hellman protocol:
- The static variant uses long-term private keys that are not changed when the connection is terminated.
- The ephemeral (DHE) variant generates private keys for each new connection.
Diffie–Hellman weaknesses
The Diffie–Hellman method does not provide for authentication of the exchange parties or the negotiated key, which makes it vulnerable to man-in-the-middle attacks. An attacker can infiltrate the communication channel and intercept or spoof protocol messages. As a result, the parties establish a secure connection not with each other, but with the attacker, who is able to read their correspondence without them knowing.