## 6 Performance and Implementation
### Experimental Results  
To evaluate the efficiency of our proposed protocol, we conduct experiments on Ubuntu 16.04 operation system with Intel i5-6200 CPU @ 2.40 GHz and 4 GB memory. We implement the algorithm in C with the Pairing-based Cryptography (PBC) library [37] and the GNU Multiple Precision Arithmetic (GMP) library [38]. We utilize the parameter **a.param**, which provides a symmetric pairing with the fastest speed among all default parameters. The implementation time overhead of the protocol is displayed in following two parts. In the first part, we carry out an experiment to evaluate the tag generation cost of our protocol. We set the number of the group users at 50, and the size of data ranges from 0.2 MB to 2 MB. The order of \(G_{1}\) is set at 160-bit, which has the equivalent security level of 1024-bit RSA. Hence, the number of data blocks ranges from 10,000 to 100,000. Figure 3 depicts the comparison on computation cost for tag generation. From Figure 3, we can see that the phase of tag generation of our protocol is separated into two parts: offline and online. As its computational cost is the most expensive one, the group user \(u_{i}\) can preprocess \(H_{2}(\omega_{j})^{y_{ID_{i}}}\), which can be conducted in offline phase. In the online phase of tag generation, group user \(u_{i}\) needs to compute \(psk_{ID_{i}}^{m_{j}}\) for each data block, which is more practical than [PERSON]'s protocol. The time cost of offline computation of tag generation for 1 MB data file is 150.5 s, while the online time cost is 25.3 s. Without loss of generality, we suppose the blocks are, on average, assigned to group users, which makes the result more acceptable. As we expected that both online and offline time of generating tags increases almost linearly with the increase of the data size. Thus, one shall be able to anticipate the time cost of generating tags for any size of data files. In the second part, we increase the number of challenged data blocks from 50 to 1000 with an increment of 50 for each test to see the time cost of Challenge, Proof-Gen, and Proof-Check steps. We suppose all the users in the group will get involved in generating the tags of the challenged data blocks. Figure 4 demonstrates the time cost of these three parts, which increase with the increase of the number of challenged data blocks, which is consistent with our previous computational analysis, because when the number of challenged data blocks rises, more random values in \(Q\) need to be produced and more \(T_{2}=\left\{T_{2j}\right\}\) need to be computed. The CSP has increasing computation on \(\mu\) and \(\sigma\). According to [9], if the CSP has polluted 1% of the data blocks, the TPA can achieve the probability of CSP's misbehavior detection of at least 99% while only needing to make 460 data blocks for a challenge. We can see that it costs the TPA only about 5.75 s to verify a response and the CSP costs about 1.1 s to generate a response when the number of challenged data blocks is 460. We compare the Proof-Check performance between Li's protocol and our protocol in Table 2. We find that our mechanism requires more checking time compared to Li's protocol. Based on our analysis of computation cost from