Score:2

How to share decryption ability to others whose public keys are not used during encryption?

br flag
Leo

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.

Eugene Styer avatar
dz flag
See https://crypto.stackexchange.com/questions/86483/using-public-key-cryptography-with-multiple-recipients
Leo avatar
br flag
Leo
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.
Eugene Styer avatar
dz flag
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.
Score:0
us flag

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.

Narayan Prusty avatar
td flag
@Leo Can you provide an example how you achieved the above using pyUmbral library
Leo avatar
br flag
Leo
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?
us flag
Yes, ctxt' would typically look like a normal ciphertext addressed directly to C, and would be decrypted in the usual way.
Leo avatar
br flag
Leo
Sounds great. I will search and try first. Thank you @Mikero. I found a library that looks good https://github.com/nucypher/pyUmbral. Just wondering do you have recommended ones?
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.