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.