1 Introduction

Today, we can see many applications of the Internet of Things (IoT) in the various aspects of human life. Smart homes, wearable devices, industrial smart monitoring systems are some samples of IoT. The first time, Kevin Ashton in 1999 within the context of an RFID project introduced an Internet of Things term. Back to 2009, when the Internet of Things (IoT) term first revealed as a group of interrelated devices capable of interconnecting wired or wireless, up to now we can see a growing progress for technologies, infrastructure, and using of IoT. Two prime factors are helping IoT overall growth: Fast internet connections and using the cloud. In terms of fast internet connections, the trend toward 5G networks (Or faster networks) will show its effect. Cloud-based solutions provide data mobility and collaboration, which is vital to create and maintain a scalable IoT network. IoT nodes have a certain physical size, processing power, and memory capacity because of limited battery considerations, so storing the data over real-time clouds services can show its outcome on nodes durability and cut downtime.

The crucial advantage of using the cloud is to reach the data from any point connected to the internet. Looking back to the high density of traffic transferred among IoT nodes and data centers, there is another endeavor called providing security. It is clear that the insecure network can lead to vulnerabilities and unwanted damage. One of the potential ways of protecting the data from unwanted access is to encrypt them with strong algorithms. Since devices interconnected on an IoT network have limited resources, especially energy as mentioned before, typical encryption algorithms cannot be scale for them. Classic encryption algorithms designed to use on desktops, phones, tablets, and servers while lightweight block ciphers are a good out for providing end-to-end security over embedded systems and sensor networks. Embedded systems are using 4-, 8-, 16-, and 32-bit micro-controllers that deal with real-time applications. For sensor networks, different technologies associate power with timing requirements, number of gates, and applying cryptographic functions. All the mentioned features here lead to the use of lightweight cryptography instead of classical methods. The intrinsic motivation of using lightweight block cipher is because of the pervasive upcoming IT landscape and the factor that they consume less computing power [1, 2].

In this paper, we chose ten lightweight block ciphers and tested their performance for their power consumption, memory usage (RAM and ROM), throughput comparison, average execution time for encryption and decryption operations in different payloads. Software lightweight implementations help to keep processor needs and memory usage as low as possible. We picked the Raspberry Pi 3 and Arduino Mega 2560 as our IoT testbed and we have done data transform over the Dropbox cloud. Searching the literature, we can see many lightweight block ciphers in which categorized in disparate groups. Choosing a suitable algorithm regarding low resource consumption (energy, RAM and ROM) and provide an acceptable level of security is our motivation to compare chosen block ciphers in this paper. The main contributions of this paper are:

  • Providing a fair comparison by software implementing of ten block ciphers over the cloud using an IoT platforms (Raspberry Pi 3 and Arduino Mega 2560) for metrics cited in the literature like power consumption, memory usages, throughput, execution time.

  • Investigate and analyze the reported data from software implementations and ordering the mentioned algorithms in specific order regarding each evaluation metric.

  • Also, we discuss the results for selecting the right algorithm with the best results for all the multiple metrics.

  • This research will help the researchers to choose the right lightweight block cipher algorithm regarding the implemented platforms.

The rest of this paper is arranged as follows. In Sect. 2, we briefly explain lightweight block ciphers. Section 3 discusses previous related works. Section 4 represents the performance comparison of selected Lightweight Block Ciphers and our evaluation results over Raspberry Pi 3 and Arduino Mega 2560. Section 5 concludes this work.

2 Lightweight Block Ciphers

