Blockchain-based cross-user data shared auditing

In cloud storage, public auditing is a more popular data integrity verification technique since it allows users to delegate auditing tasks to a fully trusted third-party auditor (TPA). However, it is difficult to find such a TPA in practical application. Besides, the centralised auditing model makes TPA have to bear burdensome work pressure, which limits the practicability of existing schemes. In this paper, we firstly proposed a blockchain-based generalised shared auditing mechanism BCSA in the cross-user scenario, which aims at achieving available public auditing with a non-fully trusted TPA, and reducing the user's auditing fees and TPA's work pressure by allowing data users to share their auditing procedure with others. Furthermore, we initialise a concrete construction BCSAD with Diffie–Hellman protocol for the cross-user auditing scenario with different data. Likewise, we also propose a novel construction BCSAI for the cross-user auditing scenario with identical data, which utilises a password-authenticated key exchange (PAKE) protocol to achieve shared auditing and ciphertext deduplication, reducing data storage and auditing fees for data users and alleviating service pressure on the cloud server and TPA. Security and performance analysis evaluate the practicability of the proposed scheme.


Introduction
Promoted by the rapid development of various Internet technologies (e.g.cloud computing), the global data volume will explosively grow from 33ZB in 2018 to 175 ZB in 2025 (Reinsel et al., 2018). Therefore, both the individual and enterprise users tend to outsource their data to cloud storage servers for reducing their storage costs and enjoying professional data storage services Xiao et al., 2021;Zhang et al., 2020).
Despite the compelling benefits of network storage service, some security and efficiency issues have attracted much attention. Due to data outsourcing, data users lose physical control of their data and the malicious server may tamper with or delete the rarely accessed data to save storage space, which inspires people to worry about the reliability of data outsourcing services. As a simple but effective solution, the notion of Provable data possession (PDP) (Ateniese et al., 2007) is introduced to achieve efficient data integrity verification, in which the data users pre-process their data before uploading it to obtain some necessary verification metadata (i.e. authenticators), which enables they to check the data integrity by challenging partial data blocks selected randomly other than the entire outsourced data.
Inspired by PDP, many improved schemes (Shacham & Waters, 2008;Shen et al., 2020Shen et al., , 2017J. Wang et al., 2015) are proposed to enhance the practicability of data auditing, especially in public auditing. However, most existing public auditing schemes are built on a fully trusted TPA, which limits the practicality of those schemes. On the one hand, it is difficult to find a fully trusted TPA in practical applications. As a remedy, Xu et al. (2020) proposed a blockchain-based (Nakamoto, 2008) public auditing scheme with a non-fully trusted TPA, in which the blockchain will work as a monitor to guarantee the reliability of non-fully trusted TPA. Furthermore, H. Yuan et al. (2020) adopt smart contract (Wood, 2014) to realise automatic public auditing without any TPA, while its auditing fee is far higher than that of Xu et al.'s scheme. On the other hand, the centralised auditing mechanism inevitably makes TPA bear the burdensome service pressure. Although some solutions, such as batch verification and batch auditing, have been proposed to improve the work efficiency of TPA, those schemes are unfriendly for those users who only store fewer data. Since the workload of TPA in each auditing challenge is independent of the number of checked files, the user who checks fewer data must pay the same money as other users for each challenge. Therefore, it is promising to study how to achieve cross-user shared auditing to further reduce TPA's workload and users' auditing fees by allowing users to share their auditing procedure with others.

Our contributions
In this paper, we propose a blockchain-based cross-user shared auditing (BCSA) mechanism, and give two concrete schemes BCSAD and BCSAI for the cross-user scenario with different and identical data, respectively. Our contributions are listed as follows.
• We propose a basic mechanism BCSA for blockchain-based shared auditing with a nonfully trusted TPA, which allows data users to share the auditing challenge to reduce auditing fees and improve the work efficiency of TPA. • We adopt the Diffie-Hellman protocol to initialise a concrete scheme BCSAD for achieving shared auditing in the cross-user auditing scenario with different data. • We further propose BCSAI to achieve shared auditing and encrypted deduplication in the cross-user auditing scenario with identical data. Compared with BCSAD, BCSAI can not only save more storage resources and reduce the data auditing and storage fees of data users, but also protect outsourced data from privacy leakage and brute-force attack.

