*Article* **Proxy Re-Encryption Scheme for Decentralized Storage Networks**

**Jia Kan 1,2,†, Jie Zhang 1,†, Dawei Liu <sup>3</sup> and Xin Huang 2,\***


**Abstract:** Storage is a promising application for permission-less blockchains. Before blockchain, cloud storage was hosted by a trusted service provider. The centralized system controls the permission of the data access. In web3, users own their data. Data must be encrypted in a permission-less decentralized storage network, and the permission control should be pure cryptographic. Proxy re-encryption (PRE) is ideal for cryptographic access control, which allows a proxy to transfer Alice's ciphertext to Bob with Alice's authorization. The encrypted data are stored in several copies for redundancy in a permission-less decentralized storage network. The redundancy suffers from the outsourcing attack. The malicious resource provider may fetch the content from others and respond to the verifiers. This harms data integrity security. Thus, proof-of-replication (PoRep) must be applied to convince the user that the storage provider is using dedicated storage. PoRep is an expensive operation that encodes the original content into a replication. Existing PRE schemes cannot satisfy PoRep, as the cryptographic permission granting generates an extra ciphertext. A new ciphertext would result in several expensive replication operations. We searched most of the PRE schemes for the combination of the cryptographic methods to avoid transforming the ciphertext. Therefore, we propose a new PRE scheme. The proposed scheme does not require the proxy to transfer the ciphertext into a new one. It reduces the computation and operation time when allowing a new user to access a file. Furthermore, the PRE scheme is CCA (chosen-ciphertext attack) security and only needs one key pair.

**Keywords:** proxy re-encryption; blockchain; storage; proof-of-replication

#### **1. Introduction**

Blockchain technology has been actively developing in recent years. A decentralized storage network [1] based on the blockchain is a promising application direction. The decentralized storage network would redefine data ownership, privacy, and accessibility. Taking the example of the traffic surveillance cameras, the data may be stored on a decentralized storage network. Therefore, the public can verify that the data exist, but only authorized parties can access it. Multiple institutions (such as insurance companies) to access data require an encryption scheme with access control. Traditional symmetric or asymmetric cryptography cannot meet this requirement, as these schemes require specifying who can decrypt before encrypting. The proxy re-encryption (PRE) is a suitable scheme for data sharing.

PRE allows a user to grant access permission in a cryptographic method. Alice would allow Bob to visit her data under Alice's authorization. However, the ciphertext must be transferred to the new one (Figure 1). In a decentralized storage network, data integration suffers from the challenge of the outsourcing attack. Blockchain consists of many semitrusted resource providers. When asked for proof, the malicious provider would download

**Citation:** Kan, J.; Zhang, J.; Liu, D. ; Huang, X. Proxy Re-Encryption Scheme for Decentralized Storage Networks. *Appl. Sci.* **2022**, *12*, 4260. https://doi.org/10.3390/ app12094260

Academic Editor: Arcangelo Castiglione

Received: 14 March 2022 Accepted: 9 April 2022 Published: 22 April 2022

**Publisher's Note:** MDPI stays neutral with regard to jurisdictional claims in published maps and institutional affiliations.