A lightweight cipher is a less demanding cryptographic method, concentrating on optimizing memory usage, power consumption and providing enough level of security. We could implement it in both hardware and software platforms. The former focuses on reducing the number of running cycles and memory footprints, and the later targeted at reducing energy consumption and memory usage. In terms of power and speed, the hardware solution provides better results. Searching the literature, we can see three groups of lightweight block cipher: Substitution-Permutation Network (SPN), Feistel Networks, and other designs. In terms of comparing Feistel against SPN structure, the round function (F) of SPN has to be invertible, but for Feistel, function F need not to be invertible. SPN provides relatively higher security in contrast to the Feistel network. On the other hand, SPN consumes more resources. In a Feistel structure, the encryption and decryption are similar and even identical in some cases. Combining natural features of mentioned ciphers led to new categories of block ciphers called hybrid. As mentioned before memory footprint is one of the supreme challenges in designing a lightweight block cipher, thus, many of the block ciphers have no S-box or tiny ones (4-byte). S-box plays a key role to resist against attacks. In this part, we have presented a brief review of the lightweight block ciphers used in this paper and the other algorithms are compared inside the Table 1.

  1. 1.

    AES—is an SPN cipher available in different encryption packages. The S-box of this cipher is a four-by-four matrix. After key expansion, depending on the preferred key length, it will apply the round function over plaintext and comprises four operations; SubBytes (A four-byte word is the SubByte return value), ShiftRows (State rows are cyclically shifted over different offsets.), MixColumns (State columns are expressed as polynomials over GF(28) and multiply by modulo x4 + 1 with a constant polynomial c(x)), and AddRoundkey (Using a simple bitwise EXOR, a Round Key is applied to the State) [3].

  2. 2.

    RECTANGLE—is suitable for hardware and software environments and has SPN framework. There are 25 rounds in this cipher that include these steps: AddRoundKey (A simple bitwise XOR (Of round subkey) applied to the intermediate state), SubColumn (Parallel application of S-boxes to the four bits in the same column), ShiftRow (A left rotation applies to each row over different offsets). A sequence of twelve basic logical operations could build S-box for this cipher. P-layer composes three rotations [4].

  3. 3.

    PRESENT—the infrastructure of this block cipher is the inspiration resource for many lightweight block ciphers. It is a bit-oriented SPN structure. After generating round keys, the algorithm implements the following steps for each of 31 rounds: addRoundKey (Involves of the operation for 0 ≤ j ≤ 63, \({b}_{j}\to {b}_{j}\oplus {k}_{j}^{i}\)), sBoxLayer (Uses a single 4 × 4 S-box), pLayer (The ith bit of STATE is moved to position P(i) due to specific mapping). It is recommended to on hardware platforms [5].

  4. 4.

    Skipjack—has an 80-bit key size, and it suffers against common attacks (Because of key size). The block size of Skipjack is 64 bits (divided into four 16 bits word) and the round number is 32 and ranked as an unbalanced Feistel network. This is a simple cipher that has an 8 × 8 S-box and there are two alternating stepping rounds called Rule A and Rule B (inversion of Rule A adding minor positioning) inside the structure [6].

  5. 5.

    PRINCE—is based on FX construction and no actual key scheduling mechanism of this algorithm could describe as; It achieves two of its 64-bit keys within the 128-bit master key that acts as a whitening key and the third one during encryption is XORed in the internal state. Each round combines these steps: key addition (The 64 bits state is XORed with 64 bits subkey), one Sbox-layer (It uses a single four bitsSbox), a linear layer (In this layer a 64*64 matrix is multiplied by a 64-bit state), and round constant addition (The state is XORed with a 64-bit round constant) [7].

  6. 6.

    SIMON—is a balanced Feistel structure and optimized to use on hardware-oriented systems. Bitwise XOR, bitwise AND, and left circular shift to make the body of round function. The key schedule could be balance or not. The authors optimized SPECK to use on software platforms and is a member of ARX based Feistel networks. Key sizes are flexible for scenarios and start from 64 bit up to 256 bits. Unique values starting from 32 to 128-bit are selectable for a block. Round numbers could be 22–34. There are two rotations, adding, and XORing operations for the round function [8].

  7. 7.

    HIGHT—ARX based generalized Feistel is a category that this cipher belongs. HIGHT is based on simple operations: XOR, addition mod 28, bitwise rotation (left). There are two algorithms for a key schedule: WhiteningKeyGeneration (Uses eight whitening key bytes for initial and final transformations) and SubKeyGeneration (128 subkeys are used for one computation). It is common to run for hardware and software platforms [9].

  8. 8.

    Piccolo—is a hardware-oriented block cipher and its key sizes are available in Piccolo-80 and Piccolo-128. For the diffusion layer, it uses special half-word permutation and whitening technique. There is a 4 × 4 S-box and can be implemented using the following operations: four NOR, three XOR, and one XNOR gates [10].

  9. 9.

    LBlock—is capable of implementing on software and hardware environments. There is a 4 × 4 S-Box in LBlock. The key schedule mechanism applies two additional S-boxes. Encryption operation involves a 32-round iterative structure and the decrypting is the inverse operation of encryption [11].

  10. 10.

    TEA and its successor XTEA—are following the Feistel formation. Both Ciphers have 128 bits of key sizes and 64-bit of block sizes. TEA represents an uncomplicated key schedule mechanism. Comparing to XTEA, some improvements have been done include rearranging shifts, XORs and additions operations. Also, a more complex key schedule mechanism used for it. Both have key sizes of 128 bits and block sizes of 128 bits [12].