Related work
For efficient integrity verification, Ateniese et al. (2007) proposed PDP to enable data users to check the integrity of their data with partial data blocks other than the entire data. Note that PDP possesses the property of public verification, which enables data users to delegate their auditing tasks to a third-party auditor. After that Juels and Kaliski (2007) proposed Proof of Retrievability (PoR) to help data users to check the availability of the outsourced data. Unlike PDP, PoR allows data users to conditionally retrieve their data even if it has been corrupted. Inspired by PDP and PoR, many improved schemes (Shah et al., 2007;H. Wang, 2012;C. Wang et al., 2011;J. Yuan & Yu, 2015) are proposed to enhance the efficiency and scalability of data auditing. Batch auditing. For improving audit efficiency, C. Wang et al. (2010) proposed a privacypreserving public auditing scheme that supporting batch auditing. In fact, this scheme only achieves the batch verification of integrity proofs generated by different servers, while batch auditing should be able to check multiple files at once. In other words, TPA generates a single challenge for multiple files, and the server returns only one proof, which means that TPA only executes one verification operation other than the process described in the scheme. Distinctly, the cross-user batch auditing, we called shared auditing, can further improve the efficiency of integrity verification, and help data users reduce the audit fee through sharing auditing challenges. Unfortunately, batch auditing can be easily achieved in the single-user scenario but is difficult to implement in cross-user scenarios currently.
Blockchain-based auditing. As a revolutionary technology, blockchain Li et al., 2021;Nakamoto, 2008;Zhang et al., 2020) provides more possibilities for solving some stubborn problems in public auditing scenarios. On the one hand, aiming at improving the practicability of TPA-aided public auditing, Zhang et al. proposed a blockchainbased auditing scheme with a non-fully trusted TPA, in which the TPA is required to publish auditing results on the blockchain so that data users can discover malicious TPA. Likewise, Xu et al. proposed a novel blockchain-based scheme that employs a non-fully trusted TPA to implement data auditing and adopts blockchain to monitor the behaviours of TPA. On the other hand, for achieving auditing without TPA, Xu et al. proposed an arbitrable PDP protocol without TPA, which utilises blockchain to record the interaction information of data auditing and uses smart contracts to realise automatic fair arbitration. Furthermore, Yuan et al. proposed an automatic data auditing scheme, which employs smart contracts to implement auditing tasks and fair arbitration.
Deduplicatable data Auditing. For achieving privacy-preserving space-saving, Douceur et al. (2002) first proposed Convergent encryption (CE) that requires data users to encrypt their data with its hash value, to enable the cloud server to detect and delete the duplicate copies of the same data. Further, Bellare et al. (2013) formalised a novel primitive Messagelocked encryption (MLE) for encrypted data deduplication. Despite the excellent efficiency, the existing MLE-based deduplication (Li et al., 2013;Miao et al., 2021;Tian et al., 2020;Xie et al., 2020) schemes are vulnerable to brute-force attack (BFA) due to their limited keyspace. J. Liu et al. (2015) given a different solution that adopts a password-authenticated key exchange (PAKE) protocol to unify the encryption key to resist BFA. Considering the data integrity in encrypted deduplication, Zheng and Xu (2012) first introduced proofof-storage with deduplication (POSD) that combines client-side deduplication and data auditing to save storage space while ensuring reliable data storage. However, this trivial combination model will inevitably result in a rapid increase of data tags and authenticators. J. Yuan and Yu (2013) proposed an improved POSD scheme that supports batch processing with fixed costs. Li et al. (2015) designed two novel schemes named SecCloud and SecCloud+, in which data users employ a trusted TPA to pre-process their data before uploading it and check data integrity later. Inspired by MLE, X. Liu et al. (2017) proposed a message-locked integrity auditing and deduplication scheme to achieve the deduplication over auditing authenticators. Xu et al. (2020) introduced a novel combination model for data deduplication and auditing, in which auditing authenticators not only be used by TPA to check data integrity, but also be utilised by CS to achieve the PoWs process.

