ECDHE (Elliptic Curve Diffie–Hellman Ephemeral) and TLS Handshake with ECDHE - Explained
ECDHE (Elliptic Curve Diffie–Hellman Ephemeral)
1. Overview
ECDHE (Elliptic Curve Diffie–Hellman Ephemeral) is a key exchange mechanism used in modern secure communication protocols such as TLS (HTTPS).
It allows two parties (for example, a browser and a web server) to:
Establish a shared secret key
Over an untrusted network
Without directly transmitting the secret
ECDHE is a variant of the Diffie–Hellman key exchange that uses elliptic curve cryptography and temporary (ephemeral) keys for each session. (CardLogix Corporation)
2. Breaking down the name
Elliptic Curve (EC)
Instead of using traditional modular arithmetic (as in classic Diffie–Hellman), ECDHE uses:
Points on an elliptic curve
Mathematical operations over those points
This provides:
Strong security with smaller key sizes
Faster computations compared to traditional Diffie–Hellman
Diffie–Hellman (DH)
Diffie–Hellman is a method where:
Both parties contribute to key generation
Neither side sends the final secret directly
Both independently compute the same shared secret
Ephemeral (E)
This is the most important part for security.
Ephemeral means:
New key pairs are generated for every session
Keys are discarded after use
So:
No long-term reuse of the same key
No persistent key material exposed across sessions
3. How ECDHE works (step-by-step)
Assume two parties: Client (C) and Server (S)
Step 1: Agree on parameters
They agree on:
A specific elliptic curve (public)
A base point on that curve (public)
Step 2: Generate temporary key pairs
Each side generates a one-time key pair:
Client:
Private key:
aPublic key:
A = a × G
Server:
Private key:
bPublic key:
B = b × G
Where G is the base point.
Step 3: Exchange public keys
Client sends
Ato serverServer sends
Bto client
These are not secret
Step 4: Compute shared secret
Each side computes:
Client computes:
a × BServer computes:
b × A
Because of elliptic curve math:
a × B = a × (b × G) = b × (a × G) = b × A
So both arrive at the same shared secret.
Step 5: Derive session keys
The shared secret is passed through a key derivation function (KDF) to produce:
Symmetric encryption keys (e.g., AES keys)
MAC keys / AEAD keys
4. Why ECDHE is secure
ECDHE security relies on the difficulty of the:
Elliptic Curve Discrete Logarithm Problem (ECDLP)
Meaning:
Even if an attacker sees
AandBThey cannot compute the shared secret efficiently
5. The key advantage: Forward Secrecy
Because ECDHE uses ephemeral keys, it provides:
🔐 Forward Secrecy
If a server’s long-term private key is compromised in the future:
Past encrypted sessions still cannot be decrypted
Why?
Each session used a unique temporary key
Those keys are deleted after the session ends
This property is one of the main reasons modern TLS prefers ECDHE.
Forward secrecy is achieved specifically because session keys are independent of long-term private keys. (ScienceDirect)
6. ECDHE in TLS (real-world use)
In HTTPS connections:
Browser and server perform ECDHE during the TLS handshake
They derive a shared secret
Then switch to fast symmetric encryption (AES-GCM / ChaCha20)
This is why modern cipher suites include names like:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
Here:
ECDHE = key exchange
RSA = authentication (signing)
AES-GCM = encryption
7. ECDHE vs ECDH (important distinction)
| Feature | ECDH | ECDHE |
|---|---|---|
| Key type | Static or long-term | Temporary per session |
| Forward secrecy | ❌ No | ✅ Yes |
| Security risk if key leaks | Past sessions exposed | Past sessions safe |
| Usage in TLS | Rare | Standard |
8. Summary
ECDHE is:
A secure key exchange protocol
Based on elliptic curve cryptography
Uses temporary keys per session
Used in TLS (HTTPS)
Provides forward secrecy
Efficient and widely deployed in modern systems
TLS Handshake with ECDHE
Client Hello
Browser connects to server and sends supported TLS versions, cipher suites, and a random value.
Server Hello
Server chooses the TLS version and ECDHE cipher suite.
Sends its certificate (for identity) and its ECDHE public key.
Key exchange
Client generates its own temporary ECDHE key pair.
Client sends its ECDHE public key to the server.
Shared secret creation
Both sides independently compute the same shared secret using ECDHE math.
Session key generation
The shared secret is used to derive symmetric encryption keys (e.g., AES keys).
Finished messages
Both sides verify that encryption is working and handshake is complete.
Secure communication starts
All data is now encrypted using fast symmetric encryption.
Key idea
ECDHE is used only to securely agree on a shared secret, after which fast symmetric encryption is used for the actual data transfer.
Comments
Post a Comment