#
Analysis of Lightweight Cryptographic Algorithms on IoT Hardware Platform^{ †}

^{1}

^{2}

^{3}

^{*}

^{†}

^{‡}

## Abstract

**:**

## 1. Introduction

## 2. Background

## 3. Method and Experimental Setup

#### 3.1. Algorithms Used for Evaluation

#### 3.2. Compilation

#### 3.3. Measuring Concepts and Metrics

- Arduino IDE is used during the uploading phase of C codes onto Arduino Board to measure:
- ROM occupation: by observing “program storage space” where the Arduino sketch is stored.
- RAM occupation: by observing the unused space for local variables, then the used space would indicate the “global variable” of dynamic memory that is the SRAM (static random-access memory), which is where the sketch creates and manipulates variables when it runs.

- Encryption and decryption speed throughput are measured in bytes/s in both platforms through programming loops and Equation (1).$$\frac{Ps}{\tau}(\mathrm{bytes}/\mathrm{s})$$$Ps$ is the size of text in ENC or DEC in bits.$\tau $ is the time taken during one ENC or DEC.
- Key schedule speed throughput concerning key expansion and Equation (2).$$\frac{Ks}{\tau}(\mathrm{bytes}/\mathrm{s})$$$Ks$ is the size of text in expanded key in bits.
- ENC and DEC speed latency are measured in B/s(cycles/block) by using speed throughput Equation (2):$$\frac{f}{\left(1\right)/Bs}(Cycles/Block)=\frac{f\ast Bs\ast \tau}{Ps}(Cycles/Block)$$f is the processor frequency in hertz.$Bs$ is the block size of the algorithm in bytes.
- Key scheduling speed latency derived from Equation (2):$$\frac{f\ast K\ast \tau}{Ks}(Cycles/Block)$$K is key size of the algorithm in bytes.
- ENC and DEC power (throughput) measured in joules/s (j/s) by using a current sensor (power sensor).
- ENC and DEC energy (power
**latency**) in joules/bit is measured by using energy throughput and speed throughput as:$$\frac{ETh(j/s)}{\left(1\right)\ast 8}(Jouls/bit)=\frac{ETh\ast \tau}{Ps\ast 8}(Jouls/bit)$$$ETh$ is energy throughput in j/s of ENC and DEC.

#### 3.4. Methodology

- The following methods were used while benchmarking the different metrics for the selected cryptographic algorithms:
- Different Cryptographic Algorithms, Same Platform: Comparing different algorithms on the same platform is performed by measuring the throughput in bytes per second that would be satisfactory.
- Same Cryptographic Algorithms, Different Platform: Looking at timing information mainly has one of two incitements, either the interest in comparing the performances of two algorithms or the quantity of information being processed through a particular platform. However, measuring in bytes per second has no actual indication of algorithm performance on different platforms. Hence, it is preferred to measure the processor clock cycle during the processing task of each byte, indicated as cycles per bytes, which allows for more relevant comparisons. It is performed simply by dividing the clock speed in hertz which is the cycles per second (C/S) by the speed throughput of the algorithm in bytes per second (B/S), yielding cycles per byte (C/B).
- Different Cryptographic Algorithms, Different Platform: The difference in key size and block among cryptographic algorithms can be assessed using bytes per second as a metric of measurement in the same platform. However, this cannot be used in different platforms (and neither can cycles per byte). Here, comes the notion of using cycle per block as a comprehensive measure of comparison between them.

- Relative Reference (RR): Nevertheless, the last comparison measurement is restrained by the enormous difference in results, speed throughputs, speed latency, and even that of energy, as will be seen in Section 4. The relative reference algorithm (RR) is used by taking the percentage of each measurement result (latency and throughput) of the algorithms, then comparing them to 1 or 100%. On that account, AES-128block-128key, AES-128-192, and AES-128-256 are selected, the traditional standard, which will be a notable solution in this kind of comparison.
- Repeating the Experiments: For numerous distinctive reasons, it can be decently troublesome to obtain measuring results such as time and speed accurately in a single iteration of coding. Frequently, internal clocks that the software or executed program can read have some degree of asynchronous precision from the core processor clock. More essentially, there is regularly a critical overhead included in such measuring results, such as the cost of context switches and sometimes timing overhead. That is, finding measurement of algorithms in this context should avoid procedure call overhead. One method is to run the algorithm many times like loops in coding, then averaging the total time to acquire the best indication of overall performance results. Furthermore, the repetition of encryption or decryption process would smooth out random effects such as IRQ (Interrupt request) signal due to external activity by adjusting the loop to an experimental number attained.On that account, the formulas of speed throughput of ENC and DEC followed by key schedule formulas would be refined as:$$\frac{Ps\ast Nl}{\tau}(\mathrm{bytes}/\mathrm{s})$$$$\frac{Ks\ast Nl}{\tau}(\mathrm{bytes}/\mathrm{s})$$$Nl$ is number of loops.
- Mean and Standard Deviation: As mentioned before, the algorithms’ speed and power are the averages (averaging the total time) of many running times in loops (1000 times). This process is repeated 100 to 1000 times as needed to reach an acceptable standard deviation of the averages obtained (1000 of 1000). The means and standard deviations related to speed and power, including key schedule speed of the algorithms, are provided in the github.
- Programming Libraries: We have implemented the needed formulas in one programming library named metrics.h for both platforms. The metrics.h library contains the implementation of Equations (3)–(7) for exclusive grouping results of the algorithms in one hand pack. In addition, changing the number of loops would be very easy using such a method for simplicity in work and other tasks. Furthermore, for the Raspberry Pi platform, the metrics.hlibrary includes the exporting of the result in “.csv” (a mode of extension file) in one hit for all studied algorithms in speed measures that would help significantly in any re-benchmarking of the algorithms when needed. Meanwhile, “.csv” exporting cannot work for the Arduino platform in programming. A software tool as an add-on for Microsoft Excel is used called PLX-DAQ [38]. Parallax Data Acquisition tool (PLX-DAQ) is a software that drops the numbers into columns as they arrive from the PC’s serial port and it has the following features:
- Plot or graph data as it arrives in real-time using Microsoft Excel.
- Record up to 26 columns of data.
- Mark data with real time (hh:mm:ss) or seconds since reset.
- Read/write any cell on a worksheet.
- Baud rates up to 128K.