Organisation
In the rest of this paper. Sections 2 and 3 introduce the necessary preliminaries and formalised framework. Next, we describe the specific constructions of BCSA and its two applications in Section 4, and then analyse the security and performance of the proposed schemes in Sections 5 and 6, respectively. Finally, we draw a conclusion in Section 7.

Bilinear map
Let G 1 , G 2 and G T be three multiplicative cyclic groups of the same prime order p, g 1 and g 2 are generators of groups G 1 and G 2 , respectively. A bilinear map is e : G 1 × G 2 → G T with the following properties: • Computational: The map e can be computed efficiently for all u ∈ G 1 , v ∈ G 2 .

Password authenticated key exchange (PAKE)
The PAKE protocol, named SPAKE2 (Abdalla & Pointcheval, 2005), can be executed by Alice and Bob as follows.
(1) Let G be a cyclic group with order p and generator g, and M u ∈ G be the public elements of user u. A hash function H is modelled as a random oracle. (2) Each side performs the following computation: • Alice chooses x ∈ R Z p and computes X = g x . She defines X * = X · (M A ) pw A .
• Bob chooses y ∈ R Z p and computes Y = g y . He defines Y * = Y · (M B ) pw B . (3) Alice and Bob exchange X * and Y * , and then computes the session key: • Alice computes K A = (Y * /(M B ) pw A ) x and then outputs the shared key as Notably, on input the same password, namely pw A = pw B , both Alice and Bob can obtain a uniform session key SK A = SK B from this protocol.

System model
As shown in Figure 1, the proposed system model involves four kinds of entities: • Cloud Server (CS): An honest-but-curious entity is responsible for providing storage service, which means that it will learn as much knowledge of outsourced data as possible while executing various tasks honestly. • Data users: Entities who want to outsource data. In particular, data users may encrypt their data before uploading it to guarantee data privacy, or execute a deduplication protocol with CS to reduce storage fees while saving storage space. • Third Party Auditor (TPA): A non-fully trusted entity is responsible for providing proxy auditing service. With the corresponding authenticators pre-computed by the data user, TPA can help data users to check data integrity by verifying the integrity proof generated by CS. • Blockchain: A distributed ledger is responsible for providing immutable data record service and smart contract running platform.

Adversarial model and security requirements
The adversarial model of the proposed scheme mainly considers four security threats.
• Forgery attack: The CS who loses the outsourced data of data users due to various causes might try to generate a valid integrity proof to pass the auditing challenge launched by TPA. • Illegal access: The TPA may learn some sensitive information about outsourced data from the authenticators and integrity proofs returned by CS. Further, CS and malicious users may try to access the context of outsourced data. • Online BFA: In encrypted data deduplication, for a predictable file, the malicious adversary can construct a candidate files set, and then upload them one by one. According to the response of CS, the malicious adversary will find out the plaintext of outsourced encrypted data. • Offline BFA: With some eavesdropped metadata (i.e. a hash value), both the malicious CS and adversary can construct a candidate files set and calculate its metadata set. Then, they will find out the plaintext of outsourced encrypted data by searching metadata set for the duplicate copy of eavesdropped metadata.
Then, we set some security requirements for the proposed scheme.
• Correctness: The proposed scheme should guarantee only the prover who indeed possesses the outsourced data can pass the auditing challenges.

