# Empirical Evaluation of TLS-Enhanced MQTT on IoT Devices for V2X Use Cases
## 5 Performance Evaluation
### Symmetric Encryption Evaluation  
The symmetric encryption evaluation focuses on quantifying and comparing the impact of AES_256_GCM and ChaCha20_Poly1305 on MQTT communication under TLS 1.3. We begin with a direct comparison of the raw encryption speed that both algorithms achieved in an isolated environment. Subsequently, we assess key system metrics on the Raspberry Pi 4\(B\) platform, including CPU utilization, execution time, end-to-end latency, energy consumption, memory usage (maximum RSS), and application-layer goodput--across all defined message packaging scenarios. In particular, we examine performance for the payload of 100 KB under three different message configurations, as well as more demanding configurations with total payloads of 1 MB and 100 MB. This methodology enables a realistic and standard-aligned assessment of symmetric cipher performance in constrained, security-critical V2X environments. The OpenSSL speed benchmark shows the results for standalone cipher throughput as a function of block size in Table 3. AES_256_GCM does not achieve the performance level of Chacha20_Poly1305 when processing small payload sizes. Chacha20_Poly1305 reaches a speed of 80.6 MB/s at 16 B block sizes, while AES_256_GCM operates at 44.6 MB/s speed. The speed difference between Chacha20_Poly1305 and AES_256_GCM broadens significantly as the block sizes increase, where Chacha20_Poly1305 reaches 322.3 MB/s at 8192 B, while AES_256_GCM reaches only 70.6 MB/s resulting in a performance difference of approximately 4.5 times. This trend is also observed in [7], where for a block size equal to 8192 B, we notice the maximum performance difference, while Chacha20_Poly1305 is approximately 3.3\(\times\) faster than AES_128_GCM. This difference between our observations is due to the fact that we are testing the more demanding AES_256_GCM. The system-level performance evaluation measures CPU cycle consumption throughout all message patterns, for the same overall payload, and roles according to Table 4. We \begin{table}
\begin{tabular}{c c c c c c} \hline \hline
**Cipher** & **Bytes** & **16 B** & **64 B** & **256 B** & **1 KB** & **8 KB** \\ \hline AES\_256\_GCM (MB/s) & 44.6 & 53.8 & 65.3 & 68.6 & 70.6 \\ Chacha20\_Poly1305 (MB/s) & 80.6 & 140 & 253.7 & 311.6 & 322.3 \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Cipher speed (MB/s) per block size. observe that the selection of the combination of the number of messages and message size in MQTT communication heavily affects the overhead applied in the IoT device, which aligns with the findings of [7], where all roles are implemented in VMs. We observe that for publisher and subscriber, the differences between Ethernet and WiFi are minimal. In addition, AES_256_GCM is more demanding than Chacha20_Poly1305 across all experimentation, with the biggest overhead being introduced in the publisher for the \(1000\times 100\) B message packaging. Indicatively the publisher needs 1386.6 Mycles to complete transmission for Chacha20_Poly1305, in both wired and wireless setups, which increases to 1436.2 Mycles-ETH (+3.6%) and 1470.1 Mycles-WiFi (+6%) for AES_256_GCM. For \(100\times 1000\) B, it requires approximately 765 Mycles for both algorithms and interfaces, which drops further for the \(10\times 10\),000 B experiment, where 710 Mycles are required. Both the subscriber and broker follow similar patterns, whilst the broker exhibits the highest overhead (+28%) when executed on the wireless setup with the \(1000\times 100\) B message packaging. As presented in Table 5, the execution time of \(1000\times 100\) B for the Ethernet setup, for both publisher and subscriber on Chacha20_Poly1305 and AES_256_GCM, is about 5.5 times slower than \(100\times 1000\) B. This grows further to about 14.8 and 16.5 times for publisher and subscriber, respectively, compared with \(10\times 10\),000 B. Furthermore, \(1000\times 100\) B is more than 2.5 times slower to execute than \(10\times 10\),000 B.