# ECIES for not shared encryption

I am using ECIES (Cryptobox as poncho pointed out) for public key encryption with ECC between Alice and Bob with secret/public keys $(a,A)$ and $(b,B)$ respectively. So Alice encrypts to Bob with

$$Encrypt(aB,Message)$$

Additionally I would like to encrypt some of Alice's data such that only she can decrypt it. Is it safe to use ECIES to compute a shared secret from Alice's secret and public key as in

$$Encrypt(aA,Message)$$

I know I could randomly generate a public key, but then I would have to store this key somewhere which I would like to avoid.

Yes, however I believe that the reason is a bit subtler than what fgrieu gave.

From your question, I don't believe that you're actually doing standard ECIES, but instead something such as NaCl's cryptobox (which is a variant).

With standard ECIES, to encrypt to the public key $A$, the encryptor selects a random value $r$, and generates the ciphertext:

$$rG, \text{Encrypt}( rA, \text{Message} )$$

In contrast, with Cryptobox, Bob doesn't select a random value, instead, he uses his own private key. That is, to encrypt to Alice's public key $A$, he will take his private key $b$, and produce [1]:

$$\text{Encrypt}( bA, \text{Message} )$$

This is effectively ECIES (with the $bG$ value implicit; that's Bob's public key). As Bob's private key is random (independent of Alice's keys), this is secure as long as standard ECIES is secure [2].

However, this raises the question: what if Alice encrypts to herself? Will that remain secure? That would not immediately follow from the security of ECIES, as Alice's private key is not a random value independent of Alice's public key.

In this specific case, it turns out to be secure. Specifically, the problem of "given $G, aG$, compute $(a^2)G$" (which is needed to decrypt Alice's message to herself) is just as hard as the general problem "given $G, aG, bG$, compute $(ab)G$". That is, given a way to solve one, you can solve the other.

[1]: Actually, I believe Bob includes a nonce to make the encryption nondetermanistic; that's not important for this explination

[2]: Actually, we need to assume that this construction doesn't leak information about Bob's private key, and that ECIES is secure even if you repeat the same random value; that's actually the case.

• Have you tried a career as a mentalist? When I see ECIES, I assume ECIES with per-message random value $r$. How you guessed the right context is remarkable. Unless there's some subliminal channel.. – fgrieu Jan 24 '18 at 16:41
• @fgrieu: read the OP's last line "I know I could randomly generate a public key, but then I would have to store this key somewhere which I would like to avoid"; that objection doesn't make sense with standard ECIES; it makes perfect sense with Cryptobox... – poncho Jan 24 '18 at 17:59