The proposed scheme
In this section, we first introduce the basic scheme BCSA, and then extend it into BCSAD and BCSAI in two specific application scenarios, respectively.
• Key Sharing. With blockchain, the data user u i who wishes to achieve shard auditing can find a partner. Both of them can obtain a uniform public/private key pair (PK, SK) = (g SK , SK) by executing a key exchange protocol on the blockchain. More details will be described in BCSAD and BCSAI. • Data upload. For simplicity, we assume that there are d 1 data users u i join in the shared auditing. When u i wants to upload her file F i , she firstly divides F i into F i = m i1 ||m i2 || · · · ||m in . Then, she calculates authenticator for each m ij : Where M ij = H(PK||i|j). Subsequently, u i calculates file tag t i = h(F i ) and α = v SK , and then uploads F i , {σ ij }, α, PK to the cloud server. Notably, all the files of partners will be regarded as one file to be checked.
• Challenge. On input system parameters Para, this algorithm picks three random elements z ∈ [1, nd 1 ], and r 1 , r 2 ∈ Z * p , and outputs Chal = (z, r 1 , r 2 ) as auditing challenge. Note that Chal will be published on the blockchain.
• Prove: On input the challenge Chal and files {F i } 1≤i≤d 1 , this algorithm calculates the indexes (a w1 , a w2 ) and coefficient b w of the wth challenged data blocks.
Then, this algorithm generates the corresponding integrity proof Proof = (R, μ, σ ) by Equation (3). Finally, it will be published on the blockchain. (3) • Verify. On input the integrity proof Proof = (R, μ, σ ), this algorithm checks the integrity of outsourced data as follows.

BCSAD
In this part, we propose a concrete scheme BCSAD which is an application of BCSA in the cross-user auditing scenario with different data.

Overview
For achieving shared auditing, a data user u i who wants to upload a file F i can publish a notice on the blockchain to find a partner. Here, we assume that u i has found a partner u j who wants to upload file F j . As shown in Figure 2, u i and u j execute a Diffie-Hellman key exchange protocol to obtain a uniform public/private key pair via blockchain, and then calculate the auditing authenticators of their files, respectively. After uploading the files F i , F j and their authenticators to CS, u i and u j delegate their auditing tasks to a non-fully trusted TPA and sign a smart contract on the blockchain to pay TPA for auditing service. Finally, TPA challenges CS for verifying the integrity of outsourced files F i and F j , and the entire auditing workflow consists of Chal, Proof , Result is recorded on the blockchain. In this way, the data users u i and u j reduce their auditing fees while achieving reliable integrity verification.

Concrete construction
• System setup: By running the Setup algorithm, the system manager can generate some necessary parameters Para to initialise a BCSAD auditing system. • Key sharing: Each user u i who wants to upload his file F i selects a private key sk i ∈ Z * p randomly, and then calculates the corresponding public-key pk i = g sk i . To achieve shared auditing, u i publishes a notice including pk i on the blockchain, and u j publishes a transaction including pk j to respond u i . Then, they can obtain the same session key k via Diffie-Hellman protocol as follow: Subsequently, they can calculate the uniform private key SK = h(k) and public key PK = g SK , which will be used in authenticator generation and proof verification, respectively. • Data outsourcing: With the same key pair (PK, SK), u i and u j , respectively, execute the same process as Data upload. Then, they delegate their auditing tasks to TPA and sign a smart contract SC = t i , t j , PK, coin i , coin j , where coin i and coin j are the pre-agreed deposit of u i and u j , which will be used to pay TPA for auditing service. • Data auditing: To check the integrity of files F i and F j , TPA challenges CS with a "challenge-response" model.
(1) (1)TPA runs the Challenge algorithm to generate an auditing challenge Chal = (z, r 1 , r 2 ), and publish it on the blockchain. (2) (2)To convince TPA that the checked files are available, CS takes as input Chal and files F i , F j to runs the Prove algorithm, and obtain an integrity proof Proof = (R, μ, σ ). Then, CS sends it to blockchain.

BCSAI
In this part, we initialise a concrete construction of BCSA, called BCSAI, in the cross-user auditing scenario with identical data.

