# Analysis of Lightweight Cryptographic Algorithms on IoT Hardware Platform +
## 5 Discussion
Figure 25: Group of 80-bits key size algorithms measuring ENC energy with respect to RR% in UNO versus Pi. (throughput and latency), and ENC energy (throughput and latency). The algorithm with the least sum of all the scores would be considered as the best. For the first list of algorithms presented in Table 1, Figure 26a,b clearly show that LEA-128-128, OMET-64-CHAM-64-128, and Hight-64-128 are the best in UNO, while Speck-48-72, Speck-64-128, and XTEA-64-128 are the best in Pi. Regarding the final list presented in Table 2, Figure 26c,d clearly show that Schwaemm-256-128, GIFT-COFB-128-128, and Schwaemm-128-128 are the best in UNO, while Xoodyak-128-128, TinyAMBU-192-32-192, and TinyJAMBU-128-32-128 are the best in Pi. In addition, the best three are presented using the \"Score Table\" in both UNO and Pi and are shown in Figures 29 and 30 as a radar graph. The best are Schwaemm-256-128, GIFT-COFB-128-128, and Schwaemm-128-128 in UNO and Xoodyak-128-128, TinyJAMBU-192-32-192, and TinyJAMBU-128-32-128 in Pi. Figure 28: Best 8 Algorithms of NIST finalists in ENC energy with respect to RR % for both UNO and Pi. Figure 30: Radar graph of the three NIST finalists winners in 5 measures in Pi. Figure 29: Radar graph of the three NIST finalists winners in 5 measures in UNO. This section provided the analysis and results of 122 ciphers in the RR and Score Table plus the announced NIST finalists analysis alone. The RR percentage showed significant importance in a comparative analysis between the different platforms besides the latencies' metrics cycle per byte and joules per byte. Moreover, one of the reasons that worsens the algorithm is the high number of rounds, as presented in Figures 31 and 32, that provide the worst and best algorithms with their related number of rounds. During the RR analysis, it was realized that most of the algorithms that were worse in Pi than in UNO were of an 80-bits key size. During this work, a number of problems were encountered:  
1. The first problem encountered was the exceeding of the Arduino UNO ROM size by a handful of the algorithms. This issue led to the code optimizing of these algorithms. Some simple code optimization and changes in the declaration minimized most of the exceeded algorithms. For example, in Katan and Kantan, where the encoders were using \(unit64_{t}Ptext\). We used to change it to \(unit8_{t}\) and the size collapsed to fit the SRAM and ROM of Arduino UNO, besides the Pi, and also by decreasing the code size for both boards. \(ESTATE_{T}weGIFT128\)-128-128, \(Romulus\)-\(M1\)-128-128, \(Romulus\)-\(N1\)-128-128, \(SKINNY\)-\(AEAD\)-\(M1\)-128-128, \(SKINNY\)-\(AEAD\)-\(M2\)-128-128, \(SKINNY\)-\(AEAD\)-\(M3\)-128-128, \(SKINNY\)-\(AEAD\)-\(M4\)-128-128, \(SKINNY\)-\(AEAD\)-\(M5\)-128-128, and \(SKINNY\)-\(AEAD\)-\(M6\)-128-128 although were minimized but still could not fit the Arduino ROM, and they were eliminated from the Arduino benchmarking only. 2. Measuring the performance power of the algorithms on the targeted platform requires setting a baseline power for the measured platform in an idle state, i.e., working on no  
Figure 31: The best algorithms and worst throughout with their corresponding number of rounds. Brown color indicates the worst algorithms in previous measures. Figure 32: All algorithms of NIST finalists with their corresponding number of rounds. Brown color indicates the worst algorithms in previous measures. load or process. After that, the power consumed by the measured algorithm would be the difference between the baseline and the mean measured power. \[\mathit{Power}_{\mathit{consumed}}=\mathit{Measured}_{\mathit{power}}-\mathit{ Idle}_{\mathit{power}} \tag{8}\]  
However, during the measuring procedure of the Arduino platform, the resulting algorithms' power started to diminish until they changed to negative values. This problem led to rolling back to check the precision of the baseline power.