# ECIES for encrypting ECDH key exchange

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.

• Could you link the other posts here on Cryptography.stackexchange that doesn't satisfies you? Did you read Wikipedia page on IES that contains DLIES and ECIES?. ECIES is already a hybrid scheme so that ECDH is used than symmetric encryption is performed with the exchanged result is used in a KDF. Aug 27, 2020 at 16:08
• Aug 27, 2020 at 16:16
• Yes, I know that it is related with that question... But... ECIES include ECDH? On wikipedia I can't get that.
– PRVS
Aug 27, 2020 at 16:21
• ECDH means Elliptic-Curve Diffie-Hellman (Key Exchange). ECIES means use ECDH then symmetric encryption (hybrid encryption). DL in DLEIS is used for classic DHKE where the multiplicative group is used. Aug 27, 2020 at 16:32
• @AleksanderRas I've decided to revert my decision to see it as a dupe as this is specifically about authentication, and I didn't see a good way of integrating that into the other answer without altering the question. Aug 27, 2020 at 19:31

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).

• Only one more question @Maarten Bodewes, so, if ECDH is used by ECIES, it means that I do not need to use ECIES and ECDH, I can only use ECIES? So, ECIES is secure against man-in-the-middle? Or for this I need the versions of the DH key agreement that allow authentication?
– PRVS
Sep 10, 2020 at 12:09
• For ECIES you generally use a static key pair of the receiver and ephemeral key pair of the sender. The public key of the static key pair of the receiver needs to be trusted or you might be encrypting for the wrong entity. To also make sure that the message is integer / authentic and to trust that the right entity is sending you the message, you would have to sign the plaintext before encryption, e.g. using ECDSA and - of course - a separate key pair of the sender for which the receiver trusts the public key. Sep 10, 2020 at 15:29
• You could use an authenticated cipher within ECIES to disallow changes / provide message integrity, but note that an attacker could still block the entire message and replace it with a different one. Sep 10, 2020 at 15:33
• yeah. i'm basically trying to understand if ECIES works as something like part of TLS handshake where, when a server sends the public key to a browser, the browser creates a Symmetric session key and encrypts it with server's public-key, then send it to the server. Now Server decrypts the encrypted Symmetric session key using the asymmetric private key to get the symmetric session key. But for my understanding, ECIES or cannot be secure against MiTM "alone".
– PRVS
Sep 11, 2020 at 7:56
• ECIES is not a transport protocol in itself. In that sense, MiTM is off topic for it. The best way to think of ECIES is RSA encryption. It uses rather different techniques but the key management and security offered are the same. Sep 12, 2020 at 9:24