Deploy360 22 October 2015

Diffie-Hellman Key Exchange Problems & Recommendations for Stronger Encryption

By Kevin MeynellFormer Senior Manager, Technical and Operational Engagement

TLS badgeA paper recently published at the 22nd ACM Conference on Computer and Communications Security in Denver, USA raises concerns about how Diffie-Hellman key exchange is implemented in many protocols including HTTPS, SSH, IPsec, SMTPS and other protocols relying on TLS. Diffie-Hellman is an asymmetric cryptographic algorithm that is commonly used to exchange session keys when establishing a secure Internet connection, but the research discovered that many server implementations are either using obsolete 512-bit so-called ‘export grade’ cryptography or are utilising a fixed or limited range of prime numbers that effectively allows 768-bit and potentially 1024-bit grade encryption to be routinely cracked using pre-computation techniques.

Tests revealed that up to 15% of servers could potentially be affected using the Logjam attack technique that forces export grade parameters (a historical legacy) for Diffie-Hellman. Whereas if 1024-bit grade encryption is broken, this could potentially compromise up to 25% of HTTPS and SSH servers and 66% of IPSec VPN connections.

The authors point out that the cracking of 1024-bit grade encryption still requires substantive amounts of computing resources that are likely only available at a nation state level, but that moving to stronger key exchange methods should be a priority for the Internet community. They make the following three recommendations:

  1. Turn off legacy export cipher suites which in any case are no longer supported by most modern browsers;
  2. Deploy Elliptic-Curve Diffie-Hellman (ECDHE) which avoids all known feasible cryptanalytic attacks;
  3. Generate 2048-bit or stronger Diffie-Hellman groups with “safe” primes.

There’s a useful page of resources to be found at https://weakdh.org which includes a Guide to Deploying Diffie-Hellman for TLS, along with a tool for testing servers.

More information on configuring web browsers and operating systems can be found in this EFF article, whilst the authors of the paper discuss the implications of their findings in this blog post.

You can also visit our TLS for Applications page to learn more about security protocols.

Disclaimer: Viewpoints expressed in this post are those of the author and may or may not reflect official Internet Society positions.

Related Posts

Improving Technical Security 15 March 2019

DNS Privacy Frequently Asked Questions (FAQ)

We previously posted about how the DNS does not inherently employ any mechanisms to provide confidentiality for DNS transactions,...

Improving Technical Security 14 March 2019

Introduction to DNS Privacy

Almost every time we use an Internet application, it starts with a DNS (Domain Name System) transaction to map...

Improving Technical Security 13 March 2019

IPv6 Security for IPv4 Engineers

It is often argued that IPv4 practices should be forgotten when deploying IPv6, as after all IPv6 is a...