• $A$ wants to communicate with $B$
  • $A$ knows a public key $P_B$ which is trusted by a third party and belongs to $B$
  • $A$ knows the address of someone who pretends to be $B$

$A$ wants to send a message to $B$ using ECIES:

  1. $A$ calculates a random private key $K$ and the related public key $P$
  2. $A$ calculates a shared secret $Z$ using $K$ and $P_B$ according to ECIES
  3. $A$ derives symmetric keys from the shared secret $k_1|k_2=\text{KDF}(Z_x)$
  4. $A$ encrypts a message $c=\text{ENCRYPT}_{k_1}(m)$
  5. $A$ tags the encrypted message $t=\text{MAC}_{k_2}(c)$
  6. $A$ sends $P|c|t$ to someone who pretends to be $B$


  • Can $A$ assume, that only $B$ can read the message? I think so.
  • As $B$ does not know anything about $A$ what is the cryptographic purpose of the MAC? As $K$ and $P$ are message specific anyone who knows $P_B$ could have sent this message with a valid MAC to $B$!?
  • Does removal of the MAC step reduce ECIES' security? I assume, but I don't get why.

1 Answer 1


Can $A$ assume that only $B$ can read the message?

Only someone with the private key corresponding to $P_B$ can read the message. If $A$ can assume that only $B$ has it, that works.

As $B$ does not know anything about $A$ what is the cryptographic purpose of the MAC?

So that someone else cannot modify the encrypted message.

What we want to prevent is someone can take the encrypted message $E_{P_B}{m}$, and modify it so that it successfully decrypts into a message $m'$, where $m$ and $m'$ are related. Without the MAC, here is what someone might try:

  • Take the encrypted text $c = ENCRYPT_{k_1}(m)$

  • Replace it with a $c'$, that decrypts with $k_1$ into $m'$

  • Repackage it into $P|c'$ as the new encrypted message.

This is often feasible, because many encryption methods make modifying the encrypted message possible (even if you don't know the encryption key $k_1$). One example of this is counter mode; if you flip any bit of the encrypted message, and the corresponding bit of the decryption will also flip (with no other change).

Because of this, then without the MAC, Eve might be able to take the encrypted message:

$ENCRYPT( \text{ "Transfer one million into Bob's account, password Rhinosaurus" })$

and change that into

$ENCRYPT( \text{ "Transfer one million into Eve's account, password Rhinosaurus" })$

With the MAC, this type of message modification is infeasible.

So in this case with the MAC Eve can still send "valid" messages to $B$, but as long as Eve does not have the password ("Rhinosaurus") Eve has no way to execute or modify a transaction.

  • $\begingroup$ +1 of course. Maybe add padding oracle attacks in the mix - they also let you loose confidentiality and are thwarted by validating the MAC before unpadding. $\endgroup$
    – Maarten Bodewes
    Sep 4, 2014 at 13:32
  • $\begingroup$ If $B$ trusts $A$ and acts on $A$'s commands, than there would be a problem. But practically spoken with plain ECIES you always get a message from someone who you do not know. This is because the message is encrypted by a random key pair. So there is no way to ever trust the sending party. Simply put: even with the MAC anyone could have sent me a valid message. If you ever trust the sending party without further authentication, than the application is insecure by design. So is the MAC together with the random key just a nice theoretical feature without any practical use? $\endgroup$
    – tryagain
    Sep 4, 2014 at 14:08
  • 1
    $\begingroup$ @tryagain: look at the example I gave above; it is actually secure. Eve could not generate the message, because she doesn't know the password. Or, are you saying that ECIES should have been designed with a known weakness (message malleability) because that weakness is likely to be covered by how it is used? $\endgroup$
    – poncho
    Sep 4, 2014 at 14:28
  • 1
    $\begingroup$ @poncho: I would never say ECIES should have been designed in a different way. But Eve does not need to modify the message, because she can compose her own valid message as long as she knows $P_B$. I still don't get it. $\endgroup$
    – tryagain
    Sep 4, 2014 at 14:37
  • 3
    $\begingroup$ @tryagain: However, should could not compose "Transfer one million into Eve's account, password Rhinosaurus" if she doesn't know the password. That's the point of the example; by modifying the message, she doesn't have to know it. $\endgroup$
    – poncho
    Sep 4, 2014 at 14:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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