Besides that, PLX-DAQ has shown a significant benefit in measuring power and graphical observation of it. - Power Connection: Power (energy) is measured through the use of the Adafruit INA219 [39] current sensor. This measuring process requires another Arduino board to read the sensor data of measuring that is fed from the load to the platforms (Arduino UNO and Raspberry Pi). The second Arduino board is used as a current-voltage monitor. The monitoring process is combined by PLX-DAQ software tool through EXCEL with the necessary Arduino programming. The circuit connection is shown in Figure 1.

- 7.
- Hardware Platform: We used two different hardware platforms in this study for comparison and benchmarking purposes:
- ATMEGA328P is a single-chip microcontroller of the megaAVR family with an 8-bit RISC processor core architecture. It is used in basic Arduino boards, such as Arduino UNO.
- Raspberry Pi 3 Model B V1.2 is the third generation of Raspberry Pi.
- Ammeter (power measurement) used: Power (energy) is measured through the use of the Adafruit INA219 current sensor. One advantage about this sensor is that it is inserted on the “high side” of the circuit instead of the ground side, which is how many of those voltage and current display modules are wired. That makes it ideal for use as a voltage and current display. It operates on a power supply of 5 volts, which can be supplied by the Arduino UNO too.

- 8.
- Methodology for conducting the performance analysis The methodology for conducting a performance analysis of lightweight cryptographic algorithms implemented on a Raspberry Pi or Arduino UNO can involve the following steps:
- (a)
- Selection of algorithms: Identify and select a set of lightweight cryptographic algorithms that are relevant to the application and that can be implemented on a Raspberry Pi/UNO.
- (b)
- Implementation: Implement the selected algorithms on a Raspberry Pi/UNO using a programming language such as Python or C. Data collection: Collect performance data by running the implemented algorithms on the Raspberry Pi and measuring the execution time and memory usage for each algorithm.
- (c)
- Data analysis: Analyze the collected data to determine which algorithms are the most efficient and secure for the given application. This may involve comparing the execution time and memory usage of the algorithms, as well as analyzing any security weaknesses or vulnerabilities in the algorithms.
- (d)
- Optimization: Based on the analysis, optimize the implementation of the chosen algorithm to minimize resource usage and increase security. Reporting: Prepare a report detailing the performance analysis and optimization results, including any recommendations for further research or improvement. The whole process is illustrated below:

## 4. Results

- The ROM, RAM, code size, and key schedule speed throughput and latency of the 39 ciphers.
- The number of rounds, encryption/decryption speed throughput/latency, and energy throughput/latency of all the 119 ciphers.

- Analysis of the number of rounds: As part of the algorithm design, modern ciphers increase their security (confusion and diffusion) through the repeated execution (n times) of a simple round function. In block ciphers, the input and output of the round function are equal to the cipher block size in general. As a standard rule, increasing the number of rounds n increases the security level, while decreasing the number of rounds would play a significant role in shortening the execution time of the encryption and decryption, which is one of the essences of lightweight cryptography. In this project, the range interval of the number of rounds of the studied algorithms is [8, 254], as shown in Figure 2. Among the five ciphers with the largest number of rounds, the Katan–Ktantan family is designed with the highest, while the Ace-64-128 and TinyJambu families are with the least among the smallest 10.

- 2.
- Analysis of code size: The code size is the size of the algorithm code written in C language. It is the occupied space on the disk or memory. Moreover, it might project the occupation of the ROM and RAM sizes. Many of the cipher implementations were optimized in coding for different considerations, among them, of significant importance, was changing the plaintext declaration in a way that takes no more space than what is required. According to the results illustrated in Figure 3, the range intervals of the code sizes are [3.6, 21] and [3.49, 17.3] in Kbytes for UNO and Pi, respectively. Of the 10 smallest code sizes, the least are Katan-32-80 and Present-64-128, whereas the biggest are Piccolo-64-80 and Rectangle-64-128 in UNO and Pi, respectively.

**Figure 3.**Code size of algorithms used in benchmarking. (

**a**) The 10 algorithms of DEC smallest code sizes and 5 of largest. (

**b**) The 10 algorithms of smallest ENC code sizes and 5 of largest. (

**c**) The 10 Algorithms of smallest code sizes and 5 of largest.

- 3.
- Analysis of ROM size: Read-only memory or ROM is a non-volatile memory. Data stored in ROM are generally the code and the tables that do not need modifications. The Arduino Uno (ATMEGA328P) ROM size (Flash) used is 32 Kbytes in size, while the Pi’s is a variable SD card where 64 Gbytes is used in this project. The Arduino IDE fulfills the ROM measurement requirement that gives the occupied size of the storage space. However, in Pi, the “size” command is used in the terminal (Linux OS) as a tool to obtain the text, data, Block Started by Symbol (BSS) (Block Started by Symbol is the space that contains all the uninitialized data), and DEC sizes (DEC = text + data + BSS) of the compiled code file in an Extensible Linking Format (ELF) extension. The range interval is [1.48, 6.05] and [3.81, 9.67] in Kbytes for UNO and Pi, respectively. Figure 4 and Figure 5 show the least cipher-demanding ROM among the 10 smallest which are the LEA family/Prince-64-128 and Present-64-80, respectively, for UNO and Pi, while the biggest demand is Piccolo-64-80 for both platforms.

