Ephemeral Diffie-Hellman (ECDH) key agreement is surprisingly not about establishing a long-term secret key; it’s about generating a fresh, unique key for each individual communication session.
Imagine you’re setting up a secret handshake with someone new every single time you meet. That’s effectively what ephemeral ECDH does for your data. Instead of using a single, permanent secret code that, if compromised, reveals all past and future conversations, you generate a brand-new, one-time-use secret code for each interaction. This makes your communication significantly more secure against future compromises.
Let’s see this in action. We’ll use OpenSSL to generate the necessary keys and perform the key exchange.
First, a client generates its ephemeral private and public keys. The curve choice is crucial here; secp256r1 (also known as P-256) is a common and secure choice.
# Client generates its ephemeral private key
openssl ecparam -genkey -name secp256r1 -out client_ephemeral.key
# Client extracts its public key from the private key
openssl ec -in client_ephemeral.key -pubout -out client_ephemeral.pub
The client_ephemeral.key file now contains the client’s private key, and client_ephemeral.pub contains its public key. This public key would then be sent to the server.
The server, upon receiving the client’s public key, uses its own ephemeral private key (generated similarly) to compute a shared secret.
# Server generates its ephemeral private key
openssl ecparam -genkey -name secp256r1 -out server_ephemeral.key
# Server extracts its public key
openssl ecparam -in server_ephemeral.key -pubout -out server_ephemeral.pub
# Server computes the shared secret using its private key and the client's public key
openssl pkeyutl -derive -inkey server_ephemeral.key -pubin -peer public -import -infile client_ephemeral.pub -outfile shared_secret.bin
The server_ephemeral.pub file would be sent back to the client. The client then uses its own private key and the server’s public key to compute the exact same shared secret.
# Client computes the shared secret using its private key and the server's public key
openssl pkeyutl -derive -inkey client_ephemeral.key -pubin -peer public -import -infile server_ephemeral.pub -outfile shared_secret.bin
Now, both the client and the server have the shared_secret.bin file containing the same 32-byte (256-bit) secret. This secret can then be used as a symmetric encryption key (e.g., for AES-GCM). The ephemeral keys (client_ephemeral.key, client_ephemeral.pub, server_ephemeral.key, server_ephemeral.pub) are discarded after the session is established.
The core problem ephemeral ECDH solves is Forward Secrecy. If an attacker somehow obtains your long-term private key (e.g., a server’s TLS private key), they can decrypt all past and future communications secured with that key. With ephemeral ECDH, even if they compromise the long-term key, they cannot decrypt past sessions because the keys used for those sessions were generated on-the-fly and discarded. The ephemeral private keys are never stored and are unique to each session. This significantly raises the bar for attackers.
The security of ECDH hinges on the mathematical difficulty of the Elliptic Curve Discrete Logarithm Problem (ECDLP). Unlike traditional Diffie-Hellman, ECDH offers equivalent security with much smaller key sizes, leading to better performance and reduced bandwidth. For example, a 256-bit ECC key provides roughly the same security as a 3072-bit RSA key. The choice of curve is critical; common, well-vetted curves like secp256r1, secp384r1, or secp521r1 are recommended. Avoid custom or obscure curves, as their security properties might not be well-understood.
When implementing ephemeral ECDH, it’s crucial to ensure that the ephemeral private keys are truly discarded after use and are never logged or stored. The process of deriving the shared secret involves modular arithmetic on the elliptic curve. Each party performs a calculation: SharedSecret = PrivateKey * PeerPublicKey (mod EllipticCurveParameters). Because the shared secret is derived using the peer’s public key, and the peer uses your public key to derive the same secret, the result is identical for both parties. The ephemeral public keys themselves are transmitted in the clear, but they are useless without the corresponding ephemeral private key.
The next step after establishing a shared secret using ECDH is typically to derive a session key for symmetric encryption, often using a Key Derivation Function (KDF) like HKDF.