# Proxy Re-Encryption Scheme for Decentralized Storage Networks
## 4 Proxy Re-Encryption Scheme
### Features  
**Collusion resilience.** Collusion resilience (collusion safe) states that the proxy and the delegate ([PERSON]) can collude to obtain the delegator's ([PERSON]) secret key. In BB598 [5],\(rk_{A\to B}=\frac{sk_{B}}{sk_{A}}\), proxy and delegate ([PERSON]) can calculate \(sk_{A}=rk_{A\to B}\cdot sk_{B}\). Collusion resilience (collusion safe) is an important feature. In any case, \(sk_{A}\) should be safe because it is related to more than the current ciphertext. All the ciphertexts generated by Alice are bound with the security of \(sk_{A}\). Our scheme is collusion resilience due to the novel method of re-key generation, inspired by the bidirectional scheme of [PERSON] and [PERSON] [16].  
**Bidirectional.** Delegation from \(A\to B\) allows re-encryption from \(B\to A\). It is observed that unidirectional and bidirectional delegation can be applied in different use cases. It is nice to distinguish between unidirectional and bidirectional proxy re-encryption. The bidirectional PRE refers to the fact that it can generate \(rk_{B\to A}\) from \(rk_{A\to B}\). WDLC10 [7] used the two layers for unidirectional encryption, where layer 2 cipher can be converted into layer 1 cipher by \(rk_{A\to B}=\frac{\Delta}{sk_{A1}+sk_{A2}}\).  
The bidirectional scheme means the re-encrypted ciphertext can transfer back to the original cipher. It depends on how the re-encryption key is designed. In BBS98, \(rk_{A\to B}=\frac{sk_{B}}{sk_{A}}\) and the reversed key \(rk_{B\to A}=\frac{sk_{A}}{sk_{B}}\) can be easily calculated. Obviously, this reversed encryption key can be applied to all the ciphertext generated by [PERSON]. In the [PERSON] and [PERSON] 2003 bidirectional ElGamal scheme, \(rk=g^{r(x_{2}-x_{1})}\) also can be reversed, but due to the random \(r\), the reversed key can be only applied to [PERSON]'s current ciphertext. Comparing the two scenarios, BBS98's bidirectional feature leads to more privacy issues than [PERSON] and [PERSON] [16].  
**Noninteractive.** The generation of the re-encryption key requires [PERSON] to use [PERSON]'s public key. [PERSON] is not involved in the interaction of re-key generation.  
**Proxy invisibility.** The user sending messages to [PERSON] does not need to be aware of the existence of the proxy. The same applies to [PERSON], the delegate.  
**Key optimality.** [PERSON] should keep a constant number of secrets, regardless of how many delegations he accepts.  
**Nontransitive.** A proxy re-encryption scheme is transitive if the proxy has right to re-delegate decryption permission. Moreover, it combines several re-encryption keys to produce a new re-key (e.g., from \(rk_{A\to B}\) and \(rk_{B\to C}\) one can obtain \(rk_{A\to C}\)). Our scheme is nontransitive, as generating a re-key requires [PERSON]'s authorization to prevent transitive action on a proxy.  
**Transferability.** This property, first considered by [PERSON] et al. in [18], catches the inability of collusion of the proxy and the delegates to re-delegate decryption rights (i.e., producing new re-encryption keys). The proxy has \(rk\) and [PERSON] knows \(g^{\prime}\) and \(sk_{B}\), which can generate a new re-key for another user.