Cryptography
elliptic-curves diffie-hellman key-exchange
Updated Sat, 10 Sep 2022 00:00:58 GMT

ECCDH: direct or with temporary ECC keypairs?


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.




Solution

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.





Comments (5)

  • +1 – Incredible detailed reply, thank you very much kind sir. Will continue to read up on the various topics mentioned. — Aug 10, 2022 at 14:45  
  • +1 – Good luck. I recommend this series of three blog posts. — Aug 10, 2022 at 15:08  
  • +2 – 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. — Aug 11, 2022 at 10:26  
  • +0 – "Make sure you include the sender's and recipient's public key in the key derivation." --> This is essentially a summary of the method described above, correct? I mean, this happens in step 2 and 3, correct? — Aug 15, 2022 at 11:01  
  • +1 – @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. — Aug 16, 2022 at 07:43