An effective cybersecurity policy incorporates modern cryptography for secure data transmission. Encrypting data protects sensitive information during communication exchange so that only those authorized to decrypt that data can access it. Without encryption, all data transmitted over the public internet is at risk of interception and nefarious reuse. Encryption helps prevent stolen data through a variety of tools, including cryptographic ciphers like the Diffie-Hellman key exchange.
This article provides a brief overview of how the Diffie-Hellman key exchange functions for encryption over a public communication channel, identifies potential risk exposure when using Diffie-Hellman primes, and outlines three solutions to secure your use of the Diffie-Hellman algorithm.
What is Cryptographic Key Exchange?
In cryptography, key exchange refers to the process through which encryption keys are exchanged between two or more parties. The key enables each party to encrypt messages they wish to send and decrypt messages they have received.
Encryption provides a layer of security between your data and potential attackers. Complex encryption algorithms protect the data from potential decryption by brute force attacks that can guess the encryption key. There are a number of cipher suites available with variable components. Encryption standards are constantly changing, but using a variety of the tools available for Public Key Infrastructure, such as asymmetric and symmetric key encryption, can help you maintain a strong cybersecurity posture.
Asymmetric encryption relies on a key pair (a public key and a private key), where the public key encrypts the data and the private key decrypts it. The message or data is called the plaintext. After being encrypted by a key, it is referred to as ciphertext. Asymmetric key encryption is foundational for SSL/TLS protocols that provide secure communications over HTTPS.
With symmetric key encryption, the sender and the recipient use a single identical key to decrypt messages. Diffie-Hellman key exchange is one of the most commonly used symmetric encryption methods used in public key cryptography.
Diffie-Hellman Key Exchange
The Diffie-Hellman key exchange algorithm is a method for agreeing to and calculating a secret symmetric key between parties on an insecure channel or public network. Keys can be ephemeral (used for a single session), static (long-term), or a combination of the two (semi-static). It is named for Whitfield Diffie and Martin Hellman, who published their collaboration on public-key algorithms in 1976. Hellman has suggested renaming it Diffie-Hellman-Merkle key exchange to include Ralph Merkle's contributions.
Diffie-Hellman key exchange typically combines a public variable and modulo operator with two private variables to result in a shared symmetric cipher key. Diffie-Hellman key exchange uses large prime numbers to calculate the keys. The exchange requires agreement on an initial prime and a modulo operator so that the computation for key agreement will be consistent between both parties, despite not exchanging secret information over public channels.
With Diffie-Hellman key exchange, the two parties agree to a shared public variable (the generator) of some integer value and a modulus, which is typically a large prime of 2000 or 4000 bits. Each party has their own private variable (sometimes called a private key) that will provide an exponent function. Though these variables are sometimes referred to as public and private keys, it is important to note that Diffie-Hellman is not asymmetric key encryption but rather a method for calculating a shared symmetric key through exponentiation.
Each party will take the public variable to the power of their private variable, running the modulo operation to achieve a numerical result, then exchange the result. Once each party has received the public variable to the power of the sender's private variable, they take that result to the power of their own private variable and run the modulo operation, which calculates to the same final result for both parties. The result of this calculation is the shared secret key.
Because the shared secret key requires both the public variable that is exchanged and the private variables that are not exchanged, it becomes more difficult for an attacker to determine the shared secret key as it is computationally difficult to take the root of an equation and the attacker does not have access to either party's private variable outright. When the modulus is exceptionally large, the modulo operation becomes extremely difficult to crack. The Diffie-Hellman use of large prime numbers makes discrete logarithm computation difficult, which is why Diffie-Hellman is often deployed as part of a cipher suite.
However, there are limitations as Diffie-Hellman key exchange does not require authentication between parties. For example, the Logjam vulnerability (CVE-2015-4000) enables an attacker to downgrade a secure connection and apply logjam precomputation for known primes used in 512-bit and 1024-bit implementations. When you determine your cipher suites and select the cryptographic algorithm, ensure that you have balanced any limitations among components.
Diffie-Hellman Risk Findings
The Diffie-Hellman algorithm provides a method for determining a secret number that is relatively simple to achieve and computationally difficult to crack. There are still some risks involved in using Diffie-Hellman, particularly if the prime is weak or common.
You can also use an automated scanning tool that accounts for the necessary data to ensure that you can quickly identify any weak links in the encryption standards for your external assets. UpGuard BreachSight provides continuous monitoring and automated scanning for potential threats, including known vulnerabilities related to Diffie-Hellman key exchange:
- Weak Diffie-Hellman prime used in key exchange
- Common Diffie-Hellman prime used in key exchange
Small key sizes and predictable primes can allow attackers to break the Diffie-Hellman cipher key. Some Diffie-Hellman keys use the same common primes. Previous vulnerabilities, like the logjam vulnerability, have allowed attackers to break these known primes, which can lead to passive listening by unauthorized agents and man-in-the-middle attacks (also known as person-in-the-middle attacks). UpGuard also scans for the Logjam vulnerability with the Vulnerable to CVE-2015-4000 (Logjam) finding.
To prevent a weak prime, ensure that you use primes that are at least least 2048-bit or greater. You can also switch to Elliptic-Curve Diffie-Hellman Ephemeral (ECDHE) key exchange, which uses the Diffie-Hellman protocol with ephemeral keys and elliptic-curve cryptography.
In addition to the two Diffie-Hellman findings, UpGuard also evaluates weak or insecure SSL/TLS and cipher suites to ensure that your website deploys strong cybersecurity measures. To understand how UpGuard evaluates these findings, read our article on weak SSL.
How UpGuard Can Help
Current UpGuard users can log in and access their Risk Profile to search for Diffie-Hellman key exchange findings among their assets. If you're not a current UpGuard user and you want to run an automated scan of your assets with BreachSight, sign up for a trial.
When you have identified an encryption risk among your assets, you can set up security measures to remedy the issue so that users remain protected when accessing your website.
How to Implement Diffie-Hellman Key Exchange for SSL/TLS Encryption
Diffie-Hellman key exchange is beneficial for encryption over public networks. To ensure that your use of Diffie-Hellman provides necessary security precautions, you can deploy the Diffie-Hellman exchange for Transport Layer Security (TLS) with the following three recommendations.
Disable Export Cipher Suites
Export cipher suites are low-strength encryption cipher suites that can introduce downgrade attacks on TLS connections. Export cipher suites are weak by design and should be removed unless explicitly required due to regulatory needs.
Deploy Elliptic-Curve Diffie-Hellman Ephemeral (ECDHE)
Elliptic-curve cryptography uses elliptic curves over finite fields to help generate the encryption key. By using temporary, ephemeral keys for Diffie-Hellman key exchange, each encryption exchange will require a new key rather than static key reuse. ECDHE encryption also adds an elliptic curve to the discrete logarithm problem, increasing the complexity of the problem while lowering the bit threshold for the same level of security. ECDHE also enables the option for perfect forward secrecy. Most browsers prefer Elliptic-Curve Diffie-Hellman (ECDH) key exchange over finite field Diffie-Hellman.
Use a Strong Diffie-Hellman Group
To prevent precomputation and potential eavesdroppers, use a strong Diffie-Hellman group of at least 2048-bits or greater. Most modern web browsers, including Google Chrome, Mozilla Firefox, and Microsoft Internet Explorer, require a group size of at least 1024 bits for Diffie-Hellman public-key encryption, and the computation becomes harder to crack with larger bit sizes.
To ensure that your server uses strong ECDHE parameters, implement Mozilla's recommended cipher suites when you configure your server. Mozilla's Server Side TLS provides a guide to configuration and recommended cipher suites for security. You can use the SSL Configuration Generator to generate configuration code according to your server and environment needs.
Some server software providers also offer advisories for deployment:
- Microsoft Internet Information Services (IIS): Updated Support for Diffie-Hellman Key Exchange
- Amazon Elastic Load Balancing: Predefined SSL security policies for Classic Load Balancers
For other software, use the appropriate configuration file to make any changes:
- Apache HTTP Server: [.rt-script]httpd.conf[.rt-script] or for specific virtual hosts found in the [.rt-script]/etc/apache2/sites-available/[.rt-script] directory
- Apache Tomcat: [.rt-script]server.xml[.rt-script]
- Dovecot: [.rt-script]/etc/dovecot.conf[.rt-script]
- HAProxy: [.rt-script]/etc/haproxy/haproxy.cfg[.rt-script]
- Lighttpd: [.rt-script]/etc/lighttpd/lighttpd.conf[.rt-script]
- Nginx: the server block held in the [.rt-script]/etc/nginx/sites-enabled/default[.rt-script] directory
- Postfix SMTP: [.rt-script]/etc/postfix/main.cf[.rt-script]
- Sendmail: [.rt-script]/etc/mail/sendmail.mc[.rt-script]
Once you have implemented your updated configuration settings, you can augment your use of Diffie-Hellman with other cryptographic tools, such as digital signatures for authentication. For example, you might use ECDHE-RSA certificates so the RSA algorithm can authenticate the source of the message.
