1
$\begingroup$

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.

$\endgroup$
3
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ 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.. $\endgroup$ – fgrieu Jan 24 '18 at 16:41
  • 1
    $\begingroup$ @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... $\endgroup$ – poncho Jan 24 '18 at 17:59

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.