Table 1 Comparison of different lightweight block ciphers
Full size table

Table 1 shows a comparison using different metrics among available lightweight block ciphers [13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29]. RELATED WORKS.

Generally, searching the literature the performance evaluation studies are categorized into three groups include software, hardware, and software/hardware evaluation papers. In this part, we look at related works in the field of software evaluations. A lightweight encryption algorithm called NUCLEAR introduced to be used in 6LoWPAN networks. To evaluate the software performance of their algorithm, they selected the ARM 7 LPC2129 platform and compared the results in terms of memory usage, power consumption, throughput, and execution time among nine lightweight block ciphers [30]. Jaber H [31] evaluated SIMON, SPECK, TWINE, KLEIN, Piccolo block ciphers in terms of power consumption and memory usage (Flash and RAM) over Atmega128 microprocessor. A performance comparison for IoT devices among six lightweight block ciphers were made by [32]. They chose Raspberry Pi 3 and Beagle Bone black as testbeds. They evaluated the mentioned algorithms due to execution time in the Cipher Block Chaining (CBC) and Electronic codebook (ECB) modes. CBC is a famous block cipher mode operation in which before encrypting operation, each plaintext is XORed with the previous ciphertext. In ECB, the message is divided into blocks, and each block is individually encrypted. Software evaluation of five block ciphers over the Strong SA-1100 processor done by Johann G [33]. XTEA, Rijndael, Serpent, RC6, and Twofish algorithms performance assessed due to power consumption, throughput, code size, and memory footprint. Miroslav B [34] compared XTEA against AES regarding several payloads over Atmel Atmega128RFA1 microprocessor considering energy consumption, time, and throughput metrics. Voice recognition applied to compare AES, PRESENT, HIGHT, and KLEIN block ciphers performance in terms of memory consumption, speed, floating-point numbers. All the codes were written in MATLAB, executed, and tested in both MATLAB and Arduino UNO [35]. Lejla and colleagues [36] evaluated AES, CLEFIA, KLEIN, LED, mCrypton, PRESENT, and KATAN block ciphers regarding encryption time, power (static and dynamic), and energy consumption for the encryption mode. They used Cadence Encounter RTL Compiler and ModelSIM simulator as the main tools to implement their work. Software performance comparison between SIMON and SPECK block ciphers over an AVR 8-bit Atmel Atmega128 microcontrollers based on Flash, RAM, cost (speed, energy) metrics for an encryption operation measured in [37]. Raspberry Pi 2 and Arduino UNO used as testbeds to evaluate PRESENT, SIMON, SPECK, RECTANGLE, PRINCE, Pride, and LBlock algorithms in terms of RAM and ROM usages, Execution time, Clock/cycle for encryption/decryption and key schedule modes [38]. The authors [39] made a performance comparison among CLEFIA, PICCOLO, and TWINE block ciphers regarding Throughput, RAM and ROM, energy consumption, and execution time metrics for the encryption mode. The experiments were done on a STM32F401RE microcontroller and 512, 1024, 2048, 3072 bytes plain texts entered as input to test the algorithms. Memory usage (RAM and ROM) and energy consumption of TEA, HIGHT, KATAN, and KLEIN block ciphers measured in [40] using an Atmel Attiny45 microcontroller in encryption mode. In [41], the authors review the approaches of smart homes, available challenges with privacy, security, and possible solutions for the mentioned concerns. Zahra and NZ in [42] makes a comprehensive review about user’s privacy protection in location-aware mobile clouding services. They address and analyze available approaches in providing security for the positioning services in the future. The in-vehicle communication, software implementing of cryptographic algorithms for AUTomotive Open System Architecture (AUTOSAR) has been done for several devices applying AES, KATAN, PRESENT, SPECK, MD5, SHA1, SHA2, SHA3, and Blake2 algorithms in [43]. Khaled [44] represented an analytical model to discover the minimum number of cloud resources to meet Service Level Objectives (SLO) response time. In [45], the authors used numerical samples to estimate the number of necessary virtual machines over cloud data centers to provide quality of service parameters. Table 2 represents a comprehensive comparison of previous related works and this study. Performance Evaluation of Lightweight Encryption Algorithms.

