# Evaluating the Efficiency of Physical and Cryptographic Security Solutions for Quantum Immune IoT
## 6 Results
### Simulation Results for Computational Costs  
Simulations were performed by modeling the execution of the key exchange test runs for the selected cryptoalgorithms from the liboqs testharness as well as for the secrecy coding. To get comparable results, the number of transmitted secrecy coded bits must be equal to the level of bits that agrees with cryptographic algorithms. For NewHope, the security level corresponds to 229 bits (against classical cryptanalysis) and 206 (against quantum analysis), and for Frodo 156 and 142, correspondingly [6]. In our case, we can send the corresponding amount of bits in one physical layer frame that carries 361 secure bits. Physical layer test runs were executed by sending (from Alice to Bob) 1000 data frames, in order to get the average costs for the transmitted bits in one frame.  
The simulated costs are presented in Tables 2 and 3. The results indicate that the energy costs of computations in secrecy coding (SC) are very small (from 3.6% to 0.04%) when compared to the costs of computation in Frodo and NewHope (NH).  
For the secrecy coding, the decoding is significantly (around 33 times) more expensive than encoding. In decoding, the average memory consumption is also more intense. This can be caused by the less optimised code causing more cache misses and/or by the more memory intensive algorithm.  
For the cryptographic algorithms, the power consumption is effectively constant in the simulation. This is because the execution of the test was limited to a single thread, and it fully utilises the CPU it is running on for the duration of the test. Thus, the variation in power consumption during the execution is limited to two factors. First, various instructions such as arithmetic, logical, load/store and vector instructions utilising the execution units of the CPU differently. However, this variation is minimal compared to the difference between the idle and active states of the CPU. Second, various parts of the code having different usage patterns for the components in the memory hierarchy. Apart from the approach where radio receiving is essential, bus and memory utilization is negligible. Furthermore, the applications were run on the ARM CPU cores of the Raspberry Pi platforms and did not use hardware acceleration.  
\begin{table}
\begin{tabular}{l c c c c c c} \hline \hline  & **[PERSON]/[PERSON]** & **[PERSON]/[PERSON]** & **NH/Alice** & **NH/Bob** & **SC/Alice** & **SC/Bob** \\ \hline Execution time & 20.4 s & 12.6 s & 14.0 s & 7.2 s & 7.2 ms & 237.5 ms \\ CPU average power & 190 mW & 190 mW & 190 mW & 190 mW & 190 mW & 190 mW \\ Memory average power & 143 mW & 143 mW & 143 mW & 143 mW & 151 mW & 157 mW \\ System average power & 1183 mW & 1183 mW & 1183 mW & 1183 mW & 1191 mW & 1197 mW \\ Energy & 24.1 J & 14.9 J & 16.6 J & 8.5 J & 8.6 mJ & 284.2 mJ \\ \hline \hline \end{tabular}
\end{table}
Table 2: Costs of key exchange computation for Raspberry Pi 2—the simulation results.  
\begin{table}
\begin{tabular}{l c c c c c c} \hline \hline  & **[PERSON]/[PERSON]** & **[PERSON]/[PERSON]** & **NH/[PERSON]** & **NH/[PERSON]** & **SC/[PERSON]** & **SC/[PERSON]** \\ \hline Execution time & 13.6 s & 8.4 s & 9.3 s & 4.8 s & 5.2 ms & 170.3 ms \\ CPU average power & 252 mW & 252 mW & 252 mW & 252 mW & 252 mW & 252 mW \\ Memory average power & 143 mW & 143 mW & 143 mW & 143 mW & 154 mW & 162 mW \\ System average power & 1715 mW & 1715 mW & 1715 mW & 1715 mW & 1726 mW & 1734 mW \\ Energy & 23.3 J & 14.4 J & 15.9 J & 8.1 J & 9 mJ & 295 mJ \\ \hline \hline \end{tabular}
\end{table}
Table 3: Costs of key exchange computation for Raspberry Pi 3—the simulation results.