Spartak - Fotolia

Problem solve Get help with specific problems with your technologies, process and projects.

Analyzing the integrity of the Diffie-Hellman key exchange

New research has cast doubt on the security of the Diffie-Hellman key exchange method. Expert Michael Cobb explains if enterprises should be concerned.

Earlier this year SearchSecurity looked at the Logjam vulnerability, a flaw in the TLS protocol relating to the...

Diffie-Hellman key exchange method. The flaw allows Internet protocols to agree on a shared secret key during the negotiation phase of a secure connection, which can then be used to encrypt subsequent communications. The Logjam attack allows a man-in-the-middle attacker to downgrade the encryption used in a vulnerable TLS connection and read and modify any data passed over it. The attack is similar in some ways to the FREAK attack, but it targets the Diffie-Hellman key exchange rather than an RSA key exchange. The research paper, titled Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice, describes the Logjam vulnerability, discusses several weaknesses in how the Diffie-Hellman key exchange has been deployed and asserts that it is less secure than widely believed.

Diffie-Hellman is not dead yet, but administrators should make sure TLS libraries are up to date and enable the more secure Elliptic-Curve Diffie-Hellman algorithm.

Much of today's secure communications over the Internet depend on a Diffie-Hellman key exchange. To make the exchange process more efficient, Modular Exponential Diffie-Hellman groups -- pregenerated prime numbers -- are used to generate or initialize the Diffie-Hellman parameters. The security of the final shared secret key depends on the size of these parameters. It turns out that a small number of the same fixed or standardized groups are used by millions of servers. This makes it worthwhile for an attacker to spend time and resources attacking them due to the vast numbers of potential targets. The researchers estimate that performing precomputation to break the single, most common 1024-bit prime would allow passive eavesdropping on 18% of popular HTTPS sites, and a second prime would allow decryption of traffic to 66% of IPsec VPNs and 26% of SSH servers. The researchers concluded that any Diffie-Hellman group smaller than 1024-bits should not be used, as even non-nation state attackers could obtain the resources needed to break them.

However, shortly after the release of the paper, Paul Wouters, a founding member at the Libreswan VPN software project, challenged the researchers' estimates of the number of vulnerable servers, claiming the findings were inflated. So, who is right and is the revered Diffie-Hellman algorithm reaching the end of its useful life?

Wouters does not dispute that the Logjam vulnerability is exploitable; it can be found in the Common Vulnerabilities and Exposures list with the CVE Identifier CVE-2015-4000. However, following his own research, he disputes how many servers are possibly affected and puts the potential success rate of a hypothetical National Security Agency attack against Diffie-Hellman much lower than the original estimate.

Whatever the number of potentially vulnerable servers actually is, both pieces of research show there is not enough collaboration or understanding between cryptographers and those that implement cryptographic algorithms in real-world hardware and software. There needs to be more oversight in how approved encryption algorithms are actually incorporated into hardware and software, otherwise IT systems will continually be put at risk though poor implementation. It's encouraging to see that the IETF's Using TLS in Applications working group will offer common guidelines and best practices for using TLS 1.3 in applications, such as the use of the latest crypto algorithms and eliminating the use of older TLS/SSL versions, as well as guidance on how certain applications should use the encryption protocol. Vendors also need to make it easier and provide more support for administrators and users to change the configuration of their systems should a set or combination of algorithms come under attack or if their security is questioned.

Diffie-Hellman is not dead yet, but administrators should make sure TLS libraries are up to date and enable the more secure Elliptic-Curve Diffie-Hellman algorithm; OpenSSL has added protection against the Logjam attack in version 1.0.2b and 1.0.1n. Run KeyCDN's free TLS vulnerability check to find out if any sites or services are vulnerable against the Logjam attack. Administrators are also advised to generate a unique 2048-bit strength Diffie-Hellman group for key exchange to prevent precomputation by hackers looking to launch the Logjam attack. Those who use SSH should upgrade both server and client installations to the most recent version of OpenSSH, which prefers Elliptic-Curve Diffie-Hellman Key Exchange. The researchers who discovered Logjam have a webpage offering further guidance on how to strengthen affected servers.

Next Steps

Read more on the Logjam vulnerability and how it crimps TLS encryption

Find out how Diffie-Hellman compares to RSA's key exchange algorithms

Learn about the differences between symmetric and asymmetric encryption algorithms

This was last published in December 2015

Dig Deeper on Disk and file encryption tools