## 6 Security Analysis
### Computational and Communication Costs
#### 7.2.2 Computational Cost  
The computational cost of each user in each epoch is shown in Table 4. From the results, it is not difficult to find that the main computational overhead for each user is in the _Local Training and Masking_ phase, because in this phase, each user needs to mask the trained local model gradients and compute three pieces of auxiliary information, and it can also be found that the computational cost of in the _Local Training and Masking_ phase increases with the number of gradients, while the other phases do not increase with it. In addition, we evaluated the computational cost incurred by each user in scenarios involving user dropout. As depicted in Figure 6a, the computational cost per user remained relatively stable, showing no considerable variation as the ratio of users dropping out escalated. The rationale for this conclusion arises from the fact that regardless of the user dropout rate, each user is only required to calculate two auxiliary pieces of information in the worst-case scenario, a computation that takes less than one millisecond. Consequently, despite an  
Figure 5: Accuracy comparison between our scheme and FedAvg under different \(k\) values on CIFAR-10. (**a**) \(k=4\); (**b**) \(k=5\); (**c**) \(k=6\); (**d**) \(k=7\). increase in the proportion of users exiting the system, the computational cost on a single user remains relatively constant. Furthermore, we evaluate the differences in the computational cost between the settings that with verification and non-verification; the result is shown in Figure 7. This result demonstrates that the verification cost in our scheme is very low and stable, with no increases with the number of gradients or users. In addition, it is not difficult to find that the computational cost of each user is only affected by the number of gradients and not the number of users. \begin{table}
\begin{tabular}{c c c c c c c} \hline \hline
**Gradient** & \multirow{2}{*}{**Phase I**} & \multirow{2}{*}{**Phase II**} & \multirow{2}{*}{**Phase III**} & \multirow{2}{*}{**Phase IV**} & \multirow{2}{*}{**Phase V**} & \multirow{2}{*}{**Total**} \\
**Numbers** & & & & & & & \\ \hline \(1\times 10^{5}\) & 0.25 & 0.2 & 149.31 & 0.28 & 2.67 & 152.71 \\ \(2\times 10^{5}\) & 0.22 & 0.22 & 224.09 & 0.2 & 2.59 & 227.32 \\ \(3\times 10^{5}\) & 0.25 & 0.24 & 426.31 & 0.25 & 3.57 & 430.62 \\ \(4\times 10^{5}\) & 0.45 & 0.2 & 553.29 & 0.18 & 3.47 & 557.59 \\ \(5\times 10^{5}\) & 0.38 & 0.2 & 692.21 & 0.21 & 2.46 & 695.49 \\ \hline \hline \end{tabular}
\end{table} 
Table 4: Computation cost of users at each epoch (ms). “Phase I” denotes system initialization. “Phase II” denotes keys broadcasting. “Phase III” denotes local training and masking. “Phase IV” denotes message collecting. “Phase V” denotes verification. Figure 6: Computational and communication costs of each user with different dropout rates, \(|\mathcal{U}|=100\), \(|\mathcal{G}|=1\times 10^{4}\). (**a**) Computational cost with different dropout rates. (**b**) Communication cost with different dropout rates. Figure 7: Computational cost comparison between verification and non-verification for each user. (**a**) \(|\mathcal{U}|=100\), with different numbers of gradients. (**b**) \(|\mathcal{G}|=1\times 10^{5}\), with different numbers of users. To comprehensively evaluate the performance of our proposed scheme, we benchmarked it against existing approaches, namely SA [16], Versa [17], and ESVFL [43]. Comparative results are illustrated in Figure 8. It becomes evident from these results that our proposed scheme significantly reduces computational overhead at the user side compared to alternative methods. Precisely, our scheme decreases computational costs by at least 85% and 89% relative to SA and Versa, respectively.