Table 2 Previous works comparison
Full size table

We picked ten algorithms due to block length, key sizes, popularity, their inner structure, and implementation possibility over software environments. Although some of the algorithms like PRESENT were hardware-oriented on first versions, they have been improved to be installed on software platforms later. Except for AES with 128 bits block length, all other algorithms have 64-bit length and in terms of key size, except LBlock and Skipjack in which have an 80-bit key size, the others have 128-bit key sizes. Table 3 compares the chosen ten lightweight block ciphers.

Table 3 Comparing selected lightweight block ciphers
Full size table

To evaluate the mentioned ten block ciphers over an IoT platform, we selected Raspberry Pi 3 and Arduino Mega 2560 as our testbed platforms and Dropbox cloud service as an encrypted file exchange platform. We have repeated each experiment for five iterations to get more precise results. The plaintext is encrypted into a file at sender side and the file transfers to the cloud and for decryption at the target side, the device reads the file from cloud and starts decrypting it. Since network parameters like delay and network speed may change during simulations, we ignored upload and download times to the cloud and all the measured values in this paper are based on local encryption and decryption times at sender or receiver. Figure 1 show a general view of the data exchange system and Fig. 2 represents the hardware layout of the evaluated system, respectively. As can be seen in Fig. 2, the Raspberry Pi 3 empowered by a 10,400 mA Power Bank and Arduino Mega is connected to notebook USB port. To control and execute commands, we connected the Raspberry Pi and Arduino to a MacBook through an ethernet and USB ports. For measuring power consumption in different scenarios, we used USB power meter. Pi 3 runs at 1.2 GHz and uses 1 Gb Ram and equipped with a 64-bit ARM Cortex A53 processor. It can be powered by a 5 V Micro USB or Power Bank. On the other hand, Arduino Mega 2560 has a 16 MHz ATmega2560 8-bit microcontroller, 256 KB Flash memory, 8 KB SRAM, and 4 KB EEPROM. The recommended input voltage for Arduino is 7–12 V.

Fig. 1
figure 1

Data exchange schema for test systems

Full size image
Fig. 2
figure 2

Hardware layout of tested system (a using Arduino Mega—b using Raspberry Pi)

Full size image

Simulations have been implemented in C. For calculating the amount of power consumed for each algorithm, we used the following equations:

$${\text{Current Stream }}\left( {\text{A}} \right) \, *{\text{ time }}\left( {{\text{Seconds}}} \right) \, = {\text{ Charge }}\left( {\text{C}} \right)$$
(1)
$${\text{Charge }}\left( {\text{C}} \right) \, *{\text{ Voltage }}\left( {\text{V}} \right) \, = {\text{ Energy }}\left( {\text{J}} \right)$$
(2)

Figure 3 and 4 represent energy consumption behavior for an encryption operation for both devices. Raspberry Pi 3 and Arduino Mega 2560 consume remarkably the maximum energy for the PRESENT algorithm comparing to other block ciphers. That is because this block cipher was originally designed to be a hardware friend. Table 4 shows the consumed energy comparison for two devices. The lightweight block ciphers in the related columns are arranged from the lowest to the highest. XTEA, Skipjack, and RECTANGLE have the minimum amount of energy consumption for the Raspberry Pi 3. XTEA and Skipjack's simple structure is an important reason to explain their energy consumption. RECTANGLE has a bit-slice style. These features help in consuming less power in software applications. For the Arduino Mega 2560, Piccolo and PRESENT have the highest amount of measured power consumption. The mentioned algorithms are designed to be used in hardware platforms and this explains why there are consuming the maximum energy in the software simulations. Skipjack, RECTANGLE, and HIGHT have the lowest amount of consumed power for Arduino Mega 2560. Despite the HIGHT has been designed for hardware platforms, it represents a good performance in terms of encryption power consumption. Arduino Mega 2560 has lower processing and memory features comparing to Raspberry Pi 3, and this affects the algorithm's order in Table 4. For Arduino Mega 2560 chart, since the PRESENT algorithm values are significantly higher than other block ciphers, we limited the chart scale to 250. In this case, the PRESENT algorithm energy consumption for 512, 1024, and 2048 seems equal. As a comparison, the real values of the PRESENT algorithm for mentioned payloads, for example, are nine times bigger than Piccolo algorithm energy consumption for the mentioned payloads.

