ECCDH: direct or with temporary ECC keypairs?

Question

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.

Answer 1

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.

Answer 2

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.