Overview
Compare to BCSAD, BCSAI aims at achieving encrypted data deduplication to save storage space while implementing shard auditing in the cross-user auditing scenario with identical data. As is described in Figure 3, the data user u i who wishes to outsource file F can firstly calculate its short hash value sh and search CS for duplicate sh. If no duplicate copy, the data has not been stored on CS, u i executes an initial upload process. Otherwise, u i finds out all the potential duplicate files from CS and executes a PAKE protocol with their owners. If the output of PAKE is a random value, u i executes an initial upload process. Otherwise, u i can obtain an encryption key from PAKE and perform a subsequent upload process. After that, all the users of file F will share the unique data copy, auditing authenticators, and auditing results, which avoids the resource waste caused by repetitive auditing tasks.

Concrete construction
• System setup: By running the Setup algorithm, the system manager can generate some necessary parameters Para to initialise a BCSAI auditing system. In particular, a short hash function SH : {0, 1} * → {0, 1} s is defined to generate a short hash value for searching the potential duplicate files. Besides, the symmetric encryption algorithm E()/D() and additively homomorphic encryption Enc()/Dec() algorithm are used to guarantee the security of outsourced data. • Key sharing: When u i wants to achieve encrypted data deduplication and shared auditing, she calculates the short hash value sh = SH(F) and searches CS for duplicate copy. If no duplicate sh, u i executes an initial upload process. Otherwise, CS finds out all the potential duplicate file {F j } 1≤j≤d 2 of F, and requires their owners u j to take the hash value h j = h(F j ) to execute a same-input-PAKE protocol with u i who inputs h = h(F). Finally, each u j obtains a session key key j and u i obtains a session key set {key j } 1≤j≤d 2 . According to the PAKE protocol described in Section 2.2, the session key j is equal to key j if and only if h is equal to h j . Subsequently, u i interacts with u j as follows: (1) (1)Each user u j first utilises a pseudorandom function to extend the length of key j and then divides the result to key jL ||key jR . Finally, u j sends key jL and (SK j + key jR ) to CS, where SK j is the encryption key of file F j . (2) (2)For each key j , u i extends and splits it to key jL ||key jR in the same way as u j does.
Then u i sends CS its public key pk, {key jL } and {Enc(pk, key jR + r)} where r is a random element chosen from the plaintext group. (3) (3)After receiving these message from {u j } 1≤j≤d 2 and u i , CS check if there is an index j such that key jL = key jL . If so, CS uses the homomorphic encryption to compute x by Equation (6), and then sends x back to u i .
x = Enc(pk, SK j + key jR ) Enc(pk, r + key jR ) = Enc(pk, SK j − r) Otherwise, CS sends back x = Enc(pk, r ), where r is a random element chosen from the plaintext group. (4) (4)With the message x returned by CS, u i can obtain the encryption key SK = Dec(sk, x) + r and its public key PK = g SK , and then execute a subsequent upload process. • Data outsourcing. If there is no potential duplicate file of F in CS, u i executes an initial upload process. Otherwise, u i performs a subsequent upload process.
(1) (1)Initial upload. u i randomly chooses an encryption key SK ∈ Z * p and calculates its public key PK = g SK and α = v SK . Then, u i encrypts the file F into C = E(SK, F) = c 1 || · · · ||c n and computes auditing authenticator for each data block by Equation (7). Finally, u i uploads C, {σ i }, α, PK to CS and deletes local data but (SK, PK).
(2) (2)Subsequent upload. u i uses SK obtained from PAKE protocol to compute the ciphertext C and authenticators {σ i }. Then, u i uploads C, {σ i }, α, PK to CS, and CS checks if the outsourced data has been stored on server. If not, CS stores sh, PK, α, C, {σ i } locally and crates an index sh, CS on the blockchain for subsequent deduplication. Otherwise, CS deletes the duplicate data and returns an access link. • Data auditing: To check the integrity of outsourced file F, TPA challenges CS with a "challenge-response" model.
(3) (3)Upon receiving the integrity proof Proof, TPA runs the Verify algorithm to check data integrity as follows: If Equation (9) holds, TPA publishes Result = 1 on the blockchain, to represent that the files F is available. Otherwise, Result = 0.
• Retrieval. When the data user u i downloads the ciphertext C from CS, she can retrieve the plaintext F by calculating F = D(SK, C).
Based on blockchain and deduplication, BCSAI enables all users of the same data can learn its integrity from blockchain, which reduces the resource waste caused by repetitive auditing tasks. Therefore, the periodic automatic auditing model is more suitable for BCSAI, and data users can pay the low average fees for shared auditing.