- 4.
- Analysis of RAM occupation: Random-access memory (RAM) is the short-term memory where data are stored to be processed by the processor. Data are stored in the RAM in the form of a heap and stack. The size of UNO’s RAM (SRAM) used is 2Kbytes, whereas the Pi’s is 1Gbytes. The Arduino IDE is sufficient for obtaining the RAM usage by the ciphers. However, the Valgrind [40] tool is used to measure the RAM occupation in Pi. Valgrind is a tool suite for debugging and profiling, and the Massif profiler tool of the Valgrind is used to measure the RAM. Figure 6 and Figure 7 show the 10 smallest and 5 largest RAM size occupations in UNO and Pi, respectively. As it can be seen, the range intervals are [264, 994] in bytes and [1.03, 21.34] in Kbytes of UNO and Pi, respectively. The least are the LEA and the Simon–Speck families, and the largest are the Ktantan family and Rectangle-64-128 in UNO and Pi, respectively.

- 5.
- Key scheduling speed: The key schedule is a process of key expansion that expands a short key (40 to 256 bits) to a larger key (or to a number of round keys) (100 to 1000 s bits) for use in encryption and decryption algorithms. This process in ciphers has a direct impact on the security of the cipher. The key schedule speed was measured using C programming routines that calculate the time taken. Formulas (2) and (4) mentioned in Section 3.3 are used for the throughput in bytes per second and latency in cycles per block, respectively. Figure 8, Figure 9, Figure 10 and Figure 11 exhibit the 10 largest and 5 smallest algorithms for the key schedule speed in UNO and Pi, respectively. The range intervals are [0.99, 400,000] in Kbytes/s and [0.029, 106.667] in Gbytes/s of UNO and Pi, respectively, for the throughput. The best is Prince-64-128, and the worst is the Ktantan family in both UNO and Pi. Further, the range intervals for the latency are [0.00032, 161.34] in Kcycles/block and [0.18, 412.02] in cycles/block of UNO and Pi, respectively. The best is XTEA-64-128, and the worst is the Ktantan family in both UNO and Pi.

- 6.
- Encryption and decryption speed: The encryption or decryption speed measuring tool is by the internal programming (C) of the time taken. Formulas (6) and (3) mentioned in Section 3.3 are used for the throughput in bytes per second and latency in cycles per block, respectively.Figure 12, Figure 13, Figure 14 and Figure 15 reveal the 10 largest and 5 smallest algorithms for the ENC speed in UNO and Pi, respectively. The range intervals are [0.1, 64.1] in Kbytes/s and [0.009, 6.99] in Gbytes/s of UNO and Pi, respectively, for the throughput. The best are Hight-64-128 and LEA-128-128; however, the worst are Jumbo-128-128 and Ktantan-32-80 in UNO and Pi, respectively (here the biggest is the fastest). The range intervals for the latency are [2, 2490.24] in Kcycles/block and [1.44, 864.65] in cycles/block of UNO and Pi, respectively (for the latency, the smallest is the best and the fastest). The best are Hight-64-128 and Speck-48-72, though the worst are Jumbo-128-128 and ISAP-K-128-64-128 in UNO and Pi, respectively.

- 7.
- Encryption and decryption power and energy consumption: Energy utilization is the measure of the electrical effort used during the execution of an operation (algorithm), and the whole energy consumed is the time integral of the power. In lightweight cryptography, energy consumption per unit operation of the algorithm defines good metrics for designing. The measuring tool used for energy in this project is the Adafruit INA219 current sensor through a connection of a second Arduino board used as a current-voltage monitor. The monitoring process is combined by the PLX-DAQ software tool through EXCEL with the necessary Arduino programming. The provided Formula (5) in Section 3.3 is used for the energy in joules per byte while the mean power obtained from sensor monitoring is the power throughput in joules per second.Figure 16, Figure 17, Figure 18 and Figure 19 show the 10 smallest and 5 largest algorithms for the ENC power. The range intervals are [0.959, 14.28] in mj/s and [168, 303] in mj/s for the power. The least are SUNDAE-GIFT-0-128-128 and XTEA-64-128. However, the worst are Simon-128-256 and DryGASCON128k56-128-128 in UNO and Pi, respectively. The range intervals for the energy are [0.097, 67.4] in µj/byte and [35.4, 26,870] in nanoj/byte (or [0.035, 26.87] in µj/byte) of UNO and Pi, respectively. The least are SUNDAE-GIFT-0-128-128 and Speck-128-128, though the worst are Rectangle-64-128 and Ktantan-32-80 in UNO and Pi, respectively.

## 5. Discussion

**Figure 20.**Group of 128-bits block size algorithms measuring key schedule speed latency with respect to RR% in UNO versus Pi.

**Figure 21.**Group of 96-bits key size algorithms measuring key schedule speed latency with respect to RR% in UNO versus Pi.

**Figure 22.**Group of 32-bits block size algorithms measuring ENC speed latency with respec to RR% in UNO versus Pi.

**Figure 23.**Group of 256-bits key size algorithms measuring ENC speed latency with respect to RR% in UNO versus Pi.

