2
$\begingroup$

as the title says, for example, A uses B's public key to encrypt a message and sent it to B. In later stages, a new member C joins and B would like to let C be able to see this encrypted message (i.e., give the decryption ability to C). How to achieve this without letting A encrypt the message again using C's public key?

One way I can think of now is that B decrypts the message first and uses C's public key to encrypt it again and then send it to C. But is there any method that requires fewer operations to share the decryption ability to C more kind of automatically? Thanks.

$\endgroup$
3
  • $\begingroup$ See crypto.stackexchange.com/questions/86483/… $\endgroup$ Commented Mar 30, 2022 at 2:24
  • $\begingroup$ Thanks @EugeneStyer. But my problem here is to let others joined later whose public keys are not used at the beginning be able to read the message as well, which is a little bit different from this question where the requirement is to encrypt the message using mutiple recipient's public keys. $\endgroup$
    – Leo
    Commented Mar 30, 2022 at 3:50
  • $\begingroup$ The reason I linked to that particular question is to note that with hybrid encryption, we encrypt the message once using AES (or similar)., and then use public encryption to send the AES key. So adding another recipient just means encrypting the AES key using the new recipient's public key. The fact that this occurs later doesn't make much difference. $\endgroup$ Commented Mar 30, 2022 at 14:24

1 Answer 1

0
$\begingroup$

If you want C to be able to decrypt anything addressed to B, then the simplest thing is to simply give B's decryption key to C.

There is also something called proxy re-encryption that is also in the spirit of "re-addressing" a ciphertext. In proxy re-encryption, there is an algorithm $\textsf{ProxyKey}(sk_B, pk_C) \to rk_{B\to C}$: it takes B's private key and C's public key as input, and generates a re-encryption key $rk_{B \to C}$. Whoever has this re-encryption key can do $\textsf{ReEncrypt}(rk_{B \to C}, ctxt) \to ctxt'$, which takes a ciphertext $ctxt$ addressed to $B$ and transforms it into $ctxt'$, an encryption of the same thing but addressed to $C$.

(There are also variants where $\textsf{ProxyKey}$ needs the private key of both parties.)

The important distinction here is that the person who "re-addresses" the ciphertext (the "proxy") can be someone other than B or C. A proxy who only has $rk_{B\to C}$ but who doesn't know B or C's private keys can't open ciphertexts addressed to B or C. They can only transform ciphertexts for B into ciphertexts for C (and not vice-versa) without looking inside. Assuming the proxy and C are distinct parties, then C can only read messages addressed to B that the proxy chooses to transform.

$\endgroup$
4
  • $\begingroup$ Thank you @Mikero. B's private key cannot be given to C in my case so the simplest way cannot work here. The proxy re-encryption sounds interesting. But after the proxy uses the re-encryption key rkB-C to re-encrypt the ctxt to get ctxt' and send it to C, how can C decrypt ctxt'? Is it using C's private key? $\endgroup$
    – Leo
    Commented Mar 30, 2022 at 3:43
  • $\begingroup$ Yes, ctxt' would typically look like a normal ciphertext addressed directly to C, and would be decrypted in the usual way. $\endgroup$
    – Mikero
    Commented Mar 30, 2022 at 4:05
  • $\begingroup$ Sounds great. I will search and try first. Thank you @Mikero. I found a library that looks good github.com/nucypher/pyUmbral. Just wondering do you have recommended ones? $\endgroup$
    – Leo
    Commented Mar 30, 2022 at 4:11
  • $\begingroup$ @Leo Can you provide an example how you achieved the above using pyUmbral library $\endgroup$ Commented Mar 23, 2023 at 19:39

Your Answer

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

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