# PriSign, A Privacy-Preserving Single Sign-On System for Cloud Environments
## 7 Performance Analysis
### Experimental Analysis  
We implemented the PriSign scheme using MIRACL [41], Type-III pairing [32], and the Barreto-Naehrig curve (BN-256) [42], and tested the system's performance at the AES-100 bit security level. The source code of our implementation is available at [10]. We ran our implementation on a personal laptop (HUAWEI Matebook 14) with an AMD Ryzen-5 \begin{table}
\begin{tabular}{c c c c} \hline \hline
**Algorithms** & **PriSign** & **[9]** & **[8]** \\ \hline Setup & \(3t_{t_{1}}+(q+2)3\cdot t_{2}+(k+1)3\cdot t_{\tau_{2}}+13\cdot t_{\tau_{p}}\) & \(1t_{t_{1}}+1t_{2}\) & \(1t_{2}\) \\ IssuerReg.1 & \(11t_{t_{1}}+5t_{2}+2t_{\tau_{p}}\) & \(2t_{t_{1}}+2t_{\tau_{2}}+2t_{\tau_{p}}\) & \(2t_{t_{1}}+1t_{2}+2t_{\tau_{p}}\) \\ IssuerReg.CA & \(11t_{1}\) & \(2t_{1}\) & \(2t_{1}\) \\ IssPolKey & \(1t_{\tau_{2}}\) & \(-\) & \(-\) \\ AggrPolKey & \(t\cdot t_{\tau_{2}}+t\cdot k\cdot t_{\tau_{p}}+t\cdot t_{\tau_{p}}\) & \(-\) & \(-\) \\ UserReg.U & \(2t_{t_{1}}+(q+3)t_{\tau_{2}}+2t_{\tau_{p}}\) & \(2t_{t_{1}}+1t_{2}+2t_{\tau_{p}}\) & \(2t_{t_{1}}+1t_{2}+2t_{\tau_{p}}\) \\ UserReg.CA & \(3t_{\tau_{1}}\) & \(2t_{1}\) & \(2t_{1}\) \\ ObtTkt.U & \(17t_{t_{1}}+2(q-1+2)t_{\tau_{2}}+2t_{\tau_{p}}\) & \((22+5)t_{t_{1}}+2t_{\tau_{2}}+4t_{\tau_{p}}\) & \((16+7)t_{t_{1}}+2t_{\tau_{2}}+4t_{\tau_{p}}\) \\ ObtTkt.1 & \(15t_{t_{1}}+(q+2)t_{\tau_{2}}+2t_{\tau_{p}}\) & \((19+5)t_{t_{1}}+3t_{\tau_{p}}\) & \((17+5)t_{t_{1}}+2t_{\tau_{p}}\) \\ SignOn & \(3t_{\tau_{1}}+(2k+1)t_{\tau_{\tau}}\) & \(6t_{\tau_{1}}\) & \(3t_{\tau_{1}}\) \\ Verify & \(2t_{\alpha}+(k+1)t_{\tau_{\tau}}+3t_{\tau_{p}}\) & \(7t_{t_{1}}+1t_{\alpha}+3t_{\tau_{p}}\) & \(8t_{\alpha}+1t_{\alpha}+2t_{\tau_{p}}\) \\ \hline \hline \end{tabular} \(j\): the number of designated verifiers.  
\end{table} 
Table 4: Computation overhead. \begin{table}
\begin{tabular}{c c c c} \hline \hline
**Variates** & **PriSign** & **[9]** & **[8]** \\ \hline \(msk\) & \((q+k+6)|\mathbb{Z}_{p}|\) & \(2|\mathbb{Z}_{p}|\) & \(1|\mathbb{Z}_{p}|\) \\ \(mpk\) & \(3|\mathbb{G}_{1}|+(q+3)|\mathbb{G}_{2}|+(k+2)|\mathbb{G}_{T}|\) & \(6|\mathbb{G}_{1}|+4|\mathbb{G}_{1}|\) & \(4|\mathbb{G}_{1}|+2|\mathbb{G}_{1}|\) \\ \(isk\) & \(3|\mathbb{Z}_{p}|\) & \(1|\mathbb{Z}_{  
4600H with a Radeon Graphics 3.00 GHz CPU, 16 GB RAM, and 512 GB SSD running the Ubuntu Kylin 16.04 operating system. In Figures 13 and 14, we show the computational and storage overheads of all algorithms at \(q=10,l=3,n=5,t=3,k=5\), where each timing result is computed as the average over ten iterations. As shown in Figure 13, the Setup algorithm in the PriSign scheme takes 53.2 s. For ticket seller registration, IssuerReg.1 and IssuerReg.CA cost 85.2 ms and 18.6 ms, respectively. For policy key generation, IsspolKey and AggrPolKey cost 1.5 ms and 47.3 ms, respectively. For user registration, UserReg.U and UserReg.CA cost 13.2 ms and 6.2 ms, respectively. The most frequently used PriSign algorithms are ObTkt, SignOn, and Verify. When obtaining a ticket, ObTkt.U and ObTkt.l cost 55.5 ms and 55.2 ms, respectively, while when accessing the service, SignOn and Verify cost 37.6 ms and 36.6 ms, respectively. The algorithm that consumes the most time is IssuerReg.l, which takes 85.2 ms; fortunately, it only needs to be  
Figure 14: Storage size of algorithms. Figure 13: Execution time of algorithms. executed once for each new issuer. In the algorithm for obtaining tickets, the time required by the user and the issuer is similar, at about 55 ms, while in the sign-on algorithm the time consumed by the user and the verifier is about 37 ms. The above conclusions are consistent with the results in Table 4. In practice, this millisecond time consumption is very friendly to both users and the server. As shown in Figure 14, for the CA, the storage of private key _msk_ and public parameters _mpk_ in the PriSign scheme takes 840 bytes and 7616 bytes, respectively. For the issuer, the storage of the private key _isk_, public key _mpk_, and credential _icred_ takes 120 bytes, 1072 bytes, and 256 bytes, respectively.