## 6 Summary Comparison: Functionality and Performance
### Communication and Computation Cost Comparison  
To accurately assess and compare the computational and communication overheads, incorporating benchmarks from recent work in [8] for consistent performance evaluation, we define specific terminology for operational timings. Specifically, \(T_{em}\), \(T_{ae}\), \(T_{h}\), \(T_{me}\), \(T_{md}\), \(T_{mac}\), \(T_{ae}\), \(T_{ad}\), \(T_{ch}\), and \(T_{fe}\) represent the execution times for elliptic curve scalar multiplication, elliptic curve point addition, a generic hash function operation, MSR encryption [8], MSR decryption [8], message authentication code computation, AES encryption, AES decryption, Chebyshev map operation, and Fuzzy extractor operation, respectively. Table 4 details these operational runtimes alongside their respective running platforms. Furthermore, to quantify the communication costs incurred during the login and authentication processes, Table 5 outlines the lengths of various security parameters.  
As depicted in Table 6, the comparative analysis incorporates seven cryptographic protocols [6; 7; 8; 35; 38; 39], focusing on their computational and communication costs. The proposed 2 FAKA-C/S protocol showcases its competitive edge, with a total running time of 62.644 ms, aligning closely with the fastest protocols like [PERSON] et al. [8] at 62.985 ms and significantly outperforming [PERSON] et al. [39], which has the longest duration at 172.662 ms. This underscores the proposed protocol's efficiency in high-speed processing scenarios.  
\begin{table}
\begin{tabular}{l c} \hline \hline
**Parameter** & **Length/Bits** \\ \hline MAC (Message Authentication Code) & 160 \\ Timestamp & 32 \\ User identity & 32 \\ Random number & 128 \\ Elliptic curve point & 160 \\ The output of the hash function & 160 \\ Symmetric ciphertext & 128 \\ \hline \hline \end{tabular}
\end{table}
Table 6: Communication and computation costs in the login and authentication phase.  
\begin{table}
\begin{tabular}{c c c c c c c c c c c} \hline \hline  & \(T_{em}\) & \(T_{ea}\) & \(T_{h}\) & \(T_{me}\) & \(T_{md}\) & \(T_{mac}\) & \(T_{ae}\) & \(T_{ad}\) & \(T_{ch}\) & \(T_{fe}\) \\ \hline \(U_{i}\) & 27.472 & 0.041 & 0.006 & 0.016 & 0.560 & 0.118 & 0.023 & 0.014 & 21.02 & 27.472 \\ \(S_{j}\) & 3.823 & 0.007 & 0.002 & 0.003 & 0.058 & 0.028 & 0.010 & 0.006 & 21.02 & 3.823 \\ \hline Terminal & \multicolumn{8}{c}{Running platform} \\ \hline \(U_{i}\) & \multicolumn{8}{c}{Raspbian with 1.2-GHz Quad-Core CPU and 1-GB RAM} \\ \(S_{j}\) & \multicolumn{8}{c}{Ubuntu 16.04 LTS with Intel Core i5 7600, 3.5 GHz CPU and 16 GB memory} \\ \hline \hline \end{tabular}
\end{table}
Table 4: Summarized runtime of all cryptographic operations (ms).  
\begin{table}
\begin{tabular}{l c} \hline \hline
**Parameter** & **Length/Bits** \\ \hline MAC (Message Authentication Code) & 160 \\ Timestamp & 32 \\ User identity & 32 \\ Random number & 128 \\ Elliptic curve point & 160 \\ The output of the hash function & 160 \\ Symmetric ciphertext & 128 \\ \hline \hline \end{tabular}
\end{table}
Table 5: Length of the safety parameters.  
In terms of communication overhead, the proposed protocol requires only 800 bits, which is more efficient compared to the highest overhead of 3328 bits by [PERSON] et al. [39]. This efficiency is essential in environments where bandwidth is limited. For instance, [PERSON] et al. [35] requires 960 bits, which is significantly higher than our protocol. Similarly, [PERSON] et al. [38] requires 864 bits, which is also higher than our protocol. This comparison underscores the proposed protocol's suitability for bandwidth-constrained environments, making it a particularly effective solution.  
In conclusion, the proposed protocol emerges as an eminent solution for secure communication, markedly enhancing processing speed and reducing the communication costs of the proposed protocol.