I am moving from RSA to ECC for my application.

Looking at these posts 1 2 3, they all suggest that Alice generates a temporary (ephemeral) ECC keypair eKP to send a message to Bob. The sessionkey sK is then generated at Alice' side as (privateKey eKP * publicKeyBob). The publicKey of eKP is transmitted along with the sK encrypted message. At Bob's side, he can calculate the same sessionkey sK as (publicKey eKP * privateKeyBob) and decrypt the message.

What I do not understand is why using a temporary (ephemeral) keypair eKP is better then just generating a session key sK directly from (privateKeyAlice*publicKeyBob).

Is it because we would re-use the same session key every time? Is it because we would have to pre-agree on seeds or initialization vectors for directly generated session keys, adding more interactions? Any other reasons?

Any insights greatly appreciated.


2 Answers 2


What I do not understand is why using a temporary (ephemeral) keypair eKP is better then just generating a session key sK directly from (publicKeyBob + privateKeyAlice).

  1. Only the recipient can decrypt messages because the sender's ephemeral private key is erased. This mitigates the issue of the sender's private key being compromised affecting the confidentiality of messages.
  2. A different shared secret is derived each time, which can help prevent cryptographic wear-out (using the same key too much) and nonce reuse.
  3. The identity of the sender is hidden. This can sometimes be desirable.

The trouble with the above, known as the Integrated Encryption Scheme (IES), is that an attacker may be able to replace the message with one of their choosing, and the recipient would be unaware.

You typically want to authenticate the sender. Therefore, I would recommend a stronger version of the authenticated key exchange you describe so you can still authenticate the sender whilst getting benefits 1 and 2. It goes like this:

  1. The sender generates an ephemeral key pair.
  2. The sender computes an ephemeral shared secret using their ephemeral private key and the recipient's long-term public key. The ephemeral private key is then erased from memory.
  3. The sender also computes a long-term shared secret using their long-term private key and the recipient's long-term public key.
  4. The sender concatenates the ephemeral shared secret and long-term shared secret to form the input keying material for a KDF. The output keying material is used as the key to encrypt a message using an AEAD.
  5. The sender's ephemeral public key is prepended to the ciphertext, and the ciphertext is sent to the recipient.
  6. The recipient reads the ephemeral public key, computes the ephemeral shared secret using their long-term private key and the sender's ephemeral public key, computes the long-term shared secret using their long-term private key and the sender's long-term public key, derives the encryption key using the same KDF, and decrypts the ciphertext.

Make sure you include the sender's and recipient's public key in the key derivation. Otherwise, with some algorithms, the same shared secret may be derived for multiple public keys, which affects sender authentication and can lead to vulnerabilities.

  • 1
    $\begingroup$ Incredible detailed reply, thank you very much kind sir. Will continue to read up on the various topics mentioned. $\endgroup$ Commented Aug 10, 2022 at 14:45
  • 1
    $\begingroup$ Good luck. I recommend this series of three blog posts. $\endgroup$ Commented Aug 10, 2022 at 15:08
  • 2
    $\begingroup$ Note that the issue with authentication is not limited to ECIES, it would also be an issue with any other unauthenticated encryption scheme such as RSA-OEAP. Session key generation in static-static DH can be randomized, if just by simply including a (public) random in the key derivation function - which should be performed after establishing the master secret. The shown authentication scheme would fit some protocols, but it might be that for others a (separate) signature scheme would be a better fit. $\endgroup$
    – Maarten Bodewes
    Commented Aug 11, 2022 at 10:26
  • 1
    $\begingroup$ @ThomasPaper Nope, have a look at the link. I mean including the public keys in step 4/6 (e.g. using the info parameter of the KDF). Multiple public keys may produce the same shared secret with those algorithms, so relying on the shared secret for sender authentication and so on doesn't work. It's a good idea to do this in all cases so it's never a problem. $\endgroup$ Commented Aug 16, 2022 at 7:43
  • 1
    $\begingroup$ Through the blog post series you mentioned i have found a reference to RFC7748 section 7, which mentions the following: "Designers using these curves should be aware that for each public key, there are several publicly computable public keys that are equivalent to it, i.e., they produce the same shared secrets." So that is why, in the KDF info field, also called info parameter, context material or public context, the author of the blog post includes all public keys (ephemeral and long-term keys). (Second part of the blog post series, step 5 in paragraph NIST One-Pass Unified Model). Thank you. $\endgroup$ Commented Nov 9, 2022 at 15:04

We usually talk about Diffie-Hellman keys (such as are used in elliptic curve cryptography) as coming in two flavours: static or ephemeral, where static keys are used in multiple exchanges for the medium to long term and ephemeral keys are used once in a single exchange for the short term.

The primary advantage of a static key is the owner does not have to be actively involved in the exchange at the point of use. It allows publication of keys before use in applications such as key chains. They also provide a measure of authentication linking previous messages to current messages.

The primary advantage of an ephemeral key is for forwards and backwards security. If the secret value associated with an ephemeral key is compromised, then this only compromises the shared key in which the ephemeral value was used. A compromised of a static key is much more wide-reaching. Your initial description is of a static-ephemeral key exchange. It's often used when a known authenticated Bob makes their contact details widely available (e.g. an open to web server) and is then contacted by an individual user Alice with no previous history with Bob (so that Bob cannot be assumed to possess Alice's public key).

Your alternative is a static-static scheme. It can be used when both parties have each others' public keys in advance (which is not always possible). As you also note, it will agree the same shared key every time. This is often a bad idea cryptographically-speaking and so some non-static information is desirable.

Modern key exchange protocols such as the Signal Protocol tend to use a mixture of both static and ephemeral keys in ways that combine the benefits of both at the cost of increased computation and bandwidth.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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