Fig. 3
figure 3

Consumed energy for encryption (Raspberry Pi 3)

Full size image
Fig. 4
figure 4

Consumed energy for encryption (Arduino Mega 2560)

Full size image
Table 4 Consumed energy comparison for encryption operation for Raspberry Pi 3 and Arduino Mega 2560
Full size table

Figure 5 and 6 shows the measured energy consumption for decryption operation for two devices. Table 5 helps in a better understanding of the algorithm's arrangement from lowest to the highest for decryption. We can see a similar situation to encryption operation in terms of power consumption for decryption mode. For the Arduino Mega graph, the vertical axis has been limited to 250, just like the encryption graph to visualize other algorithms better.

Fig. 5
figure 5

Consumed energy for decryption (Raspberry Pi 3)

Full size image
Fig. 6
figure 6

Consumed energy for decryption (Arduino Mega 2560)

Full size image
Table 5 Consumed energy comparison for decryption operation for Raspberry Pi 3 and Arduino Mega 2560
Full size table

To analyze the amount of memory (RAM and ROM) usage by each block cipher, we used Atmel Studio 7 [56, 57]. Figure 7 and 8 are about encryption RAM usage for our tested systems. Arduino Mega 2560 has a considerably lower SRAM size (8 KB) compared to 1 GB RAM of Raspberry Pi 3. Table 6 sums up the encryption RAM usage for all payloads between two devices. For Raspberry Pi 3, XTEA and RECTANGLE have the minimum RAM usage against XTEA and Piccolo for Arduino Mega 2560. Considering the highest RAM occupation, Skipjack and AES have the maximum amount of RAM usage For Raspberry Pi 3. For Arduino Mega, HIGHT and PRESENT reaching the peak points. Our tested devices have different hardware specifications. Also, the infrastructure of tested algorithms and the targets that they designed affects the simulation results for encryption and decryption modes.

Fig. 7
figure 7

Encryption RAM usage (Raspberry Pi 3)

Full size image
Fig. 8
figure 8

Encryption RAM usage (Arduino Mega 2560)

Full size image
Table 6 Sorted algorithms for encryption RAM usage (Arduino Mega 2560 vs Raspberry Pi 3)
Full size table

We can see changes in decryption RAM usage in Fig. 9 and 10. Looking at Table 7, for Raspberry Pi 3, there is no change in the order of the algorithms compared to encryption mode. For Arduino Mega 2560, XTEA occupies the minimum amount of RAM for decryption mode, and PRESENT reaches the peak just like the encryption mode. In contrast to an encryption operation, there are some changes in the algorithm sequences for Arduino Mega.

Fig. 9
figure 9

Decryption RAM usage (Raspberry Pi 3)

Full size image
Fig. 10
figure 10

Decryption RAM usage (Arduino Mega 2560)

Full size image
Table 7 Sorted algorithms for decryptin RAM usage (Arduino Mega 2560 vs Raspberry Pi 3)
Full size table

Raspberry Pi 3 is considerably stronger than Arduino Mega 2560 considering hardware features. Figure 11 and 12 provide a good comparison among ten lightweight block ciphers between two devices. Table 8 summarizes the algorithm's order from the lowest to the highest ROM usage. The peak ROM usage in bytes for encryption operation belongs to the RECTANGLE algorithm for Raspberry Pi 3 and for Arduino Mega 2560, AES occupied the highest ROM. SIMON and XTEA for Raspberry Pi 3 and SIMON and PRESENT for Arduino Mega have the lowest ROM usage.

Fig. 11
figure 11

Encryption ROM usage (Raspberry Pi 3)

Full size image
Fig. 12
figure 12

Encryption ROM usage (Arduino Mega 2560)

Full size image
Table 8 Tested algorithms order by ROM usage for encryption
Full size table

Figure 13 and 14 illustrate ROM usage for each of ten block ciphers regarding different payloads for decryption operation for Raspberry Pi and Arduino Mega. In Fig. 13, RECTANGLE, and Fig. 14, AES considerably have a higher amount of ROM usage compared to other block ciphers from the beginning. Interestingly, the rate of increase for ROM usage follows a specific pattern for both devices. SIMON and XTEA have the minimum ROM usage for both devices in decryption mode Table 9.

Fig. 13
figure 13

Decryption ROM usage (Raspberry Pi 3)

Full size image
Fig. 14
figure 14