Security analysis
According to security requirements, we analyse the security of the proposed schemes.
Theorem 5.1: The proposed schemes can guarantee that only the prover who indeed holds the outsourced data can pass the auditing challenges.
Proof: In fact, the proposed schemes BCSAD and BCSAI inherits the audit mechanism of BCSA. Therefore, we only analyse the security of BCSA here.
Firstly, BCSA adopts similar authenticator generation and proof verification algorithms as C. Wang et al.'s (2010), both of them are adapted from Shacham's work (Shacham & Waters, 2008). Therefore, the proposed scheme BCSA can guarantee that no malicious CS is able to forge a valid proof {σ , μ, R} to pass the auditing verification Equation (4) whose correctness has been derived from the Theorem 4.2 proposed on Shacham's work (Shacham & Waters, 2008). Notably, we adopt a value R in BCSA to guarantee the privacypreserving auditing, which will not affect the validity of the equation, bounded by the hardness of DLP and the commutativity of modular exponentiation in pairing.
Furthermore, based on the collision-resistance of hash function h() and the determinism of the discrete logarithm, we can derive that the underlying μ c of μ = μ c + rh(R) and R = (α) r = (v SK ) r is valid if and only if the response {σ , μ, R}.
Finally, we argue that the validity of μ c implies the correctness of the challenged blocks {m a w1 ,a w2 } where μ c = z w=1 b w m a w1 ,a w2 . Note that both the index and coefficient of the challenged blocks are generated by two pseudorandom functions, respectively. Besides, the number of challenged blocks of each auditing challenge is selected randomly. Therefore, the validity of parameter μ c is bounded by the correctness of challenged blocks.
Theorem 5.2: The proposed two schemes BCSAD and BCSAC can prevent malicious TPA from obtaining any sensitive information from the integrity proofs. Further, BCSAI can prevent any malicious entities, including TPA, users and CS, from accessing the plaintext of outsourced data illegally.
Proof: On the one hand, we show that no information on μ c can be leaked to TPA. Since μ is blinded by r as μ = μ c + rh(R) and R = (α) r , where r is chosen randomly by CS and is unknown to TPA. Bounded by the hardness of DLP, TPA cannot derive the value r from R. Thus, the privacy of μ c is guaranteed from μ, TPA cannot obtain any information on μ c from μ.
Furthermore, we show that no information on μ can be derived from σ , where Due to the confidentiality of private key SK, even if TPA can easily calculate z w=1 M b w SK a w1 a w2 , he cannot obtain (v μ c ) SK form σ , let alone μ c . Therefore, TPA cannot learn any information about the outsourced data from integrity proofs.
On the other hand, we argue that BCSAI can guarantee that no entities, including malicious users, TPA, and CS, can accessing the plaintext of the outsourced data illegally. By using a short hash value, By adopting a same-input PAKE protocol, all the data users of the same outsourced data can obtain a uniform encryption key to encrypt their data. Without an encryption key, any malicious can decrypt the outsourced ciphertext even if they have obtained it illegally.

Theorem 5.3: The proposed BCSAI can prevent malicious users from obtaining the plaintext by launching an online BFA.
Proof: For a predictable file F, the malicious user can construct a candidate file set {F i } that may include F. Then, she uploads the ciphertext of F i one by one and observes the response of CS to find out the target file F. By using the short hash query, the malicious cannot justify whether F has been stored when its short hash value exists on the blockchain. Likewise, she also cannot guarantee that the short hash values of other candidate files do not exist on the blockchain. Therefore, in BCSAI, the malicious user cannot find out the plaintext F of the outsourced encrypted data through launching an online BFA.
Theorem 5.4: The proposed BCSAI can prevent any malicious entities, including users, TPA, and CS, from obtaining the plaintext by launching an offline BFA.
Proof: In BCSAI, the encryption key of each outsourced data is generated by the first uploader. Thus, the short hash, ciphertext, integrity proof, authenticator of the outsourced data cannot leak the information of its plaintext. Distinctly, the malicious entities cannot obtain the plaintext by launching an offline BFA.

