# Client-Aware Negotiation for Secure and Efficient Data Transmission
## 4 Result and Analysis
### Application  
In WSNs, data need to be transmitted periodically. To ensure the integrity and security of data transmission, encryption transmission is often required; the amount of data transmitted at this time tends to be not large. In the process of transmitting encrypted data using the browser/server architecture, the amount of data transferred is usually less than 10 MB, so we simulated actual application scenarios with four sizes: 10 KB, 100 KB, 1 MB, and 10 MB. We built both servers and clients on the same Intel Core i7-6700 processor to avoid transmission delays. In this experiment, the client sent the same data several times and the server cleared the data inside the SSL structure after each reception to avoid the influence of session resume. Finally, the server calculates the average receiving time to describe the data processing and transmission times. To accurately describe the processing overhead in the actual application, the client starts by reading the file, and the receiver writes the received data to the file. Notably, for the server, the receive time refers to the time from the handshake until the data are fully written to the file. In this way, the actual cost consists of three parts: handshake time, transfer time, and time to write file. If there is no write time, better experimental results can be obtained because with the same data size, the write time is fixed, which reduces the improvement effect. The actual data processing and transmission times for applications using Intel Core i7-6700 processor are shown in Table 3, with similar results for the three remaining processors. The actual processing and transmission times of the four sizes of data in four scenarios were tested, including the time of handshake, file IO processing, and encrypted data transmission. Among them, symmetric encryption adopted the AES algorithm in Galois Counter Mode (GCM) mode (AEAD), whereas asymmetric encryption adopted the RSA algorithm, whose security strength is reflected in the key size of the algorithm. Specifically, cipher suite ECDHE-RSA-AES256-GCM-SHA384 was adopted in Scenarios 1 and 3, where the key size of the RSA algorithm was 4096 bits, that of the AES algorithm was 256 bits, and that of the SHA algorithm was 384 bits. Scenarios 2 and 4 adopted the cipher suite ECDHE-RSA-AES128-GCM-SHA256, where the key sizes of RSA, AES, and SHA algorithms were 1024, 128, and 256 bits, respectively. Scenarios 1 and 2 adopted software encryption; Scenarios 3 and 4 adopted hardware encryption. In the case of software encryption, the data processing and transmission times can be reduced by 89.41%, 82.43%, 54.08%, and 15.40%, respectively, whereas in the case of hardware encryption, the data processing and transmission times can be reduced by 85.30%, 81.90%, 61.62%, and 24.63%, respectively. In general, the less the amount of data transmitted, the greater the benefit of the CAN-SEAT strategy. The above experience did not consider the overhead brought by CAN-SEAT, because this overhead can usually be avoided by design. However, it is inevitable that there are some situations where the overhead cannot be avoided. Therefore, we forced the use of the CAN based on renegotiation for the above four scenarios to determine how to design the scheme and the benefits of using this strategy when the overhead of the CAN-SEAT strategy cannot be avoided. The results are shown in Table 4. We can compare the two tables to get the overhead of the CAN-SEAT strategy. When the amount of data is small (10 KB), the overhead ratio is about 50%. When the data volume is large (10 MB), the proportion can reach 16.7% at most. However, when comparing Scenarios 2 and 4 in Table 4 with Scenarios 1 and 3 in Table 3, using the CAN-SEAT method can always bring efficiency improvements.