Decryption ROM usage (Arduino Mega 2560)

Full size image
Table 9 Tested algorithms order by ROM usage for decryption
Full size table

We can illustrate the average encrypting execution times for Raspberry Pi 3 and Arduino Mega 2560 in Fig. 8 and 9. For all payloads, PRESENT is in the first rank with the highest encrypting execution time for both devices. Because the PRESENT running times after 512 bytes are high, the vertical axis in Fig. 9 has been limited to 0.9 s to show other algorithms running times clearly. Looking at Table 10, we can see the ascending order of ten algorithms by average encryption execution time for each device (Figure 15, 16).

Table 10 Algorithms order due to encryption execution time
Full size table
Fig. 15
figure 15

Average encrypting execution time (Raspberry Pi 3)

Full size image
Fig. 16
figure 16

Average encrypting execution time (Arduino Mega 2560)

Full size image

Figure 17 and 18 represent the average time spent for decryption for our testbed systems. For two charts, we can consider the PRESENT block cipher with the highest execution times values, especially beginning from 128 bytes. The execution time has been limited to 0.9 s in the second chart to view other algorithms running times easier. Table 11 summarizes the algorithm's order for decryption operation considering running time. PRINCE, Piccolo, and PRESENT have hardware-oriented architecture and have the highest running times respectively for software simulations. On the other hand, Skipjack and HIGHT have a simple structure and have the minimum running times among other algorithms for Arduino Mega. For Raspberry Pi 3, XTEA and RECTANGLE are faster than other lightweight block ciphers (Table 12, 13).

Fig. 17
figure 17

Average decrypting execution time (Raspberry Pi 3)

Full size image
Fig. 18
figure 18

Average decrypting execution time (Arduino Mega 2560)

Full size image
Table 11 Algorithms order due to decryption execution time
Full size table
Table 12 Algorithms sequence due to the average encryption throughput
Full size table
Table 13 Algorithms sequence due to the average decryption throughput
Full size table

The average encryption throughputs are shown in Fig. 19 and 20 for Raspberry Pi 3 and Arduino Mega 2560. Throughput is being calculated using the following equation:

$${\text{Throughput}} = \frac{{{\text{Number}} \,{\text{of}}\, {\text{Bytes}}}}{{{\text{End}}\, {\text{Time}} - {\text{Start}}\, {\text{Time}}}}$$
(3)
Fig. 19
figure 19

Average encrypting throughput (Raspberry Pi 3)

Full size image
Fig. 20
figure 20

Average encrypting throughput (Arduino Mega 2560)

Full size image

For encryption mode, for 16 bytes, XTEA achieves the peak value among other block ciphers for Raspberry Pi 3. From 64 bytes, RECTANGLE takes the highest throughput for Raspberry Pi 3. For Arduino Mega 2560, Skipjack has the maximum encryption throughput for all payloads. For both devices, PRESENT has the lowest encryption throughput.

Figure 21 shows the average decryption throughput for Raspberry Pi 3. RECTANGLE, Skipjack, SIMON, and XTEA has significantly higher throughputs than other algorithms. PRINCE, Piccolo, and PRESENT encryption throughput values are the smallest ones among others. For Arduino Mega 2560, Skipjack decryption throughput value is substantially bigger than other algorithms, HIGHT and RECTANGLE are in the second and third positions. As expected, Piccolo and PRESENT have the minimum decryption throughput values for both devices (Fig. 22).

Fig. 21
figure 21

Average decryption throughput (Raspberry Pi 3)

Full size image
Fig. 22
figure 22

Average decryption throughput (Arduino Mega 2560)

Full size image

3 Conclusion and Future Works

Internet of Things is composed of interrelated devices that exchange data among themselves. Many of the IoT devices are sending sensitive information that should be accessible only by legal authorities. Therefore, securing the data is a significant priority for an IoT network. To provide end-to-end security for low-power devices, we can apply lightweight block ciphers. In this article, we chose ten lightweight block ciphers and tested their performance over Raspberry Pi 3 and Arduino Mega 2560 devices. We measured encryption/decryption functions performance for different payloads due to memory usage (RAM and ROM), execution time, throughput, and energy consumption.

This paper will help readers to select the right platform and enciphering algorithm due to multiple factors like energy and memory usage, especially for software platforms. As future work, we can expand results for more block ciphers, compare their performance with other enciphering techniques such as stream ciphers, and do tests over new IoT testbeds.