## 7 Performance Analysis
### Efficiency Analysis
#### 7.2.2 Simulation Experiments  
The experiment was conducted using the IntelliJ IDE with code based on the Java pairing-based cryptography library. Simulations were performed on a system equipped with an i5-6500 CPU @3.2 GHz, 16 GB of memory, and Windows 10. The computation times, measured in seconds, were evaluated for the algorithms \(AA.KeyGen,CR.Encryption,CN.Encryption,CR.token,CN.Decryption, and \(CR.Decryption\), excluding communication time. According to the theoretical analysis in Table 2, Refs. [18; 29] include outsourcing and proxy key generation as critical components of their schemes. These features significantly influence computational overhead and efficiency, making them key subjects for comparison. As a result, the evaluation of proxy key generation is limited to these two schemes. Figure 3 provides a detailed analysis of the computation overhead for key processes in our scheme. In Figure 3, the computation time for key generation is depicted, where the x-axis represents the number of attributes, and the y-axis shows the computation overhead. Figure 3 illustrates the encryption process, with the x axis indicating the number of encrypted attributes and the y axis displaying the computational overhead. It is observed that the CR's encryption time increases slightly as the number of attributes grows, mainly because of the additional time required to generate share values for access tree leaves, while Lagrange interpolation minimally affects the overall decryption time. Figure 3 shows the decryption time, including \(CR.token\), \(CN.Decryption\), and \(CR.Decryption\). Notably, the CR's decryption time remains constant rather than increasing linearly, highlighting the scheme's efficiency and suitability for resource-constrained devices. Figure 4 compares the time consumed for key generation, encryption, and decryption between our scheme and those in Refs. [18; 29; 30; 31]. In Figure 4, the key generation time of our scheme is higher than that of [29] but lower than those of [18; 30; 31]. Although the theoretical analysis in Table 3 predicts the lowest computation time for our scheme, the observed results reveal a slight discrepancy primarily caused by the hash operation. Each attribute undergoes a hash operation before exponentiation, with an average time of 21.752 ms per operation. As the number of attributes increases, the cumulative cost of these hash operations results in a slightly higher key generation time when compared to [29], which delegates most hash computations to the CA in order to reduce the computational burden on the attribute authority. Moreover, this analysis is further supported by Table 4, which presents the execution times of various cryptographic operations used in the scheme. The table demonstrates how the execution time of each operation--such as hashing, exponentiation, and bilinear pairing--impacts the overall performance. Figure 3: Computation overhead in our scheme: (a) key generation; (b) encryption; and (c) decryption. In Figure 4b, a similar trend is observed for key generation: our scheme's computation time is higher than that of [29] but lower than those of [18; 30; 31]. Theoretically, the combined time for encryption and outsourcing in our scheme should be faster than that in [29] by one \(G_{\mathsf{T}}\) operation. However, the inclusion of \(H(att)\) calculations slightly increases the total time as the number of attributes grows, contributing to the observed performance differences. Reference [29] leverages the public parameter of the attribute to offload the majority of the computational workload to the CA. While this design effectively reduces the computational burden, it results in a high dependency on the CA, which may raise concerns regarding scalability and decentralisation in certain application scenarios. In Figure 4c, we compare our scheme with the studies of [18; 29], as the other schemes do not support proxy key generation. The proxy key generation time for our scheme falls within the middle range, influenced by variations in proxy key generation methods.