How are Secret keys exchanged through insecure networks?

In the previous post, we learned about the combination of symmetric keys (used for session data encryption) and asymmetric keys (often used for distributing those session keys securely).

But is there a method that allows two parties to agree on a secret key without sending that key over a public channel?

In this article, we will explore the Diffie–Hellman (DH) algorithm and how DH addresses key exchange's challenges in real-world scenarios.

Why isn’t the Asymmetric key good enough?

Forward Secrecy

Forward secrecy ensures that if a long-term private key is compromised at any point, past communications remain secure. If a man-in-the-middle(MitM) attacker records your encrypted traffic now and later obtains your RSA private key (through a hack or leak), they can decrypt all previously recorded sessions.

Separation of Authentication and Key Agreement

By separating the process of authenticating a party (e.g., proving a server’s identity with a certificate) from the process of deriving a session key, we reduce overall cryptographic risk. A flaw in key transport doesn’t automatically break authentication, and vice versa.

How the Diffie Hellman algorithm works

Diffie–Hellman (DH) key exchange is a mathematical technique that lets two parties securely establish a shared secret over an insecure channel. It was introduced by Whitfield Diffie and Martin Hellman in 1976.

The Diffie-Hellman key exchange allows two parties to agree on a shared secret key without delivering that key. Below is a typical simplified scenario:

Agreeing on Common Parameters

• Alice and Bob publicly agree on two numbers: A large prime number P. A generator G is a primitive root modulo P.
• These two numbers can be shared openly. An eavesdropper can see them.

Generating Private and Public Values

• Alice chooses a private random number 'a' known only to herself. She calculates her public value: A = G ^ a mod P.
• Bob chooses a private random number 'b' known only to himself. He calculates his public value: B = G ^ b mod P.
• Alice and Bob share public values through the public network.

Deriving the Shared Secret

• Alice computes secret s = B ^ a mod P = (G ^ b) ^ a mod P = (G ^ ba) mod P
• Bob computes secret s = A ^ b mod P = (G ^ a) ^ b mod P = (G ^ ab) mod P

Because ab=ba, both results are the same, Alice and Bob end up with the same value s.

Why is it Secure?

Discrete Logarithm Problem

Although an eavesdropper (called Eve) can intercept?G ^ a mod P?and?G ^ b mod P?along with the known public parameters?P?and?G, recovering a or b is extremely difficult given a large enough P. This is known as the discrete logarithm problem.

Forward secrecy

In ephemeral Diffie–Hellman (often referred to as DHE), each session uses a unique, one-time (ephemeral) set of private/public DH values. Even if future attackers compromise a server’s long-term private key, they cannot retroactively decrypt previously recorded sessions.

What real-world use cases for Diffie–Hellman

Diffie-Hellman key exchange is commonly found in security protocols, such as Transport Layer Security (TLS), Secure Shell (SSH), and IP Security (IPsec).

• SSH: During the SSH handshake, a DH key exchange (e.g., diffie-hellman-group14-sha1) is commonly used so the client and server can securely derive a shared secret without ever sending the secret itself.
• SSL/TLS: In TLS 1.2+, the server’s certificate (signed by a trusted authority) validates the server’s identity, while DH secures the session key's negotiation. This combination provides both authentication (via the certificate) and forward secrecy (via ephemeral key exchange).
• VPNs: Many VPN protocols (such as those used in IPsec and OpenVPN) rely on DH to establish a secure tunnel between a client and a VPN server.

Key Takeaways

• Diffie–Hellman allows two devices to agree on a shared secret without sending the secret itself over public networks.
• It leverages the difficulty of the discrete logarithm problem, which makes it computationally infeasible for an attacker to derive the private values.
• Ephemeral DH is crucial for forward secrecy: each session uses fresh key material, protecting past sessions even if long-term keys are compromised.
• DH is foundational in widely used security protocols like SSH, TLS, and IPsec, ensuring private communication in everyday technologies.

References:

• https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange
• https://www.practicalnetworking.net/series/cryptography/diffie-hellman/
• https://info.support.huawei.com/info-finder/encyclopedia/en/SSH.html
• https://en.wikipedia.org/wiki/Discrete_logarithm