**Copyright:** © 2022 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (https:// creativecommons.org/licenses/by/ 4.0/).

the data content from other honest providers on the fly. Proof-of-replication (PoRep) brings the concept against the outsourcing attack. The idea is to encode the user data with a unique key, e.g., the provider's public key. Meanwhile, the encoding algorithm should be expensive, and decoding is cheap, so the resource provider would not drop the replicated data, as regenerating the replication would cost more. Since everyone tends to reduce the cost, the data would lose redundancy without PoRep. PoRep is the mandatory algorithm to convenience the verifiers that the dedicating storage resource is spending.

Existing PRE is not ideal for a decentralized storage network because the extra ciphertext would trigger an expensive replicating operation (Figure 2). Combined with PoRep, the cost of PRE sharing is too high.

We propose a CCA (chosen ciphertext attack)-secure and collusion-resilience (collusion safe) proxy re-encryption scheme for the decentralized storage network (Figure 3).


**Figure 1.** Traditional PRE requires proxy computation to re-encrypt.

**Figure 2.** Comparison of the replication in decentralized storage network with or without transferred ciphertext.

The rest of the paper is organized as follows. In Section 2, we talk about the detail of decentralized storage networks and proxy re-encryption. In Section 3, we dive into the knowledge, terms, and formula used in this work. The proposed scheme and security analysis are presented in Section 4. In Section 5 we give a practical implementation and show the experiment result. The various extended questions are talked about in the evaluation, Section 6. Finally, Sections 7 and 8 provide the conclusion and future work.

#### **2. Related Work**

This section will dive deep into the background of the decentralized storage network, blockchain, and its relationship with proxy re-encryption.

#### *2.1. Decentralized Storage Network*

The cloud service is provided by a trusted third party. The data permission is controlled with a centralized mechanism. With the blockchain innovation, the recent study shows that the decentralized storage network is viable [1–4]. In the decentralized storage network, the user is not required to trust any providers, just the cryptography. It brings enormous confidence to the data owner.

The decentralized storage network is ideally built upon a permission-less blockchain. Blockchain miners provide the storage resource. The content that a user uploads to the blockchain is kept by miners. The blockchain makes the storage network permission-less. The miners can freely join or quit.

In the decentralized storage network, permission control must be cryptographic since the storage providers are semi-trusted. The existing public-key crypto is required to specify the target user to decrypt before encryption. Beyond this, PRE allows users to add the target users by re-encrypt the existing ciphertext into a new one. It is identical to permission granting at the application level. Thus, PRE schemes are helpful for blockchain storage.

However, a decentralized storage network must periodically check content integrity. The malicious miner may cheat by fetching content from other honest miners and responding to the checking. The cheater is committing to keep the content but never spending the storage resource. A decentralized storage network must be resilient to the outsourcing attack. Proof-of-replication requires the miners to encode the user content into the replication with each miner's unique identity. It is intended to make the encoding more expensive. The miner is willing to save the replication on disk, as it is impossible to fetch the content from other miners and finish the encoding in the limited time.

#### *2.2. Proxy Re-Encryption and Proof-of-Replication*

In 1998, Blaze, Bleumer, and Strauss [5] proposed the first proxy re-encryption scheme based on a cyclic group [6]. In 2010, Weng et al. [7] proposed a CCA and collusion-resilience PRE scheme. After 2010 [8,9], most PRE schemes were based on bilinear pairing [10–12] or lattice algebra structure [13]. The data uploaded must be encrypted in the decentralized storage network. However, most the PRE schemes are generating the new ciphertext during the re-encryption. A ciphertext would be replicated with each miners' unique identity. Any modification of the ciphertext would lead to more expensive PoRep operations. A PRE scheme is ideal not to generate new ciphertext during the frequent permission sharing actions under the decentralize storage network scenario. Thus, we propose the new PRE scheme.

While the new PRE schemes are diving into more complex algebra structure, the use scenarios of PRE are still limited. As business companies back the cloud service, the cloud and mobile do not fully utilize PRE schemes. The encryption will prevent data analysis and take extra cost of storage and computation. Owing to the blockchain, we foresee that blockchain-based decentralized applications will heavily rely on cryptographic schemes. Web3 allows the user to own their data. The decentralized storage network requires a pure cryptographic access control feature. PRE is ideal, but PoRep is mandatory.

The first blockchain, Bitcoin, proposed the proof-of-work (PoW) as the consensus algorithm [14] after PoW was used earlier for anti-spam purpose [15]. Computation was used as the resource for consensus, such as voting. Later, the storage space as a resource was studied, which can be classified into two categories. The proof-of-space intends to replace proof-of-work as the consensus algorithm. This replacement can bring down the cost of electricity by PoW, but junk data needs to be filled in the hard disk so far. Conversely, the proof-of-storage algorithm focuses on storing useful data. However, this algorithm cannot agree on a consensus. It only shows the proof of the data stored. Proof-of-replication is an extension of proof-of-storage, which convinces the owner that the unique storage resource keeps the data. In the permission-less blockchain, the PoRep is the key algorithm. It is nice to design schemes working with PoRep for the storage features. Filecoin uses SDR as the PoRep encoding and proves with the zero-knowledge-based algorithm [2,3]. Filecoin lets users decide how to encrypt their data. Therefore, there is no cryptographic access control for decentralized storage networks yet. The improved PRE scheme is worth studying.

In 1998, Blaze, Bleumer, and Strauss [5] proposed the first proxy re-encryption scheme. The ciphertext can be re-encrypted into another by the proxy authorized by the owner. Although the first PRE scheme is not collusion-resilient, it shows the possibility to change the key or password of the ciphertext without decryption. In 2003, Ivan and Dodis [16] proposed the group-based proxy cryptography scheme. In their unidirectional scheme, the secret key is first divided into two parts. This is the main technique that is used for collusion safety by many schemes. This illuminates our idea. In 2009, Shao et al. [17] proposed a CCA-secure scheme without pairing. Their scheme uses double trapdoors with the big prime multiplication as the secret key. One year later, Weng et al. [7] proposed a CCA-secure scheme WDLC10 without pairing. Two key pairs are used to avoid collusion for the secret key in their scheme, which is similar to Ivan and Dodis [16]. In the following years, most CCA-secure schemes were based on bilinear pairing or lattice. The PRE schemes such as AFGH06 [18] and GA07 [19] are based on bilinear pairing. XT10 [20] and ABPW13 [21] are based on lattice (LWE). NAL15a [22] is based on lattice (NTRU).

Let us take a look at how WDLC10 [7] works. To achieve collusion resilience, WDLC10 uses two key pairs. The core idea of preventing collusion is to use the sum of two secret keys instead of one. This results from the fact that the delegatee and proxy can only work together to obtain the sum of the keys, but cannot learn the value of each secret. The two keys are used for two different layers of ciphertext.

Our scheme achieved collusion resilience with one regular public/secret key pair. Under the general concept of asymmetry encryption, the cleartext can be encrypted with a public key, and the ciphertext is decrypted with the corresponding secret key. However, in the scenario of PRE, we slightly changed the definition. Assuming that anyone can create PRE ciphertext with the given public key, the malicious user could keep the crucial internal value which should be discarded during the encryption. The internal value can be used to generate new re-keys, where the access permission to the ciphertext should be controlled by the owner. In this case, the ciphertext generated with Alice's public key may not actually be controlled by Alice. This may lead to security issues. The proposed scheme

uses the secret key for encryption and decryption to ensure that only the owner can create the ciphertext. Alice can generate a re-key with her secret key and Bob's public key.

To summarize, BBS98 [5], Dodis and Ivan [16], and WDLC10 [7] use groups. WDLC10 [7] improved many features compared to BBS98 (including the most important feature, collusion resilience). To archive collusion resilience in "hashed" ElGamal, two key pairs are required for WDLC10 [7]. Shao et al. [17] used double trapdoors. For the other PRE schemes, most of them are based on bilinear pairing or lattice.

#### **3. Preliminaries**

We briefly talk about preliminary knowledge for the decentralized storage network and proxy re-encryption.

#### *3.1. Outsourcing Attack and Proof-of-Replication*

In a permission-less decentralized storage network, whoever joins the network can provide resources and make incoming attacks. The resource providers may make arbitrary attacks to reduce their costs and increase the margin. One of the most critical is the outsourcing attack. The solution to prevent outsourcing attacks is proof-of-replication [1].

The data must have redundancy stored in a permission-less decentralized storage network. An individual resource provider who deleted the local copy of data to save the storage cost makes an outsourcing attack. When the request to retrieve data comes, the resource provider can fetch the content from another provider and send it back to the requester. The data must be preprocessed into the replication format with the unique key to prevent the outsourcing attack. The cost of replication should be more expensive and time-costly than honestly storing the data. The replicated data are hard for another to utilize, as the replication key is unique. Proof-of-replication ensures the dedicating unique physical store for the data.

#### *3.2. Public Key Encryption*

Public key encryption has advantages in key management compared with symmetry key encryption. Users only need to keep their secret keys safe instead of memorizing many passwords. RSA and ElGamal (including ECC) are the most commonly used public key encryption schemes. In RSA, we can either encrypt with a public key or secret key and decrypt with the other, respectively. In ElGamal, the public key is for encryption via Equation (2), and the secret key is for decryption via Equation (3). Public key encryption allows anyone to create an encrypted message and send it to the secret key owner to establish secure communication. We mainly focus on ElGamal here:

$$a, r \in \mathbb{Z}\_{p\_r} \tag{1}$$

$$p k\_A = \text{g}^a.\tag{2}$$

$$sk\_A = a.\tag{3}$$

where *pkA* is the public key, and *skA* is the secret key. Ciphertext *c* is encrypted with the public key *pkA* and the clear message *m* via Equation (4):

$$
\mathcal{L} = \langle \mathbf{c}\_0, \mathbf{c}\_1 \rangle = \langle \mathbf{g}^r, m \cdot p k\_A^r \rangle = \langle \mathbf{g}^r, m \cdot \mathbf{g}^{ar} \rangle. \tag{4}
$$

The secret key is required for decryption via Equation (5):

$$m = \frac{\mathfrak{c}\_1}{(\mathfrak{c}\_0)^{sk\_A}} = \frac{m \cdot \mathfrak{g}^{ar}}{(\mathfrak{g}^r)^a}.\tag{5}$$

The ElGamal scheme satisfies the CPA security. Given the same input *m*, the output *c* is different each time according to the random value *r*. To achieve CCA security, validation is required before the decryption. It detects if the adversary had modified the ciphertext.

#### *3.3. Proxy Re-Encryption*

We review the model of collusion-resilience PRE. A CCA collusion-resilience proxy re-encryption scheme is an algorithm:

$$(KeyGen, \textit{RenKeyGen}, Enc, \textit{ReEnc}, Dec). \tag{6}$$

*KeyGen*(): The algorithm generates the public/secret key pair (*pk*,*sk*).

*ReKeyGen*(*skA*, *pkB*): The re-encryption key generation algorithm accepts the secret key *skA* of Alice and the public key *pkB* of Bob. It outputs a re-encryption key *rkA*→*B*.

*Enc*(*sk*, *m*): The encryption algorithm takes the public key *sk* and the clear message returns the encrypted message *c*.

*ReEnc*(*rkA*→*B*, *cA*): The re-encryption algorithm transfers the encrypted message *cA* into the ciphertext *cB* using the re-encryption key *rkA*→*B*. Bob's secret key can decrypt the transformed ciphertext *cB*.

*Dec*(*sk*, *c*): The user decrypts the ciphertext with his secret key and encrypted *c*, e.g., *cA* or *cB*. It outputs the cleartext *m*.

**Correctness.** Correctness is ensured for any *m* ∈ M and any key pair of (*pkA*,*skA*), (*pkB*,*skB*), following the conditions Equations (7) and (8):

$$\text{Dec}(sk\_{A\prime}Enc(sk\_{A\prime}m)) = m,\tag{7}$$

$$\operatorname{Dec}(\operatorname{sk}\_{\mathcal{B}}, \operatorname{ReEnc}(\operatorname{ReKeyGen}(\operatorname{sk}\_{\mathcal{A}\prime} \operatorname{pk}\_{\mathcal{B}}), \operatorname{Enc}(\operatorname{sk}\_{\mathcal{A}\prime} \operatorname{m}))) = \mathfrak{m}.\tag{8}$$

**Security definition.** Security for a CCA collusion-resilience PRE scheme is defined in the game between an adversary A and a challenger C. There are two ciphertexts from the cleartext message for the PRE scheme: encrypted cipher *m* → *cA* and re-encrypted *m* → *cB* are required for chosen-ciphertext security.

**Phase 1.** The adversary A issues queries *q*1, ... , *qm*, of which *qi* is one of the following:


**Challenge.** After the adversary A ends up Phase 1 , A chooses from two equal-length messages *m*0, *m*<sup>1</sup> ∈ M, and sends to the challenger C.

The challenger C receives *m*0, *m*1. C flips a random coin *δ* Equation (9), and computes *c*,

$$
\delta \leftarrow \{0, 1\},
\tag{9}
$$

$$x \leftarrow Enc(sk\_{A'}m\_{\delta}),\tag{10}$$

then sends the *c* Equation (10) back to the adversary A.

**Phase 2.** The adversary A continues to issue queries *qm*+1, ... , *qmax*, which *qi* can be one of the queries:

• Uncorrupted key generation query: The challenger C responses are the same as in Phase 1.


**Guess.** The adversary <sup>A</sup> outputs <sup>ˆ</sup> *δ* ∈ {0, 1}.

Referring to adversary A as an IND-PRE-CCA adversary, we define the advantage of the adversary A in attacking scheme Π as

$$\mathbf{Adv}^{IND-PRE-CCA}\_{\Pi, \mathcal{A}} = |\Pr[\delta = \hat{\delta}] - \frac{1}{2}|. \tag{11}$$

**Definition 1.** *A PRE scheme* Π *is said to be* (*t*, *qu*, *qc*, *qrk*, *qre*, *qd*, )*-IND-PRE-CCA secure, if for any t-time, IND-PRE-CCA adversary* A *makes at most qu uncorrupted key generation queries, at most qc corrupted key generation queries, at most qrk re-encryption key generation queries, at most qre re-encryption queries, and at most qd decryption queries; thus we have*

$$\mathbf{Adv}^{IND-PRE-CCA}\_{\Pi, \mathcal{A}} \le \mathfrak{e}.\tag{12}$$

*3.4. Complexity Assumptions*

The computational assumption of Diffie–Hellman (CDH) is defined as

**Definition 2.** G *is a cyclic multiplicative group with prime order p. The CDH problem is said in group* <sup>G</sup>*, given a tuple* (*g*, *<sup>g</sup>x*, *<sup>g</sup>y*) <sup>∈</sup> <sup>G</sup><sup>3</sup> *with unknown x*, *<sup>y</sup>* <sup>←</sup> <sup>Z</sup>*p, to compute gxy.*

A variant of the CDH problem named divisible computation Diffie–Hellman (DCDH) [23] problem is defined as follows.

**Definition 3.** *Let* G *be a cyclic multiplicative group with prime order p. The DCDH problem in group* G *is, given* (*g*, *g* 1 *<sup>x</sup>* , *<sup>g</sup>y*) <sup>∈</sup> <sup>G</sup><sup>3</sup> *with unknown x*, *<sup>y</sup>* <sup>←</sup> <sup>Z</sup>*p, to compute gxy.*

The construction of our chosen ciphertext-secure PRE scheme is based on the assumption of modified computational Diffie–Hellman (mCDH). The mCDH problem is a combination of the CDH problem and the DCDH problem.

**Definition 4.** *Let* G *be a cyclic multiplicative group with prime order p. The mCDH problem in group* G *is, given a tuple* (*g*, *g* 1 *<sup>x</sup>* , *<sup>g</sup>x*, *<sup>g</sup>y*) <sup>∈</sup> <sup>G</sup><sup>4</sup> *with unknown x*, *<sup>y</sup>* <sup>←</sup> <sup>Z</sup>*p, to compute gxy.*

**Definition 5.** *For a polynomial time adversary* B*, the advantage is defined as solving the mCDH problem in group* G*:*

$$\mathbf{Adv}\_{\mathcal{B}}^{mCDH} = \Pr[\mathcal{B}(\mathcal{g}, \mathcal{g}^{\frac{1}{x}}, \mathcal{g}^{x}, \mathcal{g}^{y}) = \mathcal{g}^{xy}].\tag{13}$$

#### **4. Proxy Re-Encryption Scheme**

Our PRE scheme is adopted with the PoRep in a permission-less decentralized storage network. The ciphertext *ReEnc* is an optional operation in the definition. This CCA and collusion-resilience PRE scheme is based on "hashed" ElGamal. ElGamal is one of the most important asymmetry cryptographic schemes based on CDH assumption. Both discrete logarithm and ECC can be used for the ElGamal implementation.

#### *4.1. Features*

**Collusion resilience.** Collusion resilience (collusion safe) states that the proxy and the delegate (Bob) can collude to obtain the delegator's (Alice) secret key. In BBS98 [5], *rkA*→*<sup>B</sup>* <sup>=</sup> *skB skA* , proxy and delegate (Bob) can calculate *skA* = *rkA*→*<sup>B</sup>* · *skB*. Collusion resilience (collusion safe) is an important feature. In any case, *skA* 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 *skA*. Our scheme is collusion resilience due to the novel method of re-key generation, inspired by the bidirectional scheme of Ivan and Dodis [16].

**Bidirectional.** Delegation from *A* → *B* allows re-encryption from *B* → *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 *rkB*→*<sup>A</sup>* from *rkA*→*B*. WDLC10 [7] used the two layers for unidirectional encryption, where layer 2 cipher can be converted into layer 1 cipher by *rkA*→*<sup>B</sup>* <sup>=</sup> <sup>Δ</sup> *skA*1+*skA*<sup>2</sup> .

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, *rkA*→*<sup>B</sup>* <sup>=</sup> *skB skA* and the reversed key *rkB*→*<sup>A</sup>* <sup>=</sup> *skA skB* can be easily calculated. Obviously, this reversed encryption key can be applied to all the ciphertext generated by Bob. In the Ivan and Dodis 2003 bidirectional ElGamal scheme, *rk* = *gr*(*x*2−*x*1) also can be reversed, but due to the random *r*, the reversed key can be only applied to Bob's current ciphertext. Comparing the two scenarios, BBS98's bidirectional feature leads to more privacy issues than Ivan and Dodis [16].

**Noninteractive.** The generation of the re-encryption key requires Alice to use Bob's public key. Bob is not involved in the interaction of re-key generation.

**Proxy invisibility.** The user sending messages to Alice does not need to be aware of the existence of the proxy. The same applies to Bob, the delegate.

**Key optimality.** Bob 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 *rkA*→*<sup>B</sup>* and *rkB*→*<sup>C</sup>* one can obtain *rkA*→*C*). Our scheme is nontransitive, as generating a re-key requires Alice's authorization to prevent transitive action on a proxy.

**Transferability.** This property, first considered by Ateniese 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 Bob knows *g<sup>r</sup>* and *skB*, which can generate a new re-key for another user.

#### *4.2. Proposed Scheme*

#### **Setup**

In the CCA-secure and collusion-resilience PRE scheme, *g* is the generator of a cyclic multiplicative group G of prime order *p*. *skA* Equation (16) is the secret key and *pkA* Equation (15) is the public key of Alice. *skB* Equation (18) is the secret key and *pkB* Equation (17) is the public key of Bob.

*m* is the clear message of *l*<sup>0</sup> bits length in the binary message space denoted by M. *<sup>w</sup>* is the random bits of *<sup>l</sup>*<sup>1</sup> length. *<sup>H</sup>* is the hash function, where *<sup>H</sup>*<sup>1</sup> : <sup>Z</sup>*<sup>p</sup>* · <sup>Z</sup>*<sup>p</sup>* <sup>→</sup> <sup>Z</sup>*p*, *<sup>H</sup>*<sup>2</sup> : {0, 1}*l*<sup>0</sup> · {0, 1}*l*<sup>1</sup> <sup>→</sup> <sup>Z</sup>*p*, *<sup>H</sup>*<sup>3</sup> : <sup>G</sup><sup>2</sup> → {0, 1}*l*0+*l*<sup>1</sup> , *<sup>H</sup>*<sup>4</sup> : <sup>G</sup> · {0, 1}*l*0+*l*<sup>1</sup> <sup>→</sup> <sup>Z</sup>*p*.

*KeyGen*(): The key generation algorithm generates the public/secret key pair (*pk*,*sk*) for the user:

$$a, b \in \mathbb{Z}\_{p\*} \tag{14}$$

$$p k\_A = \mathbb{g}^a,\tag{15}$$

$$isk\_A = a\_\prime\tag{16}$$

$$kp\_B = \mathbf{g}^b{}\_{\prime} \tag{17}$$

$$k\_B = b.\tag{18}$$

*ReKeyGen*(*skA*, *pkB*): The re-encryption-key-generating algorithm accepts the secret key *skA* from Alice and the public key *pkB* from Bob. The algorithm returns the reencryption key *rkA*→*B*.

Re-key *rkA*→*<sup>B</sup>* = ( *pkB pkA* )*<sup>d</sup>* = ( *<sup>g</sup><sup>b</sup> <sup>g</sup><sup>a</sup>* )*<sup>d</sup>* = *<sup>g</sup>bd*−*ad*, where the *pkA* can be derived from *skA*. When re-encrypting *DB* <sup>=</sup> *DA* ·*rkA*→*<sup>B</sup>* = (*ga*)*<sup>d</sup>* · *<sup>g</sup>bd*−*ad* <sup>=</sup> *<sup>g</sup>bd*, the re-key can only be issued by Alice, who knows *d* = *H*1(*skA*,*r*).

*Enc*(*skA*, *m*): The encryption algorithm takes the secret key *skA*, and the clear message *m* returns the encrypted message *cA* via Equation (19):

$$
\langle m||w \rangle \xrightarrow{\text{Enc}} \mathfrak{c}\_A = \langle D\_A, r, E, F, V, S \rangle. \tag{19}
$$

where *D*,*r*, *E*, *F*, *V*, *andS* are defined as Equations (20)–(24):

$$D\_A = (pk\_A)^d,\\ d = H\_1(sk\_A, r), \\ r \leftarrow \mathbb{Z}\_{p\_{\prime}} \tag{20}$$

$$E = \emptyset, \mathfrak{e} = H\_2(m, w), w \leftarrow \{0, 1\}^{l\_1}, \tag{21}$$

$$F = H\_3(\mathcal{g}^d, E) \oplus (m||w),\tag{22}$$

$$V = \mathbb{g}^v, \upsilon \leftarrow \mathbb{Z}\_{p\prime} \tag{23}$$

$$S = \emptyset \prime , \!s = \upsilon + sk\_A \cdot r. \tag{24}$$

*ReEnc*(*rkA*→*B*, *cA*): The re-encryption algorithm transfers the encrypted message *cA* into the ciphertext *cB* using the generated re-encryption key *rkA*→*<sup>B</sup>* via Equation (25). Bob's secret key can decrypt the transformed ciphertext *cB*. Here, *d* is used to generate the permission of delegation. Only the content owner can create new *D* or *rk* with *skA* and *r*.

Before the transferring, the validation *S* ? <sup>=</sup> *<sup>V</sup>* · *pk<sup>r</sup> <sup>A</sup>* of ciphertext should be checked to ensure Alice generates the ciphertext. Otherwise, the algorithm outputs ⊥:

$$\begin{split} \mathcal{c}\_A \xrightarrow{\text{Re}\,\text{Enc}} \mathcal{c}\_B &= \langle D\_B, r\_\prime E\_\prime F\_\prime, V\_\prime S \rangle \\ &= \langle D\_A \cdot r k\_{A \to B\prime} r\_\prime E\_\prime F\_\prime V\_\prime S \rangle. \end{split} \tag{25}$$

*Dec*(*sk*, *c*): The user decrypts the ciphertext with his secret key and encrypted *c*, e.g., *cA* or *cB*. It outputs the cleartext *m* and random bits *w* via Equation (26). After decryption, the validation of ciphertext should be checked *E* ? = *gH*2(*m*,*w*) . If not, the algorithm outputs ⊥:

$$\begin{split} \mathcal{L}\_{\mathcal{B}} \xrightarrow{\text{Dcc}} (m||w) = F \oplus H\_{\mathfrak{R}}(\mathcal{g}^d, E), \mathcal{g}^d = D\_{\mathcal{B}}^{\frac{1}{\bar{\mathcal{A}}\_{\mathcal{B}}}} \\ = F \oplus H\_{\mathfrak{R}}(D\_{\mathcal{B}}^{\frac{1}{\bar{\mathcal{A}}\_{\mathcal{B}}}}, E). \end{split} \tag{26}$$

In WDLC10 [7], CCA-secure "hashed" ElGamal and modified version is used. The textbook ElGamal is CPA-secure and risky in the rounded attack. To enhance the security, "hashed" ElGamal is applied with a message authenticated mechanism.

#### *4.3. Security Analysis*

Our collusion-resilience PRE scheme is CCA-secure in a random oracle model, under the modified-computation Diffie–Hellman (mCDH) assumption [24].

In this section, we prove the scheme under mCDH assumption [24] that any efficient algorithm's mCDH advantage is negligible.

**Theorem 1.** *Our PRE scheme* ∏ *is IND-PRE-CCA-secure under the assumption of the mCDH [24] in group* G*, and the Schnorr signature [25] is EUF-CMA-secure in the random oracle model. An* *adversary* A*, who asks at most qHi random oracle queries to Hi with i* ∈ {1, ... , 4}*, can effectively break the* (*t*, *qu*, *qc*, *qre*, *qd*, )*-IND-PRE-CCA of our scheme* ∏*, for any* 0 < *ν* < *. Thus we have:*

• *The* (*t* - , - )*-mCDH problem [24] in group* <sup>G</sup> *can be solved by an algorithm* <sup>B</sup> *with Equations (27) and (28):*

$$\begin{aligned} f &\le t + \left( q\_{H\_1} + q\_{H\_2} + q\_{H\_3} + q\_{H\_4} \right. \\ &\left. + q\_u + q\_c + q\_{rk} + q\_{rc} + q\_d \right) \mathcal{O}(1) \\ &\left. + \left( q\_u + q\_c + 4q\_{r\epsilon} + 3q\_d + (2q\_d + q\_{rc})q\_{H\_2} \right) t\_{\epsilon\prime} \right. \end{aligned} \tag{27}$$

$$
\epsilon' \ge \frac{1}{q\_{H\_3}}(2(\epsilon - \nu) - \frac{q\_{H\_2} + (q\_{H\_2} + q\_{H3})q\_d}{2^{l\_0 + l\_1}} - \frac{2q\_d + q\_{r\varepsilon}}{q}).\tag{28}
$$

*where te is the exponential running time in the group* G*.*

*t*

• *The EUF-CMA security of the Schnorr signature [25] can be broken by an attacker with advantage ν within time t*- *.*

**Proof.** It is assumed that the Schnorr signature [25] is (*t* - , - )-EUF-CMA-secure for the probability 0 < *ν* < . While the CDH problem (given *g*, *gx*, *g<sup>y</sup>* output *gxy*) is as hard as the mCDH problem [24] (given *g*, *g* 1 *<sup>x</sup>* , *gx*, *g<sup>y</sup>* outputs *gxy*), this theorem is proved under the mCDH problem [24]. A *t*-time adversary A can break the IND-PRE-CCA security of scheme ∏ with advantage − *ν*. We show how an algorithm B solves the (*t* - , - )-mCDH problem [24] in group G.

Suppose algorithm <sup>B</sup> accepts the input of mCDH challenge tuple (*g*, *<sup>g</sup>x*, *<sup>g</sup>* 1 *<sup>x</sup>* , *<sup>g</sup>y*) <sup>∈</sup> <sup>G</sup>4, and *<sup>x</sup>*, *<sup>y</sup>* <sup>←</sup> <sup>Z</sup>*<sup>p</sup>* is unknown. Algorithm <sup>B</sup> plays the role of challenger playing the IND-PRE-CCA game with adversary <sup>A</sup>. Algorithm <sup>B</sup>'s goal is to output *<sup>g</sup>xy*.

**Setup.** Algorithm <sup>B</sup> passes parameters (*p*, <sup>G</sup>, *<sup>g</sup>*, *<sup>H</sup>*1, *<sup>H</sup>*2, *<sup>H</sup>*3, *<sup>H</sup>*4, *<sup>l</sup>*0, *<sup>l</sup>*1) to adversary <sup>A</sup>. *H*1, *H*2, *H*3, *H*<sup>4</sup> are random hash oracles controlled by the algorithm B.

**Hash Oracle Queries.** Adversary A may send the queries to random oracle *H*1, *H*2, *<sup>H</sup>*3, and *<sup>H</sup>*<sup>4</sup> at any time. Algorithm <sup>B</sup> has four empty lists *<sup>H</sup>list* <sup>1</sup> , *<sup>H</sup>list* <sup>2</sup> , *<sup>H</sup>list* <sup>3</sup> , and *<sup>H</sup>list* 4 initially, used for storing the query parameters and result value tuples.


**Phase 1.** The adversary A sends a series of queries as in the definition of the IND-PRE-CCA game. The algorithm <sup>B</sup> holds three hash lists *<sup>K</sup>list Uncorrupted*, *<sup>K</sup>list Corrupted*, and *<sup>R</sup>list*, answering the adversary A as follows:

• Uncorrupted key generation query *qu*. If the tuple (*a*, *ga*) is not in the hash list *Klist Uncorrupted*, the algorithm <sup>B</sup> chooses *<sup>a</sup>* <sup>←</sup> <sup>Z</sup>*p*; add the tuple (*a*, *<sup>g</sup>a*) to the hash list *Klist Uncorrupted*. Respond with *pk* <sup>=</sup> *<sup>g</sup><sup>a</sup>* to adversary <sup>A</sup>.


(*skA*, *pkA*,*skB*, *pkB*,*rkA*→*B*) is added to the *<sup>R</sup>list*. Then, the *rkA*→*<sup>B</sup>* is returned to adversary A.

For the challenge purpose, both *skA* and *skB* should be uncorrupted.


**Challenge.** When adversary A ends Phase 1, the adversary outputs a target public key *pk*<sup>∗</sup> and two equal-length messages *<sup>m</sup>*0, *<sup>m</sup>*<sup>1</sup> ∈ {0, 1}*l*<sup>0</sup> , queries to algorithm <sup>B</sup>. Algorithm <sup>B</sup> responds as follows:


**Phase 2.** The adversary A issues the queries as in Phase 1. Algorithm B responds to those queries to A as in Phase 1.

**Guess.** The adversary <sup>A</sup> responds a guess <sup>ˆ</sup> *δ* ∈ {0, 1} to B. Algorithm B calculates *<sup>H</sup>*3(*gd*, *<sup>E</sup>*∗) = *<sup>H</sup>*3(*gxy*, *<sup>E</sup>*∗) = *<sup>F</sup>*<sup>∗</sup> <sup>⊕</sup> *<sup>m</sup>*<sup>ˆ</sup> *<sup>δ</sup>* <sup>=</sup> *<sup>α</sup>*ˆ. <sup>B</sup> looks up the hash list *<sup>H</sup>list* <sup>3</sup> for the tuple (*gd*, *E*∗, *α*) where *α* = *α*ˆ, then returns the *g<sup>d</sup>* as the solution *gxy* to the given mCDH instance.

**Analysis.** First, let us evaluate the simulation of random oracles. *H*1, *H*<sup>4</sup> are perfect As long as <sup>A</sup> does not query (*mδ*, *<sup>w</sup>*) to *<sup>H</sup>*<sup>2</sup> or (*gxy*, *<sup>E</sup>*) to *<sup>H</sup>*3, so *<sup>H</sup>*<sup>2</sup> and *<sup>H</sup>*<sup>3</sup> are perfect . We denote *AskH*∗ <sup>2</sup> the event (*mδ*, *w*) has been queried to *H*2, and *AskH*<sup>∗</sup> <sup>3</sup> the event that (*gxy*, *<sup>E</sup>*) has been queried to *H*3.

The challenged ciphertext is identically distributed.

Second, the simulation for the re-encryption oracle. The re-encryption query is perfect unless the adversary A can transfer the ciphertext into the new one without querying hash *H*<sup>1</sup> to obtain the *rk*. We denote this event as *ReEncErr*. Since *H*<sup>1</sup> plays the role of the random oracle, which is queried by adversary A at most *qre* times, we have

$$\Pr[ReEncErr] \le \frac{q\_{rc}}{q}.\tag{29}$$

Third, the simulation for the decryption oracle. Suppose that(*pk*, *c*), *c* = (*D*,*r*, *E*, *F*, *V*, *S*) is a valid ciphertext, as the validation *S* ? <sup>=</sup> *<sup>V</sup>* · *pk<sup>r</sup> <sup>A</sup>* of ciphertext can be checked. There is still a chance that *c* can be generated by querying other random values to *H*<sup>3</sup> instead of *gd*, where *d* = *H*1(*skA*,*r*). Denote *Valid* to be an event that *c* is valid. Let *AskH*<sup>3</sup> be the event that (*gd*, *E*) has been queried to *H*<sup>3</sup> and *AskH*<sup>2</sup> be the event that (*m*, *w*) has been queried to *H*2. Then, we have

$$\begin{aligned} &= \Pr\left[\textit{Valid} \, | \, \neg \textit{Ask} \, H\_2 \right] \\ &= \Pr\left[\textit{Valid} \wedge \textit{Ask} \, H\_3 \, | \, \neg \textit{Ask} \, H\_2 \right] \\ &\quad + \Pr\left[\textit{Valid} \wedge \neg \textit{Ask} \, H\_3 \, | \neg \textit{Ask} \, H\_2 \right] \\ &\le \Pr\left[\textit{Ask} \, H\_3 \, | \neg \textit{Ask} \, H\_2 \right] + \Pr\left[\textit{Valid} \, | \neg \textit{Ask} \, H\_3 \wedge \neg \textit{Ask} \, H\_2 \right] \\ &\le \frac{q\_{H\_3}}{2l\_0 + l\_1} + \frac{1}{q'} \end{aligned} \tag{30}$$

similarly,

$$\begin{aligned} &= \Pr\left[\textit{Valid} \, | \, \neg \textit{Ask} \, H\_3\right] \\ &= \Pr\left[\textit{Valid} \wedge \textit{Ask} \, H\_2 \, | \neg \textit{Ask} \, H\_3\right] \\ &\quad + \Pr\left[\textit{Valid} \wedge \neg \textit{Ask} \, H\_2 \, | \neg \textit{Ask} \, H\_3\right] \\ &\le \Pr\left[\textit{Ask} \, H\_2 \, | \neg \textit{Ask} \, H\_3\right] + \Pr\left[\textit{Valid} \, | \neg \textit{Ask} \, H\_2 \wedge \neg \textit{Ask} \, H\_3\right] \\ &\le \frac{q\_{H\_2}}{2l\_0 + l\_1} + \frac{1}{q} .\end{aligned} \tag{31}$$

Thus, we have

$$\begin{aligned} &\Pr\left[Valid \mid \neg AskH\_2 \lor \neg AskH\_3\right] \\ &\le \Pr\left[Valid \mid \neg AskH\_2\right] + \Pr\left[Valid \mid \neg AskH\_3\right] \\ &\le \frac{q\_{H\_2} + q\_{H\_3}}{2^{l\_0 + l\_1}} + \frac{2}{q} .\end{aligned} \tag{32}$$

Denote *DecErr* as the event that *Valid*|(¬*AskH*<sup>2</sup> ∨ ¬*AskH*3) happens during the entire simulation. The *qd* times of decryption queries have been issued to a decryption oracle, and we have

$$\Pr[DecErr] \le \frac{(q\_{H\_2} + q\_{H\_3})q\_d}{2^{l\_0 + l\_1}} + \frac{2q\_d}{q}.\tag{33}$$

Denote *Good* as the event *AskH*∗ <sup>3</sup> ∨ (*AskH*<sup>∗</sup> <sup>2</sup> |¬*AskH*<sup>∗</sup> <sup>3</sup> ) ∨ *ReEncErr* ∨ *DecErr*. If *Good* has not happened, the adversary A cannot gain any advantage in guessing *δ* from *m*0, *m*1, due to the random *E* as one of the input of *H*3(*gd*, *E*) and *E* = *g<sup>e</sup>* = *gH*2(*m*,*w*) is generated with the random bits *<sup>w</sup>* ← {0, 1}*l*<sup>1</sup> . We have Pr[*<sup>δ</sup>* <sup>=</sup> *<sup>δ</sup>*- |¬*Good*] = <sup>1</sup> 2

$$\begin{aligned} \Pr[\delta = \delta']\\ \theta &= \Pr[\delta = \delta' | \neg Good] \Pr[\neg Good] + \Pr[\delta = \delta' | Good] \Pr[Good] \\ &\le \frac{1}{2} \Pr[\neg Good] + \Pr[Good] \\ &= \frac{1}{2} (1 - \Pr[Good]) + \Pr[Good] \\ &= \frac{1}{2} + \frac{1}{2} \Pr[Good] \end{aligned} \tag{34}$$

and

$$\begin{aligned} \Pr[\delta = \delta']\\ \ge \Pr[\delta = \delta' | \neg Good] \Pr[\neg Good] \\ = \frac{1}{2} (1 - \Pr[Good])\\ = \frac{1}{2} - \frac{1}{2} \Pr[Good]\_\prime \end{aligned} \tag{35}$$

we have

$$|\Pr[\delta = \delta'] - \frac{1}{2}| \le \frac{1}{2}\Pr[Good]. \tag{36}$$

By the definition, the advantage ( − *ν*) for IND-PRE-CCA adversary:

$$\begin{aligned} \epsilon-\nu\\ =\left|\Pr[\delta=\delta']-\frac{1}{2}\right|\\ \leq \frac{1}{2}\Pr[Good]\\ =\frac{1}{2}\left(\Pr[AskH\_3^\*\vee\left(AskH\_2^\*\mid\neg AskH\_3^\*\right)\vee ReEncEr\gamma\vee DecErr]\right)\\ =\frac{1}{2}\left(\Pr[AskH\_3^\*]+\Pr[AskH\_2^\*\mid\neg AskH\_3^\*]\right)\\ +\Pr\left[ReEncErr\right]+\Pr[DecErr]. \end{aligned} \tag{37}$$

Since Pr[*ReEncErr*] <sup>≤</sup> *qre <sup>q</sup>* , Pr[*DecErr*] <sup>≤</sup> (*qH*2+*qH*<sup>3</sup> )*qd* 2*l* 0+*l* <sup>1</sup> <sup>+</sup> <sup>2</sup>*qd <sup>q</sup>* and Pr[*AskH*<sup>∗</sup> <sup>2</sup> |¬*AskH*<sup>∗</sup> <sup>3</sup> ] ≤ *qH*<sup>2</sup> 2*l* 0+*l* <sup>1</sup> , we obtain

$$\begin{split} \Pr[AsH\_3^\*] \\ \geq & 2(\varepsilon - \nu) - [AsH\_2^\*] \cdot \gamma AsH\_3^\* ] \\ - & \Pr[DecErr] - \Pr[ReEncErr] \\ \geq & 2(\varepsilon - \nu) - \frac{q\_{H\_2}}{2^{l\_0 + l\_1}} \\ - & \frac{(q\_{H\_2} + q\_{H\_3})q\_d}{2^{l\_0 + l\_1}} - \frac{2q\_d}{q} - \frac{q\_{re}}{q} \\ = & 2(\varepsilon - \nu) - \frac{q\mu\_2 + (q\mu\_2 + q\mu\_3)q\_d}{2^{l\_0 + l\_1}} - \frac{2q\_d + q\_{re}}{q} . \end{split} \tag{38}$$

In event *AskH*∗ <sup>3</sup> , algorithm B will be able to solve the mCDH instance, and, consequentially, the following is obtained:

$$
\epsilon' \ge \frac{1}{q\_{H\_3}} (2(\epsilon - \nu) - \frac{q\_{H\_2} + (q\_{H\_2} + q\_{H\_3})q\_d}{2^{l\_0 + l\_1}} - \frac{2q\_d + q\_{I^c}}{q}).\tag{39}
$$

From the description of the simulation, the running time of algorithm B can be bounded by

$$\begin{split} t' \le t + (q\_{H\_1} + q\_{H\_2} + q\_{H\_3} + q\_{H\_4} \\ \quad + q\_{\mu} + q\_{\mathcal{C}} + q\_{rk} + q\_{\mathcal{C}^c} + q\_d) \mathcal{O}(1) \\ \quad + (q\_{\mu} + q\_{\mathcal{C}} + 4q\_{\mathcal{C}^c} + 3q\_d + (2q\_d + q\_{\mathcal{C}^c})q\_{H\_2})t\_{\mathcal{C}}. \end{split} \tag{40}$$

This completes the proof of Theorem 1.

#### **5. Experiment**

In this section, we analyze the computation cost. With the development of the blockchain in the past decade, elliptic curves cryptography (ECC), including ECDSA and 25519, has become the standard user access credential. The group with big integers is less used nowadays. As ECC computation is still heavy even for a modern CPU, we propose the practical implementation which cached the ECC operation to speed up for practice. Otherwise, the encryption and decryption over ECC would take too long a time and become meaningless.

#### *5.1. Schemes Comparison*

The two group-based schemes without pairings are using double trapdoors [26] and "hashed: ElGamal [7]. In Table 1, the comparison results indicate that the proposed scheme is slower than WDLC10 for encryption, since "hashed" ElGamal is used. Our scheme does not differentiate the first and the second level of ciphertext. *teN* is the time in exponential operation over the *N*<sup>2</sup> group, where *N* is the safe prime. Let *N* = *pq* be a safe prime modulus, such that *p* = 2*p*- + 1, *q* = 2*q*- + 1, and *p*, *p*- , *q*, *q* are primes. *te* is the time in exponential operation over the group. *k* is the length of generated key in *KeyGen*(1*k*). *<sup>k</sup>*<sup>1</sup> is the hash algorithm *<sup>H</sup>* : {0, 1}<sup>∗</sup> → {0, 1}*k*<sup>1</sup> . *Nx* and *Ny* are the safe-prime modulus corresponding to the delegator and the delegatee, respectively. The ReEnc is not available in our scheme as we do not transfer the ciphertext, but it only generates a re-key.



#### *5.2. Practical Implementation*

Due to the computation inefficiency of ECC, in the practical implementation, we can use elliptic curves and cyclic multiplicative group together to boost the encryption.

For the practical encryption and decryption, the message is divided into small chunks *m*, as each time that group operation is involved in the computation, using ECC will cost much longer time. For the calculation *<sup>F</sup>* <sup>=</sup> *<sup>H</sup>*3(*gd*, *<sup>E</sup>*) <sup>⊕</sup> (*m*||*w*), where *<sup>E</sup>* <sup>=</sup> *<sup>g</sup><sup>e</sup>* ,*e* = *<sup>H</sup>*2(*m*, *<sup>w</sup>*), *<sup>w</sup>* ← {0, 1}*l*<sup>1</sup> , the operation *<sup>E</sup>* <sup>=</sup> *<sup>g</sup><sup>e</sup>* will be too expensive if using ECC. On the other hand, ECC provides better security with less secret key length in bits for the user's public key and secret key. Roughly speaking, 160 bits of the ECC secret key are as strong as 1024 bits of the secret key required in RSA or ElGamal over the multiplicative integer group.

It is better to divide and conquer the problem by using both the elliptic curves group and the cyclic multiplicative integer group *<sup>g</sup>* <sup>∈</sup> <sup>G</sup>*p*. In the calculation *DA* = (*pkA*)*d*, *<sup>d</sup>* <sup>=</sup> *<sup>H</sup>*1(*skA*,*r*),*<sup>r</sup>* <sup>←</sup> <sup>Z</sup>*p*, for the user key pair (*pk*,*sk*), we use generator *gECC* <sup>∈</sup> <sup>G</sup>*ECC*, then *pk* = *gsk ECC*. Meanwhile *<sup>F</sup>* <sup>=</sup> *<sup>H</sup>*3(*gd*, *<sup>E</sup>*) <sup>⊕</sup> (*m*||*w*) the exponential operation *<sup>g</sup><sup>d</sup>* in *<sup>H</sup>*<sup>3</sup> can be calculated only once in ECC and cached. Another exponential calculation *E* = *g<sup>e</sup>* must be evaluated for every *m* and *w*. Thus, for *g<sup>e</sup>* , the ECC operation will be too heavy. Here, we have the modification below:

$$
\langle m||w \rangle \xrightarrow{\text{Enc}} \mathfrak{c}\_A = \langle D\_A, r, E, F, V, S \rangle. \tag{41}
$$

where *D*,*r*, *E*, *F*, *V*, *S* is defined as:

$$D\_A = (pk\_A)^d,\\ d = H\_1(sk\_A, r), \\ r \leftarrow \mathbb{Z}\_{p\_{\prime}} \tag{42}$$

$$E = \mathfrak{g}^{\varepsilon}, \varepsilon = H\_2(m, w), w \leftarrow \{0, 1\}^{l\_1}, \tag{43}$$

$$F = H\_3(g\_{E,CC}^d, E) \oplus (m||w),\tag{44}$$

$$V = \mathcal{g}\_{\text{ECC}}^v v \leftarrow \mathbb{Z}\_{p\*} \tag{45}$$

$$S = \mathcal{g}\_{ECC}^{s} \mathbf{s} = \boldsymbol{\upsilon} + \mathbf{s} \mathbf{k}\_A \cdot \boldsymbol{r}. \tag{46}$$

For the re-encryption *cA ReEnc* −−−→ *cB*, re-encrypting *DB* <sup>=</sup> *DA* · *rkA*→*<sup>B</sup>* = (*g<sup>a</sup> ECC*)*<sup>d</sup>* · *gbd*−*ad ECC* = *<sup>g</sup>bd ECC*, where re-key *rkA*→*<sup>B</sup>* = ( *pkB pkA* )*<sup>d</sup>* = ( *<sup>g</sup><sup>b</sup> ECC ga ECC* )*<sup>d</sup>* = *gbd*−*ad ECC* . For the validation *<sup>E</sup>* ? = *gH*2(*m*,*w*) after decryption, as *pk* is not involved, no ECC operation needs to be performed.

#### *5.3. Performance Comparison*

Python 3.8 is used to implement our PRE scheme and WDLC10. Since Shao09 uses a different theory over the large prime numbers, it was hard to make a fair comparison by choosing the parameters. The code is modified from an open-source pure Python library named python-ecdsa, which is licensed in the public domain.

We implemented the ECC version of our PRE scheme and the practical modification in Python 3.8 and tested it on a MacBook Air of Intel Core i5 at a processor speed of 1.3 GHz. For every 64 bytes of data (including 48 bytes clear message *m* and 16 bytes of random initialization vector *w*), we repeat encryption 100 thousand times and note the time cost.

Our scheme is slightly slower than WDLC10 for encrypting in theory, as we described in Table 1. However, for the modification for practical cached exponential operation for *gECC*, from Figure 4, we can observe that practical modification can speed up the encryption by avoiding ECC computation. In most cases, elliptic curve-based asymmetry cryptography is commonly used in the signature or key exchange due to its slowness. However, the decentralized storage network shows the scenarios where an asymmetry encryption is required. Meanwhile, it is nice to have the key strength and reasonable encryption/decryption speed. The result of Figure 4 shows that even for a modern CPU, the computation is insufficient for fast encryption. The practical implementation is helpful to speed up the operation while maintaining the security from ECC with less key length.

**Figure 4.** Time cost for PRE ECC and practical encryption for every 1000 times of encryption of 64 bytes data on MacBook 1.3 GHz Intel Core i5.

In the experiment, we use the cyclic multiplicative group over an integer of 196 bits for both ours and WDLC10. The ECC curve is NIST192p. The message *m* size is 48 bytes and *w* is 16 bytes since the blake2b outputs up to 64 bytes (512 bits) each time.

In Figure 5, we compare our practical modification PRE scheme with pure-Pythonimplemented WDLC10. PRE brings useful access control, privacy features, and better key management than symmetry encryption. Unlike WDLC10, there is no requirement for layer 1 and layer 2 ciphertext. Our scheme needs only one public/secret key pair. For the hash function, we use blake2b, which can output a flexible length of the hash digest. For the curve, we use NIST192p. Our proxy re-encryption is ready for practice. Figure 5 shows that with the modification on our scheme, the ECC computing is cached, so our scheme can be slightly faster than WDLC10 even if the theory shows our scheme was slower, shown in Table 1.

**Figure 5.** Time cost for our PRE scheme and WDLC10 encryption for every 100 k times of encryption of 64 bytes data on MacBook 1.3 GHz Intel Core i5.

#### *5.4. Performance on the Embedded Device*

The PRE encryption and decryption are highly likely to be performed on an embedded device, such as an IP camera or mobile phone. Figure 6 shows the performance of our PRE scheme and WDLC10 on an early model of Raspberry Pi microcomputer. The early version of Raspberry Pi has quite low computation capacity; however, it achieves a reasonable performance. In addition, the permission grant in our scheme does not require transfer of the ciphertext, which would be friendly to the embedded devices. Recently, the embed device has attained a faster CPU with multi-cores. The feature of skipping the re-encryption makes it fit better for the embedded device.

**Figure 6.** Time cost for our PRE scheme and WDLC10 encryption for every 1000 times of encryption of 64 bytes data on a 1st generation of Raspberry Pi model B 700 Hz.

#### **6. Evaluation**

#### *6.1. Remove Access or Corrupted Ciphertext*

Thus far, our scheme covers the encryption and decryption of data and shares the data with the public key of another user. We can either choose to generate a *rkA*→*<sup>B</sup>* or *DB*, and it is possible to generate a new ciphertext by replacing *DB* with *DA* or reuse *cA* by placing *DB* in a separate file.

$$c\_A \xrightarrow{ReEm} c\_B$$

How about removing the access permission of a user? The concept of forwarding secrecy [27] was introduced in cryptography. Strictly, since a message is sent to another one, it is not a secret anymore, as the content could be copied and shared again. It is impossible to revoke a message or erase information with cryptography. However, in practice, people come and leave the organization, and granting or revoking data access permission is the daily operation. If a user intends to expose the critical information *g<sup>d</sup> ECC* to the public, the cipher *c* is no longer a secret. In those cases, the cryptography method can not ensure security in practice. The only choice is to remove the existing ciphertext to prevent further information leaking.

We provide another ciphertext transfer operation. It is not a part of our scheme but it is useful when transferring the ciphertext into a new one when the message is leaking, and this operation could be applied after any data access permission is revoked.

Transfer operation *cA Trans f er* −−−−→ *c*- *<sup>A</sup>*, where *c*- *<sup>A</sup>* = *D*- *A*,*r*- , *E*, *F*- , *V*- , *S*- :

$$D\_A' = (pk\_A)^{d'}, \\ d' = H\_1(sk\_{A'}r'), \\ r' \leftarrow \mathbb{Z}\_{p'} \tag{47}$$

$$\begin{aligned} F' &= F \oplus r\varepsilon\\ &= F \oplus H\_3(\mathcal{g}^d, E) \oplus H\_3(\mathcal{g}^{d'}, E) \\ &= H\_3(\mathcal{g}^d, E) \oplus (m||w) \oplus H\_3(\mathcal{g}^d, E) \oplus H\_3(\mathcal{g}^{d'}, E) \end{aligned} \tag{48}$$

$$\mathcal{L} = H\_3(\mathcal{g}^{d'}, E) \oplus (m|\lvert w \rvert)\_\* $$

$$\mathcal{V}' = \mathcal{g}^{\mathbf{v}'}, \mathbf{v}' \leftarrow \mathbb{Z}\_{\mathfrak{p}\prime} \tag{49}$$

$$\mathbf{S}' = \mathbf{g}^{s'}, \mathbf{s}' = \mathbf{v}' + s\mathbf{k}\_A \cdot \mathbf{r}'.\tag{50}$$

The ciphertext transfering key *re* is defined:

$$r\varepsilon = H\_3(\mathcal{g}^d, E) \oplus H\_3(\mathcal{g}^{d'}, E). \tag{51}$$

It is safe to send the transfer key to the proxy and transfer the existing ciphertext into a new one. By this operation, the previous ciphertext is discarded, and the new permission of access should be regenerated.

The concept above is also helpful in blockchain storage content for key renewal. Periodically changing the secret key is recommended to avoid potential confidential key leakage. A finance blockchain such as Bitcoin can create another secret/public key pair and transfer existing coin assets to the new wallet address. The signature is the evidence of a coin transaction. As opposed to this, the storage blockchain uses a secret key to decrypt. Losing a key is losing the data unless an algorithm can transfer the old ciphertext to the new one under the new key. Our PRE scheme is suitable for this scenario.

#### *6.2. Search with PRE*

The commercial applications are interested in searching [28,29]. Nowadays, searching in data is more than just full-text matching. Complexity algorithms are applied to texts, images, videos, and even speech. A CPA-secure encryption works against searching over the ciphertext in concept. Even if, in the future, the full homomorphic encryption [30] is ready, it might be hard to perform a search over CPA ciphertexts.

With proxy re-encryption, it is possible to design the application that outsources the information processing to the trusted party. Data could be stored safely on the cloud with versions, and the index for the recent version will be processed in-house.

#### *6.3. Applications with PRE*

We introduced PRE for decentralized storage network scenarios, which are the fundamental components for lots of blockchain applications. It is possible to build a media store for movies and music based on blockchain. Once a user purchases the movie, he has the right to download the movie file content freely. A purchase record is marked on the blockchain, as evidence of the right to use from the intellectual property owner. It is publicly verifiable. The PRE re-key can be used as evidence. The evidence can be listed publicly and it is meaningful only to the purchaser who owns the secret key.

#### **7. Conclusions**

In this paper, we proposed a PRE scheme satisfying the PoRep scenario. Since the PoRep is the key algorithm for a decentralized storage network, the proposed PRE would be an important candidate for a future blockchain storage network. In a decentralized storage network, access control must be cryptography-based. Meanwhile, the decentralized storage network suffers from outsourcing attacks. Proof-of-replication helps to convince users that their content is kept by the dedicated storage resource. The proposed PRE scheme is suited for proof-of-replication, which does not generate the extra ciphertext. The scheme reduces the cost of cryptographic access control. Moreover, our PRE scheme is CCA-secure and only requires one key pair. With the practical implementation, it is reasonably fast to use in applications.

Nowadays, users become used to placing their data on the public cloud. Although the data access is permission-controlled, it might be transparent to cloud storage providers. Employing the PRE scheme will bring true privacy to user data, even if the service provider is semi-trusted.

Due to the computation efficiency, symmetry encryption is widely used for encryption. However, the key management for symmetry encryption is complex, leading to more privacy issues. With the maturity of the PRE scheme, it can bring more flexibility to data storage and access control. Asymmetry encryption will play a more important role in blockchain-based systems.

#### **8. Future Work**

In this paper, we proposed the proxy re-encryption for the decentralized storage networks. It is a CCA-secure, collusion-resilience PRE scheme that requires only one key pair. The PRE scheme works under the concept of proof-of-replication, which is the core algorithm of the decentralized storage network, and the proposed scheme is reasonable, fast, and practical. It can be used for mobile and IoT devices. In the future, we will keep working on speeding up the scheme. Furthermore, it is possible to add more features based on the current scheme, e.g., the multiply public keys re-encryption, or the time-limited re-key issuing. To enable searching within PRE is also an interesting topic.

**Author Contributions:** Funding acquisition, D.L.; Supervision, X.H.; Writing—original draft, J.K.; Writing—review & editing, J.Z. All authors have read and agreed to the published version of the manuscript.

**Funding:** This research was funded in part by the XJTLU Key Program Special Fund under grant number KSF-E-05. This work is supported by Research Project Supported by Shanxi Scholarship Council of China 2021-038, and Applied Basic Research Project of Shanxi Province No. 20210302123130, No. 20210302124273. This work was partially supported by the National Natural Science Foundation of China under Grant No. 62002296; the Natural Science Foundation of Jiangsu Province under Grant No. BK20200250; and the XJTLU Key Programme Special Fund under Grant No. KSF-E-54.

**Conflicts of Interest:** The authors declare no conflict of interest.

#### **Glossaries**



#### **References**


MDPI St. Alban-Anlage 66 4052 Basel Switzerland Tel. +41 61 683 77 34 Fax +41 61 302 89 18 www.mdpi.com

*Applied Sciences* Editorial Office E-mail: applsci@mdpi.com www.mdpi.com/journal/applsci

MDPI St. Alban-Anlage 66 4052 Basel Switzerland Tel: +41 61 683 77 34 www.mdpi.com

ISBN 978-3-0365-5878-3