Performance evaluation
In this section, we evaluate the performance of our two schemes by comparing them with the three latest schemes (C. Wang et al., 2010;Xu et al., 2020; in terms of functionality comparisons, theoretical analysis, and implementation. Table 1 lists the functionalities of five compared schemes. As regards data auditing, all the compared schemes can support batch auditing, but only Wang et al.'s scheme cannot achieve public auditing with the non-fully trusted TPA. Note that Yuan et al.'s scheme utilises smart contract to achieve public auditing without any TPA, but its auditing fees is much higher than other schemes. Besides, only Xu et al.'s scheme cannot protect data privacy well. Our two schemes and Xu et al.'s scheme can share the auditing authenticators and results of outsourced data among its users. Further, only our two schemes can achieve cross-user shared auditing, which means that the user's auditing fees of our schemes are lower than that of other schemes. Considering the space savings, only our BCSAI, Xu et al.'s

Theoretical analysis
We further analyse the compared schemes in terms of computation, communication, and storage costs. Notions using in those schemes are defined in Table 2. Table 3 shows the computation cost of compared schemes during checking d 1 files. To achieve cross-user shared auditing, BCSAD and BCSAI require additional computing costs to unify shared users' keys by running a key exchange protocol. As a result, their computation costs of Prove and Verify phases are only dependent on the number of challenged data blocks other than that of checked files. Therefore, the extra costs consumed by the key exchange are acceptable to achieve shared auditing for reducing users' auditing fees and TPA's service pressure. During Upload phase, all the compared schemes consume the same computation costs to generate the auditing authenticators, while Yuan et al.'s scheme and BCSAI separately consume extra costs 2H + 1E and 1H + 1E to encrypt each data block for ensuring the privacy of outsourced data. Correspondingly, both of them require extra computation costs to decrypt the encrypted data during Retrieval phase. Table 4 analyses the communication and storage costs for compared schemes. Due to the extra Key exchange phase in shared auditing, BCSAD and BCSAI separately need d 1 (d 1 − 1)|G| and (4d 2 + 1)|Z| + 4d 2 |G| to unify the key pair of shared participants, which enable the communication costs of them during Auditing phase are independent of the

Implementation
In this section, we use Python to implement the compared schemes by calling GNU Multiple Precision Arithmetic (GMP) Library and Pairing-Based Cryptography (PBC) Library. For each scheme, we further tested the computation costs of the client on a Windows 10 laptop with a 2.30 GHz Intel Core i7-1068NG7 CPU and 16GB memory, as well as the computation costs of the server on CentOS 8.3.2011 with two 2.20 GHz Intel Xeon Silver 4210 CPU and 128 GB memory. Specifically, we use SHA-256 and AES-128 to generate an encryption key and encrypt the outsourced data and set the number of shared users ranges from 1 to 11, and the number of challenged blocks ranges from 50 to 500 in data auditing. Notably, all experiments are executed 30 times to obtain an average result. Next, we analyse the performance of compared schemes from data outsourcing and auditing Firstly, we evaluate the computation costs of compared schemes during the key exchange phase. Recalling in Tables 3 and 4, only the schemes BCSAD and BCSAI need to perform key exchange protocol to achieve shared auditing. Therefore, Figure 4 shows the computation costs of BCSAD and BCSAI during the key exchange phase. Specifically, When the number of partners in shared auditing is 5, the time costs of BCSAD and BCSAI are 0.85 and 0.88 s, respectively. When the number of shared partners raises to 10, the corresponding costs are 3.74 and 3.98 s. Distinctly, the time costs of BCSAD are similar to that of BCSAI. Notably, the time consumption of key exchange in practical application is higher than our experiment results since the interaction delay cannot be avoided and controlled.
Secondly, we show the computation costs of compared schemes during the upload phase in Figure 5. Note that we unify the size of each partner's file as 1 MB in this experiment. Obviously, the time costs of Wang et al.'s scheme are roughly identical to that of Xu et al.'s scheme and BCSAD, which is mainly consumed to generate auditing authenticators. In particular, the time costs of Yuan et al.'s scheme and BCSAI are higher than others since they consume extra time to encrypt the outsourced data.
Next, we replay Ateniese et al.'s work (Ateniese et al., 2007) with a simulation experiment. As shown in Figure 6, for achieving 99% auditing precision rate, the number of challenged blocks must not be less than 4603 at 0.1% block corruption rate, 459 at 1% block corruption rate, 228 at 2% block corruption rate. For 95% auditing precision rate, the number of challenged blocks must not be less than 2995 at 0.1% block corruption rate, 299 at 1% block corruption rate, 149 at 2% block corruption rate. Distinctly, the number of challenged blocks   is roughly 460 cr for achieving 99% auditing precision rate where cr% is block corruption rate. Likewise, the number of challenged blocks is roughly 300 cr for achieving 99% auditing precision rate. Therefore, the most existing auditing schemes are trend to evaluate their performance during challenging 460 and 300 blocks at 1% block corruption rate.
Then, we set the number of the checked file as 5 and test the computation costs of compared schemes during challenging different numbers of blocks. In the proof generation phase, the time costs of Wang et al.'s scheme, Xu et al.'s scheme, Yuan et al.'s scheme, BCSAD, and BCSAI are 2.72, 2.71, 2.66, 0.54 and 0.47 s during challenge 300 blocks, and the corresponding costs are 3.89, 3.95, 3.76, 0.75 and 0.83 s during challenging 460 blocks. In the proof verification phase, their time costs are 7.55, 8.13, 7.40, 1.65 and 1.43 s during challenging 300 blocks, 11.59, 12.43, 12.20, 2.51 and 2.34 s during challenging 460 blocks. Distinctly, we can see that the time costs of each scheme during proof generation and proof verification increase linearly with the number of challenged blocks.
Further, we set the number of challenged blocks as 460 and test the computation costs of compared schemes during checking different numbers of files. As described in Figure 8 Figures 7 and 8, the computation costs of BCSAD and BCSAI in the data auditing phase do not depend on the number of challenged files as other schemes do, which proves that the performances of the proposed shared auditing scheme (i.e. BCSAD and BCSAI) are better than that of the shared audit scheme.
Finally, we test the computation costs of compared schemes in the retrieval phase. Since only Yuan et al.'s scheme and BCSAI supporting privacy protection, Figure 9 show the time costs of other schemes are 0, which means that the data users can directly download plaintext from CS, while Yuan et al.'s scheme and BCSAI need extra time costs to decrypt the outsourced encrypted data to plaintext.

Conclusion
Benefit from the blockchain, we propose a cross-user shared auditing mechanism, called BCSA, that has not been achieved currently. Further, we extend BCSA to two concrete constructions, BCSAD and BCSAI, which are suitable for different data and the same data cross user audit scenarios, respectively. Each of them allows data users to share auditing challenges to reduce auditing fees, and the latter one not only achieves encrypted data deduplication but also guarantees the security of outsourced data against online and offline brute-force attack. Finally, both the security and performance analysis demonstrate the practicability of our schemes.
As we showed, the rise of blockchain brings more possibilities for solving the stubborn problems of traditional public auditing. Therefore, we plan to fully utilise various techniques or tools of blockchain, like smart contract and consensus mechanism, to achieve automatic and efficient data auditing without TPA. Moreover, we will also further study the shared auditing mechanism in future work.

Disclosure statement
No potential conflict of interest was reported by the author(s).