ECIES for encrypting ECDH key exchange

Question

I started studying Elliptic Curve Cryptography, and I do not know if I understand the difference between ECDH and ECIES (even with the other posts here on stackexchange).

I'm wondering if ECIES can be used to encrypt the ECDH key exchange to guarantee that it does not exist a man-in-the-middle. I'm thinking about this like TLS, where there is an asymmetric encryption before symmetric keys are exchanged.

In brief, something like:

Use ECIES to establish a secure client-server session and ECDH to generate the shared key to exchange information securely over the established secured session between server and client. In the Asymmetric Encryption Algorithm, the sender needs a Public key to encrypt the message, and the receiver need a Private Key to decrypt the message, while in Symmetric Encryption Algorithm, Both sender and receiver need single Symmetric session key to encrypt and decrypt data. This make sense? If not, please help me understand the difference between ECIES and ECDH and if ECDH has some authentication.

Answer 1

Elliptic Curve Integrated Encryption Scheme (ECIES) is a type of Integrated Encryption Scheme (IES) that uses Elliptic-Curve Diffie-Hellman (ECDH) key agreement to establish an ephemeral data key (rather than a session key) which is then used to encrypt data using a symmetric scheme. It uses an ephemeral key during the creation of the ciphertext, for which the public key is stored with the ciphertext. Usually, the receiver / decrypting entity has got a static key pair for which the public key needs to be trusted by the sender / encrypting entity.

ECIES can of course be used for authentication of the receiver: you could encrypt an ephemeral key using the data key, send it over, and if the other party is able to decrypt then you have authenticated the receiver. Of course, the receiver must still show that it now has the authentication key to e.g. create a MAC over a message known by both parties. In the case of TLS you would basically be replacing RSA_ ciphersuites that perform RSA encryption with ECIES_ ciphersuites that perform Elliptic Curve encryption.

That sounds great, but hold on: both parties now first have to establish an ephemeral data key, to encrypt an ephemeral authentication key. It would be much easier to simply use the data key for authentication. If you'd do that then you're back to Diffie-Hellman key agreement. So basically it would only be useful if normal DH key agreement can - for some reason or other - not be directly integrated in the protocol.

This is an explanation by example that differs from an earlier, more concise one given here. That one focuses on the session key derivation, this one is more about the possible entity authentication.

---

There are several versions of the DH key agreement that allow authentication. Most possible schemes are documented in NIST SP 800-56A Revision 3: "Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography", chapter 6.

Basically you need a static DH key to perform authentication which then can be performed by validating a MAC created using the derived key. So the "1S" scheme (S for Static) is able to authenticate one entity, and 2S schemes are able to authenticate both entities (I'll skip over multi-entity key agreement, for now, keeping it at a single pair).