# Empirical Evaluation of TLS-Enhanced MQTT on IoT Devices for V2X Use Cases
## 5 Performance Evaluation
### Symmetric Encryption Evaluation
\begin{table}
\begin{tabular}{l l c c c c c c} \hline \hline  & \multirow{2}{*}{**Role**} & \multicolumn{3}{c}{**ChaCha20**} & \multicolumn{3}{c}{**AES-GCM**} \\ \cline{3-8}  & & **1000 x 100 B** & **100 x 1000 B** & **100 x 1000 B** & **100 x 1000 B** & **100 x 1000 B** & **10 x 10,000 B** \\ \hline \multirow{3}{*}{\(\mathbf{\text{Publisher}}\)} & Publisher & 1.398 & 0.256 & 0.095 & 1.407 & 0.258 & 0.095 \\  & Subscriber & 1.395 & 0.251 & 0.085 & 1.405 & 0.253 & 0.085 \\  & Broker & 1.193 & 0.282 & 0.164 & 1.2 & 0.282 & 0.167 \\ \hline \multirow{3}{*}{\(\mathbf{\text{Publisher}}\)} & Publisher & 11.497 & 1.329 & 0.246 & 11.606 & 1.395 & 0.256 \\  & Subscriber & 11.483 & 1.312 & 0.216 & 11.592 & 1.381 & 0.225 \\ \cline{1-1}  & Broker & 9.236 & 1.159 & 0.297 & 9.322 & 1.217 & 0.307 \\ \hline \hline \end{tabular}
\end{table} 
Table 6: Energy consumption (J) during TLS Phase 4 (data encryption): ChaCha20 vs. AES-GCM for 100 KB payload under different message packaging configurations over both Ethernet and WiFi. \begin{table}
\begin{tabular}{l l c c c c c c c} \hline \hline  & \multirow{2}{*}{**Role**} & \multicolumn{3}{c}{**ChaCha20**} & \multicolumn{3}{c}{**AES-GCM**} \\ \cline{3-8}  & & **1000 x 100 B** & **100 x 1000 B** & **10 x 10,000 B** & **100 x 100 B** & **100 x 1000 B** & **10 x 10,000 B** \\ \hline \multirow{3}{*}{\(\mathbf{\text{Publisher}}\)} & Publisher & 0.590 \(\pm\) 0.022 & 0.108 \(\pm\) 0.003 & 0.040 \(\pm\) 0.004 & 0.594 \(\pm\) 0.022 & 0.109 \(\pm\) 0.003 & 0.040 \(\pm\) 0.002 \\  & Subscriber & 0.589 \(\pm\) 0.022 & 0.106 \(\pm\) 0.004 & 0.036 \(\pm\) 0.003 & 0.593 \(\pm\) 0.022 & 0.107 \(\pm\) 0.003 & 0.036 \(\pm\) 0.002 \\  & Broker & 0.634 \(\pm\) 0.021 & 0.150 \(\pm\) 0.004 & 0.087 \(\pm\) 0.007 & 0.638 \(\pm\) 0.023 & 0.150 \(\pm\) 0.004 & 0.089 \(\pm\) 0.005 \\ \hline \multirow{3}{*}{\(\mathbf{\text{Publisher}}\)} & Publisher & 4.853 \(\pm\) 0.095 & 0.561 \(\pm\) 0.020 & 0.104 \(\pm\) 0.004 & 4.899 \(\pm\) 0.155 & 0.589 \(\pm\) 0.032 & 0.108 \(\pm\) 0.005 \\  & Subscriber & 4.847 \(\pm\) 0.094 & 0.554 \(\pm\) 0.022 & 0.091 \(\pm\) 0.004 & 4.893 \(\pm\) 0.155 & 0.583 \(\pm\) 0.032 & 0.095 \(\pm\) 0.005 \\  & Broker & 4.910 \(\pm\) 0.097 & 0.616 \(\pm\) 0.020 & 0.158 \(\pm\) 0.006 & 4.956 \(\pm\) 0.155 & 0.647 \(\pm\) 0.032 & 0.163 \(\pm\) 0.006 \\ \hline \hline \end{tabular}
\end{table} 
Table 5: Execution time (sec) during TLS Phase 4 (data encryption): ChaCha20 vs. AES-GCM for 100 KB payload under different message packaging configurations over both Ethernet and WiFi. subscriber, respectively. In contrast, broker CPU usage exhibits 54.4% and 38.1% increases in the wired and wireless setups. As expected, the large-scale set requires the most cycles. The publisher is from 6.9 to 7.6 times more demanding than the small and medium test's publisher and subscriber in both the wired and wireless setups, while for the broker, we have increases of 64 and 41.4 times for Ethernet and 50 and 36.2 times for WiFi, on the low and medium scales, respectively. AES_256_GCM follows the same trends while remaining heavier throughout the entirety of the experimentation. The maximum overhead is for the 1000 \(\times\) 100 B message packaging, on WiFi, where we observe a 6% increase. Furthermore, we note that as we scale from low- and medium- to high-scale experiments, wireless communication affects the nodes differently. For 100 KB and 1 MB, the broker is mainly affected, while for 100 MB, the publisher is. From Table 8 we infer that AES_256_GCM remains 0.6% to 3.3% slower than Chacha20_Poly1305. In addition, we have uniform overhead in all roles when comparing across scales. For instance, from low to medium scales, we have increases 44.3% to 50.6% for Ethernet and 11.8% to 14.8% for WiFi. The high-volume experiment requires the most time for execution, as it is 55 to 60 times slower than the low-volume one for the wired setup and about 19 times slower for the wireless setup. As has been demonstrated previously, we deduce the end-to-end payload latency from the broker's execution time.