# Can I apply "encrypt with public key and decrypt with private key concept" using ECC certificate?

If Alice wants to send encrypted message to Bob, she can use Bob's public key to encrypt the plain message. Once Bob reliably gets encrypted message, he can decrypt it with his private key. In this process, Bob will never have to know anything about Alice (assuming message is not tampered). In other words, Alice does not need her own public/private key pair. Further this process can be easily achieved by Bob's RSA certificate and Alice does not have to have any RSA certificate. I also understand that this is following asymmetric algorithm (i.e. using PKI).

How does this encryption and decryption process change if Bob has ECC certificate only?

I have reviewed Integrated Encryption Scheme (https://en.wikipedia.org/wiki/Integrated_Encryption_Scheme). As far as I can tell, both DLIES and ECIES seem to suggest deriving a key (using key agreement protocol), then encrypt and decrypt messages using that key, which is essentially a symmetric algorithm.

1. Does not this mean both Alice and Bob need each other's ECC public key?

2. If so, this process appears to differ when RSA certificate is used. Am I correct?

3. Does this mean Alice now needs her own ECC certificate because she needs to send her public key to Bob along with encrypted message so that Bob can successfully decrypt it using Alice's public key and his private key?

You are right that (EC)IES essentially consists of a Diffie-Hellman key agreement and authenticated symmetric encryption, but the protocol flow is different. In particular, IES is a "one-shot" public-key encryption scheme: Assuming that Alice knows Bob's public key beforehand, she can encrypt a message for Bob "offline" without any interaction, just like with RSA.

In summary, ECIES consists of the following steps:

1. Assume Alice knows Bob's public key $Y=[y]P$.
2. Alice generates a random private key $x$ and computes $[x]Y$.
3. She derives a symmetric key $k$ from $[x]Y$.
4. Using some authenticated symmetric encryption algorithm, she encrypts her message using $k$ as the key, yielding a ciphertext $c$.
5. She transmits the pair $([x]P,c)$ to Bob.

1. No, in IES the receiver (Bob) does not need Alice's long-term public key because she generates a fresh ephemeral key pair (whose public part is transmitted as part of the ciphertext) for each message. In fact, Alice does not even need to have a long-term key to be able to encrypt messages for Bob! This is in line with the general public key encryption setting: Everybody can encrypt, only Bob can decrypt.

2.: Yes, the encryption procedure for RSA is different from IES. But the protocol flow is not! Both are public-key encryption schemes.

3. No, according to 1.

• In step [4.], the use of authenticated encryption is pointless. It only gives a false impression of security, when really nothing is authenticated: an adversary with Bob's public key can perform just as Alice. For short messages, XOR of the message with $k$ will do.
– fgrieu
Nov 5, 2017 at 14:20
• @fgrieu Without authentication, an attacker can manipulate (e.g. flip bits in) the encrypted message without knowing the plaintext — this is something they could not have done by simply replacing the ciphertext. (Here is an example.) Nov 5, 2017 at 14:30
• OK, I remove pointless. Indeed, if the short ciphertext is known to be of the form "16-octet-password ∥ URL" with URL but not password known, then authenticated encryption prevents active adversary Eve from altering URL to some server under her control, get the password in that way, and then impersonate Bob w.r.t. the rightful server; authenticated encryption indeed helps here! I should have said: In step [4.], the use of authenticated encryption does not provide authentication of the message.
– fgrieu
Nov 5, 2017 at 14:50
• yyyyyyy: If I understand you correctly, you are saying that Alice has to send her public key (ephemeral or not) to Bob so that he can decrypt the text. Correct? Nov 6, 2017 at 4:22
• @Raghu Yes, it's considered to be part of the ciphertext. Nov 6, 2017 at 12:47