0
$\begingroup$

I wonder what are the practical differences between using Authenticated Encryption and then ECIES. It looks like both require communicating the shared secret in some fashion between the parties and both provide encryption and authentication.

To make a concrete example, consider we have a party A, which receives messages {x1, x2, ..., xn} from various other parties, but needs to read the sender from the message itself, because upon receiving a message x, A doesn't know the sender otherwise. Using some AEAD scheme, A could have in an authenticated part the sender in plain text, consequently allowing A to choose the shared secret which to use to authenticate and decrypt the the message it received.

Can ECIES do this and if so, what is the practical difference? If not, well, what could be the purpose of ECIES? There seem to dearth of information on ECIES.

Improve this question
$\endgroup$

1 Answer 1

Reset to default
2
$\begingroup$

I wonder what are the practical differences between using Authenticated Encryption and then ECIES. It looks like both require communicating the shared secret in some fashion between the parties and both provide encryption and authentication.

ECIES is a specific hybrid encryption scheme using elliptic curve cryptography to enable EC based encryption - that is: encryption using the static public key of the receiver and decryption using the static private key of the receiver.

AEAD is a description of an interface for symmetric encryption with authentication.

ECIES depends on a asymmetric key pair (where the public key is trusted) and AEAD depends on a single symmetric key, which needs to remain secret. ECIES is a specific construct to perform encryption using Elliptic curves, AEAD is a description of an interface for authenticated ciphers. In such, it doesn't make much sense to compare the two.

To make a concrete example, consider we have a party A, which receives messages {x1, x2, ..., xn} from various other parties, but needs to read the sender from the message itself, because upon receiving a message x A doesn't know the sender. Using some AEAD scheme, A could have a plain-text part in each x telling the sender in an authenticated part and hence would need which shared secret to choose to open the actual message.

You wouldn't really need to authenticate the key identifier; if you'd change the key identifier then the authentication tag is already invalid, as you would use the wrong key to authenticate the ciphertext. You'd only need it if the scheme reuses the key for multiple senders that trust each other (not a common scenario). If this is for transport authentication you'd generally just keep track of a session.

Can ECIES do this and if so, what is the practical difference? If not, well, what could be the purpose of ECIES? There seem to dearth of information on ECIES.

No, ECIES just performs encryption, and as anybody has the public key, anybody can create a valid ciphertext. It doesn't If you want to add such functionality, you should sign the data, and then encrypt the plaintext and signature.

If you're talking about real time communication between a sender and receiver then you'd just use a transport protocol such as TLS. TLS 1.3 requires AEAD but since there already is a key establishment scheme based on DH, ECIES isn't used.

Improve this answer
$\endgroup$
3
  • $\begingroup$ "The plaintext will of course come out garbled, but that would be too late."; that's not correct; with AEAD, if the authentication tag doesn't check out, no decryption is generated. Of course, anyone with the secret key can put anything they want into the AAD; if multiple parties use the same secret key, you need to assume that they won't pretend to be the others (because you don't have a way to detect it if they do). And if each has their own secret key, why do they need to list the identity in the authenticated data? $\endgroup$
    – poncho
    Jul 31, 2016 at 17:57
  • $\begingroup$ @poncho To exaggerate for the sake of making the idea more clear, if there are a billion parties each having shared their secret key with A, it would be much more efficient for A if it could upon receiving message x choose the correct shared key (without trying until one-by-one to find one that works). No real-time usage. Not too deep thinking, but I was thinking something like storing and reading messages offline. The party could sign the data with public key crypto before AEAD, I believe, to mitigate some problems (if this makes sense, I didn't have clear goals to what to achieve). $\endgroup$
    – Veksi
    Jul 31, 2016 at 19:23
  • $\begingroup$ @Veksi: normally, if there are more than one party you share keys with, then included with the encrypted message is some value that indicates who it is from; you take that id and look up in the database to find the key, you then use the key to decrypt the data. If the decryption worked, it must be from that party (or, at least, someone who knows the key). $\endgroup$
    – poncho
    Jul 31, 2016 at 20:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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