Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I just read about ECDH and while getting a overview over the process, I noticed that this key exchange method does neither provide any forward secrecy, nor does it protect against replay-attacks, because the shared secret will be the same for each session. Are there any common methods that extend ECDH to support these security features?

share|improve this question
up vote 11 down vote accepted

To get Perfect Forward Secrecy, you have to use ephemeral keys.

With static Diffie-Hellman (elliptic curve or not, that's not the issue), Alice and Bob both own a DH key pair: Alice's private key is a, public key is aG (elliptic curve notation, G is the conventional "base point" for the curve); Bob's private key is b, public key is bG. When Alice and Bob want to talk to each other, they do the DH thing, which means that they end up with the shared secret value abG. They always have this exact shared secret. If an attacker manages to steals Alice's private key (a), then he can recompute the shared secret, and thus decrypt all past and future conversations between Alice and Bob.

Ephemeral Diffie-Hellman is about generating DH key pairs "on the fly" and not recording private keys anywhere (the private keys are kept in RAM only, and for the duration of the conversation only). Never being recorded ought to make these private keys immune from ulterior theft; that's where PFS comes from. This is used in SSL/TLS with the "DHE" (and "ECDHE") cipher suites: the server owns a private/public key pair, with the public key being in a certificate, and fit for signatures (e.g. that key pair is of type RSA or DSA). When a client connects, both client and server generates new DH key pairs; the server signs his newly generated DH public key with its signature key (the client verifies that signature and validates the server certificate). The key which is actually used to encrypt the data is the one derived from the Diffie-Hellman algorithm.

With DHE cipher suites, should the server's private key be stolen, then the thief only gains the power to compute forged signatures. The thief may then impersonate the server and endanger future communications by running a Man-in-the-Middle attack, but past connections were encrypted with regards to DH keys which have long been lost, and thus won't be decrypted by the attacker. That's PFS.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.