**Figure 24.**Group of 128-bits block and key sizes algorithms measuring ENC energy with respect to RR% in UNO versus Pi.

**Figure 25.**Group of 80-bits key size algorithms measuring ENC energy with respect to RR% in UNO versus Pi.

#### Finalists of NIST

- 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 Ktantan, where the encoders were using $unint{64}_{t}Ptext$. We used to change it to $unint{8}_{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. $ESTAT{E}_{T}weGIFT128\text{-}128\text{-}128,$ $Romulus\text{-}M1\text{-}128\text{-}128,$ $Romulus\text{-}N1\text{-}128\text{-}128,$ $SKINNY\text{-}AEAD\text{-}M1\text{-}128\text{-}128,$ $SKINNY\text{-}AEAD\text{-}M2\text{-}128\text{-}128,$ $SKINNY\text{-}AEAD\text{-}M3\text{-}128\text{-}128,$ $SKINNY\text{-}AEAD\text{-}M4\text{-}128\text{-}128,$ $SKINNY\text{-}AEAD\text{-}M5\text{-}128\text{-}128,\mathrm{and}$ $SKINNY\text{-}AEAD\text{-}M6\text{-}128\text{-}128$ although were minimized but still could not fit the Arduino ROM, and they were eliminated from the Arduino benchmarking only.
- 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 load or process. After that, the power consumed by the measured algorithm would be the difference between the baseline and the mean measured power.$$Powe{r}_{consumed}=Measure{d}_{power}-Idl{e}_{power}$$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. Thus, the tactic was measuring over time (1 h), from the cool down, the behavior of the platform power in idle mode and then with the load mode (algorithm). The resulting graphs of UNO are shown in Figure 33 and Figure 34 in the two modes.The Raspberry Pi has gone through the same process where Figure 35 and Figure 36 reveal the resulting graphs. The graphs show that after 25 min of starting Arduino in the idle mode, a plateau is observed, whereas in the load mode the graph goes to a plateau after 30 min. Consequently, repeating the measurement by respecting 30 min intervals from the start led to the results interpreted in Section 4, while the Pi graphs show no need for a repeat or respecting any criteria. Furthermore, the speed measurement of UNO was re-benchmarked respecting a 30 min interval.

## 6. Conclusions and Future Work

- Arduino mega could be considered in the analysis for the algorithms that exceeded the memory ROM in ATMEGA328P UNO.
- The NIST finalists were not compared between UNO and Pi with respect to the key schedule, ROM, RAM, and code size, so as a future work these comparisons could be performed.
- Stream ciphers and hash functions algorithms could be added to the analysis.
- Using the AES as a relative reference was taken as a linear approach. As future work, it could be established from another approach or approximation after adequate research in such a field and also depending on the behavior of the chosen algorithms.
- It is important to note that the performance of the algorithm can also be affected by environmental factors, such as the temperature of the Pi/UNO. So, this factor should also be considered while conducting the performance analysis in future works.

## Author Contributions

## Funding

## Data Availability Statement

## Conflicts of Interest

## Abbreviations

LWC | Lightweight Cryptography |

LW | Lightweight |

AE | Authenticated Encryption |

AEAD | Authenticated Encryption with Associated Data |

AES | Advanced data Encryption Standard |

ARM | Advanced Reduced Instruction Set Computing Machine |

ARX | Addition/Rotation/XOR |

AVR | Alf and Vegard’s RISC |

DEC | Decryption |

DES | Data Encryption Standard |

DF | Diffie–Hellman key exchange |

ENC | Encryption |

FN | Feistel Networks |

GFN-2 | Type-2 Generalized Feistel Network |

GFS | Generalized Feistel Structure |

HIGHT | High security and Light Weight |

UNO | Arduino |

LEA | Lightweight Encryption Algorithm |

MAC | Message Authentication Code |

MD5 | Message Digest 5 |

MSP | Main distribution/Service Panel |

P | Permutation |

RAM | Random-Access Memory |

RFID | Radio Frequency Identification |

ROM | Read-Only Memory |

RPi or Pi | Raspberry Pi |

RR | Relative Reference |

LD | Linear Dichroism |

SHA-2 | Secure Hash Algorithm 2 |

specs | Specifications |

SPN | Substitution-Permutation Network |

XTEA | eXtended Tiny Encryption Algorithm |

IDE | Integrated Development Environment |

$Ps$ | The size of text in ENC or DEC. |

$\tau $ | The time taken during one ENC or DEC. |

$Ks$ | The size of text in expanded key. |

f | The processor frequency in hertz. |

$Bs$ | The block size of the algorithm in bytes. |

$ETh$ | Energy throughput in j/s of ENC and DEC. |

$Nl$ | Number of loops. |

## References

- El-Hajj, M.; Fadlallah, A.; Chamoun, M.; Serhrouchni, A. A survey of internet of things (IoT) Authentication schemes. Sensors
**2019**, 19, 1141. [Google Scholar] [CrossRef] [PubMed] [Green Version] - El-hajj, M.; Chamoun, M.; Fadlallah, A.; Serhrouchni, A. Analysis of authentication techniques in Internet of Things (IoT). In Proceedings of the 2017 1st Cyber Security in Networking Conference (CSNet), Rio de Janeiro, Brazil, 18–20 October 2017; pp. 1–3. [Google Scholar]
- El-Hajj, M.; Fadlallah, A.; Chamoun, M.; Serhrouchni, A. A taxonomy of PUF Schemes with a novel Arbiter-based PUF resisting machine learning attacks. Comput. Netw.
**2021**, 194, 108133. [Google Scholar] [CrossRef] - El-Haii, M.; Chamoun, M.; Fadlallah, A.; Serhrouchni, A. Analysis of Cryptographic Algorithms on IoT Hardware platforms. In Proceedings of the 2018 2nd Cyber Security in Networking Conference (CSNet), Paris, France, 24–26 October 2018; pp. 1–5. [Google Scholar]
- Eisenbarth, T.; Gong, Z.; Güneysu, T.; Heyse, S.; Indesteege, S.; Kerckhof, S.; Koeune, F.; Nad, T.; Plos, T.; Regazzoni, F.; et al. Compact Implementation and Performance Evaluation of Block Ciphers in ATtiny Devices. In Progress in Cryptology—AFRICACRYPT 2012; Mitrokotsa, A., Vaudenay, S., Eds.; Springer: Berlin/Heidelberg, Germany, 2012; pp. 172–187. [Google Scholar]
- Ibrahim, N.F.; Agbinya, J.I. A Review of Lightweight Cryptographic Schemes and Fundamental Cryptographic Characteristics of Boolean Functions. Adv. Internet Things
**2021**, 12, 9–17. [Google Scholar] [CrossRef] - Daemen, J.; Rijmen, V. AES Proposal: Rijndael. 1999. Available online: https://www.cs.miami.edu/home/burt/learning/Csc688.012/rijndael/rijndael_doc_V2.pdf (accessed on 12 January 2023).
- Rivest, R.L.; Shamir, A.; Adleman, L. A method for obtaining digital signatures and public-key cryptosystems. Commun. ACM
**1983**, 26, 96–99. [Google Scholar] [CrossRef] [Green Version] - Suzaki, T.; Minematsu, K.; Morioka, S.; Kobayashi, E. Twine: A lightweight, versatile block cipher. In Proceedings of the ECRYPT Workshop on Lightweight Cryptography, Louvain-la-Neuve, Belgium, 28–29 November 2011; Volume 2011. [Google Scholar]
- Poschmann, A.Y. Lightweight Cryptography: Cryptographic Engineering for a Pervasive World. Ph.D. Thesis, Ruhr-University Bochum, Bochum, Germany, 2009. [Google Scholar]
- Beaulieu, R.; Shors, D.; Smith, J.; Treatman-Clark, S.; Weeks, B.; Wingers, L. The SIMON and SPECK lightweight block ciphers. In Proceedings of the 52nd Annual Design Automation Conference, San Francisco, CA, USA, 7–11 June 2015; p. 175. [Google Scholar]
- Avanzi, R. The QARMA block cipher family. Almost MDS matrices over rings with zero divisors, nearly symmetric even-mansour constructions with non-involutory central rounds, and search heuristics for low-latency s-boxes. IACR Trans. Symmetric Cryptol.
**2017**, 2017, 4–44. [Google Scholar] [CrossRef] - El Hadj Youssef, W.; Abdelli, A.; Dridi, F.; Machhout, M. Hardware implementation of secure lightweight cryptographic designs for IoT applications. Secur. Commun. Netw.
**2020**, 2020, 8860598. [Google Scholar] [CrossRef] - Guo, J.; Peyrin, T.; Poschmann, A.; Robshaw, M. The LED block cipher. In Proceedings of the International workshop on cryptographic hardware and embedded systems, Nara, Japan, 28 September–1 October 2011; Springer: Berlin/Heidelberg, Germany, 2011; pp. 326–341. [Google Scholar]
- Shibutani, K.; Isobe, T.; Hiwatari, H.; Mitsuda, A.; Akishita, T.; Shirai, T. Piccolo: An ultra-lightweight blockcipher. In Proceedings of the International Workshop on Cryptographic Hardware and Embedded Systems, Nara, Japan, 28 September–1 October 2011; Springer: Berlin/Heidelberg, Germany, 2011; pp. 342–357. [Google Scholar]
- Bogdanov, A.; Knudsen, L.R.; Leander, G.; Paar, C.; Poschmann, A.; Robshaw, M.J.; Seurin, Y.; Vikkelsoe, C. PRESENT: An ultra-lightweight block cipher. In Proceedings of the International Workshop on Cryptographic Hardware and Embedded Systems, Vienna, Austria, 10–13 September 2007; Springer: Berlin/Heidelberg, Germany, 2007; pp. 450–466. [Google Scholar]
- Benadjila, R.; Guo, J.; Lomné, V.; Peyrin, T. Implementing lightweight block ciphers on x86 architectures. In Proceedings of the International Conference on Selected Areas in Cryptography, Burnaby, BC, Canada, 14–16 August 2013; Springer: Berlin/Heidelberg, Germany, 2013; pp. 324–351. [Google Scholar]
- Kim, B.; Cho, J.; Choi, B.; Park, J.; Seo, H. Compact implementations of HIGHT block cipher on IoT platforms. Secur. Commun. Netw.
**2019**, 2019, 5323578. [Google Scholar] [CrossRef] - Hong, D.; Sung, J.; Hong, S.; Lim, J.; Lee, S.; Koo, B.S.; Lee, C.; Chang, D.; Lee, J.; Jeong, K.; et al. HIGHT: A new block cipher suitable for low-resource device. In Proceedings of the International Workshop on Cryptographic Hardware and Embedded Systems, Yokohama, Japan, 10–13 October 2006; Springer: Berlin/Heidelberg, Germany, 2006; pp. 46–59. [Google Scholar]
- Diehl, W.; Farahm, F.; Yalla, P.; Kaps, J.; Gaj, K. Comparison of hardware and software implementations of selected lightweight block ciphers. In Proceedings of the 2017 27th International Conference On Field Programmable Logic And Applications (FPL), Ghent, Belgium, 4–8 September 2017; pp. 1–4. [Google Scholar]
- Hafer, L.; Parker, A. Register-transfer level digital design automation: The allocation process. In Proceedings of the 15th Design Automation Conference, Las Vegas, NV, USA, 19–21 June 1978; pp. 213–219. [Google Scholar]
- Beaulieu, R.; Shors, D.; Smith, J.; Treatman-Clark, S.; Weeks, B.; Wingers, L. SIMON and SPECK: Block Ciphers for the Internet of Things. Cryptol. ePrint Arch.
**2015**. Available online: https://eprint.iacr.org/2015/585.pdf (accessed on 12 January 2023). - Abed, S.; Jaffal, R.; Mohd, B.J.; Alshayeji, M. FPGA modeling and optimization of a SIMON lightweight block cipher. Sensors
**2019**, 19, 913. [Google Scholar] [CrossRef] [PubMed] [Green Version] - Dwiel, B.; Choudhary, N.; Rotenberg, E. FPGA modeling of diverse superscalar processors. In Proceedings of the 2012 IEEE International Symposium On Performance Analysis Of Systems & Software, New Brunswick, NJ, USA, 1–3 April 2012; pp. 188–199. [Google Scholar]
- Dahiphale, V.; Raut, H.; Bansod, G. Design and Implementation of novel datapath designs of lightweight cipher RECTANGLE for resource constrained environment. Multimed. Tools Appl.
**2019**, 78, 23659–23688. [Google Scholar] [CrossRef] - Zhang, W.; Bao, Z.; Lin, D.; Rijmen, V.; Yang, B.; Verbauwhede, I. RECTANGLE: A bit-slice lightweight block cipher suitable for multiple platforms. Sci. China Inf. Sci.
**2015**, 58, 1–15. [Google Scholar] [CrossRef] - Rezvani, B.; Coleman, F.; Sachin, S.; Diehl, W. Hardware implementations of NIST lightweight cryptographic candidates: A first look. Cryptol. ePrint Arch.
**2019**. Available online: https://eprint.iacr.org/2019/824.pdf (accessed on 12 January 2023). - Banik, S.; Chakraborti, A.; Inoue, A.; Iwata, T.; Minematsu, K.; Nandi, M.; Peyrin, T.; Sasaki, Y.; Sim, S.; Todo, Y. Gift-cofb. Cryptol. EPrint Arch.
**2020**. Available online: https://eprint.iacr.org/2020/738 (accessed on 12 January 2023). - Gueron, S.; Jha, A.; Nandi, M. Comet: Counter Mode Encryption with Authentication Tag. 2019. Available online: https://csrc.nist.gov/CSRC/media/Projects/Lightweight-Cryptography/documents/round-1/spec-doc/comet-spec.pdf (accessed on 12 January 2023).
- Dobraunig, C.; Eichlseder, M.; Mendel, F.; Schläffer, M. Ascon v1. 2. Submiss. CAESAR Compet.
**2016**, 5, 7. [Google Scholar] - Beierle, C.; Biryukov, A.; Santos, L.; Großschädl, J.; Perrin, L.; Udovenko, A.; Velichkov, V.; Wang, Q.; Biryukov, A. Schwaemm and Esch: Lightweight Authenticated Encryption and Hashing Using the Sparkle Permutation Family. 2019. Available online: https://csrc.nist.gov/CSRC/media/Projects/lightweight-cryptography/documents/finalist-round/updated-spec-doc/sparkle-spec-final.pdf (accessed on 12 January 2023).
- Podimatas, P.; Limniotis, K. Evaluating the Performance of Lightweight Ciphers in Constrained Environments—The Case of Saturnin. Signals
**2022**, 3, 86–94. [Google Scholar] [CrossRef] - Regla, A.; Festijo, E. Performance analysis of light-weight cryptographic algorithms for internet of things (IOT) applications: A systematic review. In Proceedings of the 2022 IEEE 7th International Conference For Convergence In Technology (I2CT), Mumbai, India, 7–9 April 2012; pp. 1–5. [Google Scholar]
- Turan, M.; McKay, K.; Chang, D.; Calik, C.; Bassham, L.; Kang, J.; Kelsey, J. Status Report on the Second Round of the NIST Lightweight Cryptography Standardization Process. 2021. Available online: https://tsapps.nist.gov/publication/get_pdf.cfm?pub_id=932630 (accessed on 12 January 2023).
- Shpigor, I. Instant MinGW Starter; Packt Publishing Ltd.: Birmingham, UK, 2013. [Google Scholar]
- Stallman, R. Using and Porting the GNU Compiler Collection; Free Software Foundation: Boston, MA, USA, 1999. [Google Scholar]
- Arduino, S. Arduino. 2015. Available online: https://search.iczhiku.com/paper/TFzDJhGhd6VMaDsI.pdf (accessed on 12 January 2023).
- Silva, J.L.d.S.; Melo, M.; Camilo, R.d.S.; Galindo, A.L.; Viana, E.C. Plataforma Arduino integrado ao PLX-DAQ: Análise e aprimoramento de sensores com ênfase no LM35. In Proceedings of the XIV Escola Regional de Computação Bahia, Alagoas e Sergipe (ERBASE), Feira de Santana, Brazil, 20–23 May 2014. [Google Scholar]
- Hindle, A.; Wilson, A.; Rasmussen, K.; Barlow, E.J.; Campbell, J.C.; Romansky, S. Greenminer: A hardware based mining software repositories software energy consumption framework. In Proceedings of the 11th Working Conference on Mining Software Repositories, Hyderabad, India, 31 May–1 June 2014; pp. 12–21. [Google Scholar]
- Nethercote, N.; Seward, J. Valgrind: A framework for heavyweight dynamic binary instrumentation. ACM Sigplan Not.
**2007**, 42, 89–100. [Google Scholar] [CrossRef] - Atzori, L.; Iera, A.; Morabito, G.; Nitti, M. The social internet of things (siot)–when social networks meet the internet of things: Concept, architecture and network characterization. Comput. Netw.
**2012**, 56, 3594–3608. [Google Scholar] [CrossRef] - Cauteruccio, F.; Cinelli, L.; Fortino, G.; Savaglio, C.; Terracina, G.; Ursino, D.; Virgili, L. An approach to compute the scope of a social object in a Multi-IoT scenario. Pervasive Mob. Comput.
**2020**, 67, 101223. [Google Scholar] [CrossRef]

**Figure 26.**NIST best algorithms in UNO vs. Pi. (

**a**) Best 3 For UNO. (

**b**) Best 3 For Pi. (

**c**) Best 3 for UNO. (

**d**) Best 3 for Pi.

**Figure 27.**Best 8 Algorithms of NIST finalists in ENC speed latency with respect to RR % for both UNO and PI.

**Figure 28.**Best 8 Algorithms of NIST finalists in ENC energy with respect to RR % for both UNO and Pi.

**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.

Family-Cipher | Algorithm | Type | Structure | Block Size (bits) | Key Size (bits) | Rounds |
---|---|---|---|---|---|---|

Relative reference | AES | Block Cipher | SPN | 128 | 128/192/256 | 10/12/14 |

1-1 | HIGHT | Block Cipher | Generalized Feistel Structure (GFS) | 64 | 128 | 32 |

2-2/3/4 | KATAN | Block Cipher | stream cipher like | 32/48/64 | 80 | 254 |

3-5/6/7 | KTANTAN | Block Cipher | Stream cipher like | 32/48/64 | 80 | 254 |

4-8/9/10 | LEA | Block Cipher | Generalized Feistel Network (GFN) | 128 | 128/192/256 | 24/28/32 |

5-11 | Piccolo | Block Cipher | GFN | 64 | 80/128 only 80 chosen | 25/31 |

6-12/13 | PRESENT | Block Cipher | SPN | 64 | 80/128 | 31 |

7-14 | PRINCE | Block Cipher | SPN | 64 | 128 | 12 |

8-15 | QARMA | Block Cipher | SPN | 64 | 64 | 27 |

9-16 | RECTANGLE | Block Cipher | SPN | 64 | 128 | 25 |

10-1726 | SIMON | Block Cipher | Feistel | 32128 | 64256 | 3272 |

11-2736 | SPECK | Block Cipher | Addition/Rotation/XOR (ARX) | 32128 | 64256 | 2234 |

12-37/38 | TWINE | Block Cipher | Type-2 Generalized Feistel Network (GFN-2) | 64 | 80/128 | 36 |

13-39 | XTEA | Block Cipher | ARX | 64 | 128 | 64 |

Number | Algorithm | Kind | Block Size (bits) | Key Size (bits) | Num of Rounds | Algorithm Info |
---|---|---|---|---|---|---|

1 | ACE | Authenticated encryption with associated data (AEAD)-block cipher-hash algorithm | 64 | 128 | 8 | Tag size of 128 bits, digest (hash) of 256 bits |

2 | ASCON | Authenticated encryption (AE)-block cipher and hashing | 64-128 | 128 | 30/32 | Key size = tag size = security level 128 bits |

3 | COMET | AE-block cipher | 64-128 | 128 | 27/80 | Block cipher mode of operation |

4 | DryGASCON | AEAD-block cipher-hash algorithm | 64-128 | 128/160/256 | 48 | N/A |

5 | Elephant as (Dumbo-Jumbo-Delirium) | AE Family-block cipher | Tweakable block cipher | 128 | 18/80/90 | Nonce-based encrypt-then-MAC construction |

6 | ESTATE | AE Family-block cipher | Tweakable | 128 | 40 | Block cipher-based MAC then encrypt |

7 | ForkAE | AE Family-block cipher | 64 | 128 | 53/75/87 | SKINNY primitive |

8 | GIFT-COFB | AE Family-block cipher | Tweakable | 128 | 40 | block cipher cryptographic primitive |

9 | Gimli | AE-block cipher and hashing | Tweakable | 256 | 24 | Cipher: 256-bit key, 128-bit nonce, 128-bit tag Hash: with 256-bit output |

10 | Grain-128AEAD | AEAD stream cipher | Tweakable | 128 | 160 | Nonce (IV) of size 96 bits and key of size 128 bits |

11 | HyENA | AE Family-block cipher | Tweakable | 128 | 40 | Hybrid feedback based |

12 | ISAP | AE Family-block cipher | 64 | 128 | 32/33/48/56 | Nonce-based AEAD |

13 | KNOT | AEAD-block cipher-hash algorithm | Tweakable | 128/192/256 | 118/136/160/ 208 | Permutation-based and bit-sliced AEAD and hashing algorithms |

14 | LOTUS-AEAD and LOCUS-AEAD | AEAD-block cipher | 64 | 128 | 28 | Block cipher-based AE scheme that employs OTR style |

15 | mixFeed | AE Family-block cipher | 64 | 128 | Based on any block cipher with some key scheduling | |

16 | ORANGE | Sponge AE-block cipher and sponge hash | 128 | 128 | 12 | Based on any permutation |

17 | Oribatida | AE Family-block cipher | Tweakable | 128 | 26/34 | Keyed permutation-based mode |

18 | PHOTON-Beetle | AE-block cipher and hashing | Tweakable | 128 | 12 | Sponge-based mode Beetle with the P256 (used for the PHOTON hash) |

19 | Pyjamask | Block cipher | 96/128 | 128 | 14 | SPN |

20 | Romulus | AE Family-block cipher | Tweakable | 128 | 48/56 | Based on a Tweakable block cipher (TBC) Skinny |

21 | SAEAES | AE Family-block cipher | 128/192/ 256 | 128 | 10 | AES-based AEAD |

22 | Saturnin | MAC-block cipher-hash | 256 | 256 | 10 | N/A |

23 | SKINNY | AEAD-block cipher-hash algorithm | Tweakable | 128 | 48/56 | Tweakable block ciphers |

24 | SPARKLE (SCHWAEMM and ESCH) | AE-block cipher and hashing | 128/192/ 256 | 128/196 /256 | 10/11/12 | Permutations based on an ARX design |

25 | SPIX | MAC-block cipher | 64 | 128 | 72/144 | Hybrid |

26 | SpoC | AEAD-block cipher | 192/256 | 128 | 108/ 144 | Permutation-based mode |

27 | Spook | AEAD-block cipher | Tweakable | 128/256 | Sponge based | |

28 | Subterranean 2.0 | Hashing, MAC computation, stream encryption, AE | 128 | 128 | N/A | |

29 | SUNDAE-GIFT | Block cipher | 128 | 128 | 40 | N/A |

30 | TinyJambu | AE-block cipher | 32 | 128/192/256 | 8 | Based on a keyed permutation |

31 | WAGE | AEAD-stream cipher | 64 | 128 | 111 | Permutation based on the Welch–Gong (WG) stream cipher |

32 | Xoodyak | Hashing, encryption, MAC, AE-block cipher | 128 | 128 | 12 | Duplex object |

Measurement | Metrics (in) | Tool of Measuring for Arduino | Tool of Measuring for Raspberry Pi |
---|---|---|---|

Key size | bits | Algorithm specs | Algorithm specs |

Block size | bits | Algorithm specs | Algorithm specs |

Rounds number | number of rounds | Algorithm specs | Algorithm specs |

ROM occupation | bits or bytes | Arduino IDE | Size command |

RAM occupation | bits or bytes | Arduino IDE | Valgrind |

Code size | Kbytes | Size occupied on memory | Size occupied on memory |

Encryption (ENC) or decryption (DEC) speed throughput | Bytes/s | Programming + Equation (1) | Programming + Equation (1) |

ENC or DEC speed latency | cycle/Block | Programming + Equation (3) | Programming + Equation (3) |

Key schedule speed throughput | Bytes/s | Programming + Equation (2) | Programming + Equation (2) |

Key schedule speed latency | cycle/Block | Programming + Equation (4) | Programming + Equation (4) |

ENC or DEC power (throughput) | joules/s | Current (power) sensor | Current (power) sensor |

ENC or DEC energy (latency) | joules/bit | Current (power) sensor + Equation (7) | Current (power) sensor + Equation (7) |

Condition | Key Schedule Speed UNO (39) | Key Schedule Speed Pi (39) | ENC Speed UNO (110) | ENC Speed Pi (110) | Energy UNO (110) | Energy Pi (110) |
---|---|---|---|---|---|---|

Unit Normal Comparison | Kbytes/Kcycles per s | Gbytes/cycles per s | Kbytes/Kcycles per s | Gbytes/cycles per s | [0.097,67.4] µj/byte | [0.035,26.87] µj/byte |

Overall sum of % | 30,760 | 6032 | 77,014 | 6114 | 68,138 | 42,308 |

Overall sum of % decreases from UNO to Pi | ↘80% | ↘92% | ↘ 40% | |||

# of algorithms decreases in RR % | 3 (all of 64 Block size) | 36 (92%) | 6 (4 of key size 80) | 106 (94%) | 15 (8 of 9 of key size 80) | 95 (86%) |

# of algorithms <100% in RR % | 10 (25%) | 33 (84%) (+23 added) | 28 (25%) | 79 (72%) (+51 added) | 33 (30%) | 65 (60%) (+32 added) |

Overall sum of % | Is the sum of all the algorithms percentage in RR | |||||

↘ | The number of algorithms decreases | |||||

<100% | Number of algorithms that are below 100% in RR |

Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content. |

© 2023 by the authors. Licensee MDPI, Basel, Switzerland. This article is an open access article distributed under the terms and conditions of the Creative Commons Attribution (CC BY) license (https://creativecommons.org/licenses/by/4.0/).

## Share and Cite

**MDPI and ACS Style**

El-hajj, M.; Mousawi, H.; Fadlallah, A.
Analysis of Lightweight Cryptographic Algorithms on IoT Hardware Platform. *Future Internet* **2023**, *15*, 54.
https://doi.org/10.3390/fi15020054

**AMA Style**

El-hajj M, Mousawi H, Fadlallah A.
Analysis of Lightweight Cryptographic Algorithms on IoT Hardware Platform. *Future Internet*. 2023; 15(2):54.
https://doi.org/10.3390/fi15020054

**Chicago/Turabian Style**

El-hajj, Mohammed, Hussien Mousawi, and Ahmad Fadlallah.
2023. "Analysis of Lightweight Cryptographic Algorithms on IoT Hardware Platform" *Future Internet* 15, no. 2: 54.
https://doi.org/10.3390/fi15020054