# Client-Aware Negotiation for Secure and Efficient Data Transmission
## 4 Result and Analysis
### Encryption Scheme and Security Analysis  
In the SSL/TLS protocol, cipher suites are used to handle encryption schemes. Two common cipher suites, ECDHE-RSA-AES256-GCM-SHA384 and ECDHE-RSA-AES128-GCM-SHA256, with different security strengths are used to illustrate. The cipher suite describes the algorithm of key exchange (ECDHA), the algorithm of authentication (RSA), data encryption (AES128, AES256), and signature (SHA384, SHA256) used in the current session. The algorithm strength of symmetric encryption is shown in Figure 7b,d,f. In addition, there is a factor that affects the encryption overhead, that is the algorithm and strength of asymmetric encryption used by the certification authority when issuing certificates to clients. The encryption efficiency of asymmetric encryption algorithms is shown in Figure 7a,c,e. Using different algorithms (such as ECDSA or RSA) or different algorithm strengths will result in different security and encryption efficiency. The algorithm strengths are shown in Table 1.  
However, sometimes, in order to reduce the overhead of the full handshake, the encryption scheme used by each IP can be stored locally. In this way, the next time the client logs in, because the IP is available in the client hello message and the cipher suite is set after this message, the cipher suite setting can be completed without the second handshake. At this time, there will be no overhead for the second handshake. If the client needs to modify the encryption scheme, they can also perform a second handshake to change the encryption scheme. Therefore, the CAN based on renegotiation will only generate some small processing overhead in some cases (the method described in the previous paragraph), and in some cases, it will generate the overhead of a full handshake. The redirection-based method will produce a three-way handshake overhead. Because usually the time for data caching (without deleting session-related information) will last for several minutes, the overhead of a handshake during this time is usually negligible. Therefore, the CAN-SEAT strategy can assume that there is no overhead in most cases. However, there are still situations where it is difficult to ignore the overhead. At this time, a specific method may be designed according to the specific situation, such as using the method described in the previous paragraph to avoid the overhead of CAN-SEAT. In this way, it can be considered that the proposed strategy has no overhead in most cases. The security analysis mainly is for the security of the encryption algorithm and the security of the two CAN-SEAT strategies. The strength of the algorithm is shown in Section 2.3. In the actual deployment here, only algorithms with the strength of the near-term or long-term protection algorithm (Table 1) will be deployed. Therefore, the strength of the algorithm can be guaranteed. As for the secondstrategy, in the first stage of CAN based on redirection, only the client identity information is need. Other relevant private information is not transmitted over the network and is therefore secure, and the HTTPS protocol based on Apache + OpenSSL will be used in the later stage, while the continuously maintained security software ensures the most secure communication environment in today's environment. The techniques used by CAN based on renegotiation mainly include renegotiation. There are some weaknesses in the renegotiation technology, so in the latest version of OpenSSL, there have been several security updates to the renegotiation technology [26; 27]. \begin{table}
\begin{tabular}{c c c c} \hline \hline
**Experimental Platform** & **Xilinx Zynq** & **FT-2000+**FTC662** & **Intel I7-6700** \\ \hline RSA signature speed & 3.07\% & 2.13\% & 2.20\% \\ RSA authentication speed & 8.79\% & 7.35\% & 9.95\% \\ AES software encryption speed & 76.08\% & 76.99\% & 74.48\% \\ AES hardware encryption speed & 87.12\% & 95.48\% & 87.49\% \\ \hline \hline \end{tabular}
\end{table}