IEEE INTERNET OF THINGS JOURNAL, VOL. 8, NO.

10, MAY 15, 2021 8279

Comparative Performance Analysis of Lightweight

Cryptography Algorithms for IoT Sensor Nodes
Amir Fotovvat , Gazi M. E. Rahman , Graduate Student Member, IEEE, Seyed Shahim Vedaei ,
and Khan A. Wahid , Senior Member, IEEE

Abstract—The Internet of Things (IoT) has become an inte- cities, medical and healthcare, connected cars, agricultural
gral part of future solutions, ranging from industrial to everyday automation, and surveillance, users in such a large network
human life applications. Adding a new level of intelligence will not be safe if the IoT functions or data are abused or
to objects and automating decisions make this new technol-
ogy appealing to everyone. However, applications that involve compromised [2]. In [3], some major vulnerabilities in IoT
data are more vulnerable to various types of attacks. As a result, are categorized as: 1) insufficient authentication or authoriza-
researchers are constantly exploring secure connections between tion, such as lack of high-level and low-level access controls;
IoT edge nodes. On one hand, suitable IoT nodes should be 2) insecure network services, such as exposure against denial-
cheap and require low power, which means lower computa- of-service attacks; 3) lack of transport encryption/integrity
tional performance. On the other hand, a secure connection
layer is power hungry and requires powerful hardware resources. verification (usually no encryption is used in transmission of
Lightweight cryptography (LWC) algorithms are a promising information); 4) insecure software and firmware, such as lack
solution to reduce computation complexity while maintaining of management systems for updating the software of devices;
a desired level of security. In the presented work, we attempt to and 5) poor physical security, such as removable memories
address the issue of adding security to the IoT network layer by and access to the firmware via ports. These are among the
comparing the performance of 32 LWC algorithms with currently
well-known algorithms on multiple IoT platforms (Raspberry Pi most important factors that must be addressed to ensure the
3, Raspberry Pi Zero W, and iMX233). These 32 authenticated safety of IoT environments; otherwise, many devices, such as
encryption with associated data algorithms have been selected robots, sensors, cars, and refrigerators will be vulnerable. This
from the second round of the LWC standardization process con- can have unimaginable consequences for people, governments,
ducted by the National Institute of Standards and Technology. and industries. Therefore, the first step required before we fully
Power consumption, random access memory usage, and execu-
tion time are measured for these algorithms using the targeted enable the IoT to be applied is to establish standards for its
embedded platforms that are used as IoT sensor nodes. The software and hardware. Also, it is worth noting that the iden-
results of this study will assist researchers in choosing a suitable tification and rectification of security issues in the IoT is more
platform and optimal LWC algorithm for IoT applications. challenging than in the Internet. This is because of the inher-
Index Terms—Authenticated encryption with associated data ent features that the IoT provides, such as connecting physical
(AEAD) algorithms, Internet of Things (IoT), lightweight cryp- actions with remote communications through a various range
tography (LWC), security. of devices and sensors.
Currently, most of the IoT devices do not use secure encryp-
I. I NTRODUCTION tion or authentication algorithms in their communications [3],
ITH the increasing demand for the Internet of
W Things (IoT) and its applications in today’s markets
and industry, the importance of security in device-to-device
which can lead to spoofing and eavesdropping attacks. In med-
ical applications, there are many implantable devices that are
resource constrained, such as the ECG pacemakers, which use
communications among edge nodes is becoming more and embedded microprocessors and integrated circuits with lim-
more critical. It has been predicted that the number of IoT ited memory, processing power, and power consumption [4].
devices will grow to 75 billion by 2025; currently, this num- Failure to use of proper encryption in these devices may
ber is around 7 billion [1]. Consequently, in the near future, lead to severe consequences, such as unauthorized access
the Internet network will become much more complex, with of private data, manipulation of device functioning, etc. [5].
a rapidly increasing amount of data circulating through it. There are many trusted encryption algorithms widely used
Considering the variety of IoT applications, such as smart over the Internet, which are generally designed for servers,
smartphones, and desktops [7], e.g., advanced encryption stan-
Manuscript received July 23, 2020; revised September 18, 2020, October
20, 2020, and November 26, 2020; accepted December 10, 2020. Date of pub- dard (AES) and Rivest–Shamir–Adleman (RSA). However,
lication December 15, 2020; date of current version May 7, 2021. This work these ciphers might not be the right choice for IoT edge
was supported in part by Natural Sciences and Engineering Research Council nodes or implantable medical devices. Because of the resource
of Canada (NSERC) and in part by the Canada First Research Excellence Fund
(CFREF). (Amir Fotovvat, Gazi M. E. Rahman, and Seyed Shahim Vedaei limitations of these devices, we need to look for encryp-
contributed equally to this work.) (Corresponding author: Amir Fotovvat.) tion algorithms that require small hardware footprints. Such
The authors are with the Department of Electrical and Computer algorithms are known as lightweight cryptography (LWC).
Engineering, University of Saskatchewan, Saskatoon, SK S7N 5A9, Canada
(e-mail: [email protected]). In a recent survey [6], the importance of using such LWC
Digital Object Identifier 10.1109/JIOT.2020.3044526 algorithms in different layers of an IoT system using various
2327-4662 
c 2020 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission.
See https://www.ieee.org/publications/rights/index.html for more information.
Authorized licensed use limited to: Somaiya University. Downloaded on April 04,2025 at 06:19:37 UTC from IEEE Xplore. Restrictions apply.
8280 IEEE INTERNET OF THINGS JOURNAL, VOL. 8, NO. 10, MAY 15, 2021

TABLE I
hardware platforms is discussed. In the hardware implemen- S ELECTED C RYPTOGRAPHY A LGORITHMS
tation of LWC algorithms, performance can be defined as
the required gate area, the number of logic blocks, or gate
equivalents. In software implementations, the performance of
these algorithms is reflected in random access memory (RAM),
read only memory [7], [8], and central processing unit (CPU)
usage. Power consumption, latency, and throughput are other
factors that need to be considered in the tradeoff between
the desired level of security and the resources in IoT nodes.
Power consumption is especially important in battery-operated
devices. In real-time applications, latency is critical and is
defined as the interval between the initial request and the
production of output. Throughput is the rate of output gener-
ation. In comparing LWC algorithms to previous algorithms,
throughput is not of high importance, though we still need
it to be acceptable [7]. So far, there is no general agreement
on the encryption/authentication algorithms for IoT networks.
However, recently more attention is directed toward develop-
ment of these algorithms. Since 2015, the National Institute
of Standards and Technology (NIST) has been looking for
suitable LWC solutions. In 2019, it started a standardization
process to select the best LWC algorithms for constrained
devices. In the second round of the process, 32 algorithms
were selected for final consideration (the list is shown in
Table I). These algorithms are new and have high potential to
be used in future applications. In this article, the performance
of the mentioned algorithms is investigated and compared with
themselves and with previously known authenticated encryp-
tion algorithms, such as Galois/counter mode (GCM), counter
with cipher block chaining mode (CCM), and offset codebook
mode (OCB) with AES as the block encryption in terms of
power consumption, execution time, and memory requirements
on three different IoT embedded platforms. All tested ciphers
are in authenticated encryption with associated data (AEAD)
format, which takes plain text, associated data, nonce, and integrates discrete wavelet transform, AES, and RSA tech-
key as inputs. In the AEAD algorithms, the plain text will be niques to encrypt medical images. Singh et al. [13] discussed
encrypted but the associated data are not, as we sometimes do the usage of lightweight encryption algorithms in IoT devices.
not need to encrypt a portion of data, such as headers, although They suggested a method to assign an encryption algorithm to
they still should be authenticated. The AEAD algorithms are each IoT device based on the memory space, battery power,
secure as long as the nonce is unique for each encryption (with message data size, and the computation power. Such methods
the same key) [9]. can also be implemented in a fog device where communica-
tions of edge devices are being controlled. Hence, as soon as
a new device connects to the network, the server automati-
II. R ELATED W ORKS cally configures the encryption and protocols for the new IoT
Many researchers have been trying to tackle the aforemen- device.
tioned security issues in IoT systems. Gonzalez et al. [10] End-to-end encryption is a vital component in the security
proposed software-defined networking (SDN) to make deci- of IoT networks. There are many papers on common non-
sions about message forwarding within an IoT network. It can lightweight encryption algorithms. In [14], the performance
be utilized to limit the access of some devices to other nodes of some famous symmetric key encryption algorithms, such
or even to the Internet. Miettinen et al. [11] presented a model as AES, Twofish, Speck, RC6, and LEA in the GCM mode
that can automatically identify the type of devices connected of operation and with different key sizes are evaluated.
to an IoT network. This can be done by collecting fingerprints These algorithms are compared based on battery drain,
of different devices during the communication setup. Then, throughput, and execution time. In this work, AES is shown
with the help of machine learning models, the authors’ model to have the highest encryption throughput, but its software
was able to detect types and software versions of IoT devices implementation consumed more power compared to others.
with high accuracy. This information can be used for software The authors concluded that the Speck algorithm can be used
updates through an SDN controller. In [12], a model for secure instead of AES as it consumes less energy while having good
data transmission in healthcare IoT systems is discussed. It encryption speed. Maitra et al. [15] tested the required timing,

Authorized licensed use limited to: Somaiya University. Downloaded on April 04,2025 at 06:19:37 UTC from IEEE Xplore. Restrictions apply.
FOTOVVAT et al.: COMPARATIVE PERFORMANCE ANALYSIS OF LIGHTWEIGHT CRYPTOGRAPHY ALGORITHMS FOR IoT SENSOR NODES 8281

TABLE II
memory, and power for software implementation of AES-256 AEAD A LGORITHM P ERFORMANCE M EASUREMENT M ATRICES
and XTEA ciphers on 8-b and 32-b microcontroller-based
systems. According to their results, XTEA can be a suitable
choice in sensor nodes, where there is not enough memory
and computation processing for AES implementation. In [16],
the power consumption of data encryption standard, AES,
and RSA ciphers for encryption and decryption of medical
images is evaluated.
Alrowaithy and Thomas [17] conducted a speed mea-
surement over C/C++ opensource cryptography libraries.
According to the experiment, the throughput for the same
algorithm varies significantly among different famous cryptog-
raphy libraries, e.g., Openssl, Botan, and Libgcrypt. In similar
papers, we rarely see detailed testing and analysis that include
all power, timing, and memory usage. Also, the mentioned
papers and similar works do not completely investigate the
LWC algorithms and their performance in a real-world IoT
setting.
Aside from the need for integrity and confidentiality of
information in IoT nodes, authentication algorithms should
also be implemented. In [18], a mutual authentication algo-
rithm for constrained devices is proposed that is based on
a new public key encryption method. The authors showed memory of LWC algorithms. We compared these LWC algo-
that their method is 88 times faster than RSA and seven rithms in detail in terms of hardware utilization and energy
times faster than the elliptic curve cryptography algorithm consumption for three different embedded IoT platforms. In
when using a security level of 112 b. Hwang and Gope [19] addition, we evaluated five of the algorithms in a simulated
propose new modes of operation that add authentication to real-life application using iMX233 and IoT sensor nodes based
encryption with a very low computational cost. They showed on long range (LoRa).
that the execution speed of their method is faster than other
authenticated encryption modes, such as GCM, CCM, and III. M ATERIALS AND M ETHODS
OCB. Esfahani et al. [20] present a lightweight authentication The presented work investigates and compares the
algorithm that only requires hash and XOR operations. The performance of lightweight AEAD algorithms in 32-b oper-
advantages of this method are low computational costs and low ating system (OS)-based embedded systems, which can be
memory usage. In a report from the NIST [7], primary outlines used for IoT applications. The NIST strongly encourages
and anticipations regarding message authentication codes, hash researchers to get involved in the evaluation of the candi-
functions, and cipher blocks are discussed for constrained date algorithms, focusing mainly on security, implementation,
devices. It also provides metrics and design considerations in and performance analysis. The following is a discussion of
order to measure the performance of different algorithms. In the methodology of this research. In the performance mea-
our article, we are targeting AEAD algorithms; thus, the results surement phase, we measured execution time, power, and
show the performance when implementing both authentication RAM usage for the algorithms over three hardware platforms
and encryption. As the selected algorithms are taken from the using different message sizes. Table II shows the matrices
NIST LWC standardization, which is currently ongoing, much used for the measurements. Three hardware platforms were
security and performance analysis must be performed on them. chosen from the popular and readily available single-board
Pugh et al. [21] discuss the importance of proper cryptographic computer or system on module, considering high, medium,
testing and some related challenges. They also performed and low resource availability with the capability to run an
different tests over NIST LWC candidates, such as bit con- embedded Linux OS. The selection of these platforms are con-
tribution, buffer check, and bit exclusion. In [22] and [23], sistent with the ones used widely in recent IoT applications [6].
two opensource benchmarking tools for hardware implementa- Table II lists some comparable similar platforms that could
tions are presented. They also provide the performance results also be used. We used 32-b processor as the implementation of
for several candidates. Rezvani and Diehl [24] measured the algorithms are mostly limited to high-level C-code; a few
energy, throughput, and area for five candidates using field- of the algorithms have implementations for FPGA, 8-b++++,
programmable gate array (FPGA) implementations. In [25], and 16-b hardware platforms. Fig. 1 illustrates the selected
a software execution speed test over all round two LWC candi- platforms and the experimental setups.
dates is provided, which is performed on Windows and Linux The first step was to select a suitable Linux OS for the hard-
operating systems. The tests are done with different compiler ware platforms and configure it with the minimum requirement
optimization levels, but RAM usage and energy consumption for AEAD implementation. Raspbian was selected for the
have not been measured. Our article contains a more compar- Raspberry Pi 3B (RPI-3B) and Raspberry Pi Zero W (RPI-
ative performance analysis for measuring speed, energy, and ZW), and Debian for the iMX233 board. GCC is used to

Authorized licensed use limited to: Somaiya University. Downloaded on April 04,2025 at 06:19:37 UTC from IEEE Xplore. Restrictions apply.
8282 IEEE INTERNET OF THINGS JOURNAL, VOL. 8, NO. 10, MAY 15, 2021

Fig. 1. Hardware IoT platforms used for experiment. (a) RPI-3B. (b) RPI-ZW. (c) iMX233. (d) Illustration of experimental setup [“IoT platform” can be
one of (a), (b), or (c)].

compile the AEAD codes without any memory sanitization 2) the PC sends another request to the target hardware to
or optimization to avoid extra time required while executing run the automation program written in python; 3) the python
the algorithms. Monitoring software was written in python lan- program executes the algorithm and gets its process identifica-
guage to monitor the CPU and RAM usage, which then stored tion (PID); 4) the automation program monitors the CPU and
the data in internal memory for processing and visualization. RAM usage for the known PID; 5) at the end of the algorithm,
We also set a test platform using a power measurement unit the automation program sends back the halt message to the
which is independent of the hardware platform that runs the PC; 6) the PC requests the measurement unit to stop the sam-
algorithms, as shown in Fig. 1(d). We also developed automa- pling and kill all related processes; and 7) finally, all data are
tion software for the power measurement unit to automate the stored on the PC for postprocessing. The same procedure takes
energy and power measurement functionality. place for all 32 algorithms on the three different hardware plat-
All units in Fig. 1(d) run simultaneously; both the monitor- forms, one by one. The sampling time for the CPU, RAM, and
ing and testing IoT platforms are configured to run with min- power measurements are set to 10 ms. In addition, all samples
imum resources. Universal asynchronous receiver–transmitter are tagged with the time for synchronization of the captured
communication was used for the secure shell (SSH) connec- data from different devices.
tion. All the boards are powered up by a 5 V, 3-A adaptor
for which the voltage and current are constantly monitored
by an interintegrated circuit (I2C) digital wattmeter from IV. R ESULTS AND D ISCUSSIONS
DFROBO. The wattmeter is capable of sampling voltage with The data collection procedure is divided into four phases:
a resolution of 4 mV and a relative error of less than ±0.2%. In 1) reference measurement; 2) test case 1 (different hard-
addition, the current resolution is 1 mA with a ±0.2% relative ware platforms); 3) test case 2 (different message sizes); and
error. The wattmeter module is connected to a microproces- 4) test case 3 (IoT sensor node application). In test case 1, all
sor through an I2C connection, which is designated as power 32 AEAD algorithms are executed using the same benchmark
measurement unit (as depicted in Fig. 1(d), the RPI-3B is used to measure their performance in terms of execution time, CPU
for the power measurement unit), and a python script handles load, RAM usage, and energy requirement. For each algorithm,
the data acquisition procedure and stores all the data in the 1082 executions with different combinations of message and
measurement unit locally. All data are then used for offline associated data size (from 0 to 32 B) is performed. In test
processing and performance analysis. Both the measurement case 2, the execution time and RAM requirement are mea-
unit and the targeted platform are controlled and monitored sured using three different message sizes (100 B, 1kB, and
using a remote personal computer (PC) through the SSH. The 10 kB) to evaluate the effect of message size and memory
experiment process is as follows: 1) the PC sends a request to management. Test case 3 is performed on an IoT sensor
the measurement unit to start sampling the voltage and current; node with a LoRa wireless module. In this experiment, five

Authorized licensed use limited to: Somaiya University. Downloaded on April 04,2025 at 06:19:37 UTC from IEEE Xplore. Restrictions apply.
FOTOVVAT et al.: COMPARATIVE PERFORMANCE ANALYSIS OF LIGHTWEIGHT CRYPTOGRAPHY ALGORITHMS FOR IoT SENSOR NODES 8283

Fig. 2. Power consumption at different software activities for RPI-3B. (a)

AEAD algorithms are used to encrypt the sensor data (30 B)

before transmitting, using the LoRa interface. The main objec-
tive of this experiment is to measure the contribution of the
AEAD algorithms in terms of time and energy usage while
transmitting sensor data over the LoRa interface.

A. Reference Measurement (b)

First, power measurement is started by determining the base
Fig. 3. (a) AEAD CPU and RAM utilization. (b) AEAD Power utilization
power consumption of each platform (average power consump- along with the automation software.
tion for the OS and automation software without running the
AEAD algorithms). Fig. 2 shows the detailed power mea-
surement data acquired using the RPI-3B where we can see went back to 0 again after the end of execution. On the other
the variations of the power (or energy) usage during differ- hand, Fig. 3(b) shows the power consumption profile from
ent activities. We added a delay after every activity to avoid start to finish of the CPU monitoring software that was used
the transitional data and applied a filter to remove instanta- to start the AEAD algorithm and monitor the PID-based CPU
neous values due to the CPU execution cycle. The RPI-3B usage. This extra data acquisition was performed to verify the
is connected remotely through the virtual network comput- power consumption with the base consumption as shown in
ing (VNC) viewer and remote terminal (using SSH), which Fig. 2.
detects data on power performance, such as voltage, current,
and the power when the energy monitoring unit is used. As B. Test Case 1: Different Hardware Platforms
shown in Fig. 2, in Zone-1, we ran a text editor (Geany) from For the final data collection, all the AEAD codes were
the remote terminal, which shows the total power consump- used as received from the NIST without any optimization.
tion for the OS processes, VNC viewer, text editor, and all From previously common authenticated encryption algorithms
hardware components used during these activities. Similarly, we selected GCM [61], OCB [62], and CCM [63] modes
in Zone-2, we started a process to monitor the system (proces- of operation. Unlike OCB, GCM and CCM are both patent-
sor and memory) utilization by running Linux “top” command. free algorithms. For these algorithms, we used the OpenSSL
As a result, we observed an incremental change in power con- library with AES as the block encryption. The RPI-3B, RPI-
sumption. In Zone-3, we stopped the text editor and observed ZW, and iMX233 were employed as the platforms under test
a decrement in power and current curves. In Zone-4 and and a same structured test for each algorithm was used, in
Zone-5, we stopped the VNC viewer and realized a gradual which encryption and decryption were performed 1082 times
decrease in power consumption. Finally, we stopped the “top” for different combinations of message and associated data sizes
process and observed very low-power consumption in Zone- (from 0 to 32 B). Then, the overall execution time, RAM, and
6 that is due to the Linux process and the hardware used at energy consumption were reported. After postprocessing of
that time. the acquired data, it was found that some of the algorithms
Then, we executed the AEAD algorithms and monitored showed a relatively similar processing time. Fig. 4 shows the
their power consumption curves (voltage, current, and power), algorithms’ total execution time on three different hardware
and the time of execution for the iMX233 board, as shown in platforms arranged from the fastest to the slowest algorithm
Fig. 3. This power performance analysis helped us to measure with the non-LWC algorithms (GCM, OCB, and CCM) at
the power consumption while the AEAD algorithms were exe- the beginning. It is worth mentioning that six of the last
cuted. Fig. 3(a) shows the percentage of CPU and RAM usage seven algorithms with highest execution time (in Fig. 4) are
for a particular AEAD algorithm, and Fig. 3(b) shows the permutation-based ciphers. Among the seven algorithms with
power usage at the same time. In Fig. 3(a), both the CPU and the lowest execution time, four of them are block cipher based,
RAM utilization curves went from 0 to their maximum level two are permutation based, and one is tweakable block cipher
within a very short time just after running the algorithm, and based.

Authorized licensed use limited to: Somaiya University. Downloaded on April 04,2025 at 06:19:37 UTC from IEEE Xplore. Restrictions apply.
8284 IEEE INTERNET OF THINGS JOURNAL, VOL. 8, NO. 10, MAY 15, 2021

Fig. 4. AEAD execution time on three different hardware platforms (arranged from low to high execution time, and keeping non-LWC algorithms at the
beginning).

Fig. 5. AEAD maximum RAM requirement (kept in the same sequence as in Fig. 4).

Fig. 6. AEAD CPU utilization in three different hardware platforms (kept in the same sequence as in Fig. 4).

In Fig. 5, the maximum RAM usage for the LWC algorithms Fig. 6 shows the CPU utilization for the LWC and three AES
and three non-LWC algorithms are shown. All the algorithms algorithms. Although there are some variations for different
use the lowest amount of RAM while executed in the RPI-3B algorithms, most of them were in a specific range, depending
and highest while executed in the RPI-ZW. According to the on the employed hardware platform. The iMX233 shows the
results, the LWC algorithms use 308–368 kB of RAM in the lowest CPU utilization ranging from 61% to 64.9%, and the
RPI-3B. For the IMX board they use 424–500 kB RAM, which RPI-ZW shows between 70.9% to 78.7%. The RPI-3B shows
is slightly higher than the RPI-3B. However, all the LWC algo- the maximum among the three, which is from 79.9% to 94.9%.
rithms use much more RAM in the RPI-ZW, which is above The iMX233 is a single-core processor and has the lowest
968 kB and up to 1180 kB. SPARKLE is found to be the lowest speed. It was able to dedicate lower CPU resources to execute
RAM-consuming LWC algorithm for all three hardware plat- the algorithms while performing the other tasks of the OS itself
forms. The Oribatida, ASCON, and Grain-128AEAD are the along with the data display. At the same time, the RPI-3B hav-
highest RAM-consuming algorithms in the RPI-3B, IMX, and ing a quad-core CPU was able to dedicate one of the cores for
RPI-ZW platforms, respectively. However, GCM, OCB, and the AEAD algorithms and had the fastest processing time by
CCM required almost 2.5 times RAM compared to the LWC utilizing almost 95% of the CPU. Among the LWC algorithms,
algorithms for all three platform. Therefore, these algorithms Saturnin occupied the lowest and Elephant occupied the high-
may not be suitable for IoT sensor nodes. est CPU utilization in IMX. Whereas, ASCON got the lowest

Authorized licensed use limited to: Somaiya University. Downloaded on April 04,2025 at 06:19:37 UTC from IEEE Xplore. Restrictions apply.
FOTOVVAT et al.: COMPARATIVE PERFORMANCE ANALYSIS OF LIGHTWEIGHT CRYPTOGRAPHY ALGORITHMS FOR IoT SENSOR NODES 8285

Fig. 7. Energy consumption of the AEAD algorithms.

and SpoC got the highest CPU utilization in the RPI-ZW; Fig. 8. Power consumption of different HW platforms while running one
SAEAES utilized the least and Romulus utilized the most CPU algorithm. The “call out” box shows the base power consumption.
in the RPI-3B platform. All three non-LWC algorithms uti-
lized the CPU less than some of the LWC algorithms, such as
Subterranean in all three hardware platforms. The same exper- this experiment is to convey only the effect of the message
iment was performed on a PC with a corei7 intel and 8 GB of size on the LWC algorithms. We repeated the encryption and
RAM, and execution time was found to be faster compared to decryption of the messages ten times and measured the execu-
the RPI-3B. However, the relative performance results among tion time and RAM usage for each one. Then, to derive a single
the algorithms remained almost the same. time iteration, the execution time was divided by a factor of
The energy consumption also depended on the execution ten. For better accuracy, we repeated this process several times
time as shown in Fig. 7. Among the three hardware plat- for each algorithm and then reported the average as the exe-
forms, the RPI-ZW always demonstrated the lowest energy cution time. Fig. 9 shows the algorithms arranged according
consumption for almost all the LWC and AES algorithms. The to their execution time for a single encryption and decryption
IMX showed the highest energy consumption for all the LWC of a 10-kB message (with non-LWC algorithms at the begin-
algorithms; however, the three AES algorithms consumed less ning). By comparing the execution times as shown in Fig. 9,
energy compared to the consumption for the RPI-3B plat- there were some changes in the order of algorithms compared
form. All the LWC algorithms followed a similar sequence to test case 1 (Fig. 4). These variations may be due to the dif-
in terms of energy consumption for all three hardware plat- ferences in test cases 1 and 2 (differences in message sizes and
forms. Fig. 7 shows that almost two thirds of the LWC repetition times). Comparing the performance of all 32 algo-
algorithms consume less than 1 J in the IMX. One-third of rithms in terms of message size,we found increasing execution
them consume as low as 500 mJ for the same hardware time with the increase of text input length. Table III shows
platform. Among the ten high-energy-consuming LWC algo- the RAM requirement for three different message sizes. It can
rithms, Grain-128, Elephant, and Oribatida consume more be seen that the RAM requirement for algorithms is almost
than 5 J in the IMX platform. Among the LWC algorithms, the same for input messages shorter than 1 kB, but increases
TinyJambu is the lowest energy-consuming algorithm in the from 5% to 12% for a message size increase of ten times. The
IMX and RPI-3B, whereas, SPARKLE consumes the lowest only exception was found for the Grain-128 algorithm, which
in the RPI-ZW board. All three non-LWC algorithms con- showed an increase of 29%.
sume the lowest energy in the RPI-ZW when comparing all the
LWC algorithms. Among the hardware platforms, the energy
D. Test Case 3: IoT Sensor Node Application
consumption was highest for all the algorithms when using
the iMX233 board, but we chose this platform as the most In this section, we simulated an IoT application to collect
preferred option for the IoT end-node due to its low-power sensor data and send them over to a LoRa base station. Then,
consumption during both the AEAD execution and other tasks we analyzed the performance of the cryptography algorithms
(shown in Fig. 8). It shows that the iMX233 has the lowest and LoRa communication timing. The iMX233 platform was
power consumption of 260 mW; on the other hand, the RPI- selected as the hardware due to its low-power consumption
ZW and RPI-3B consume 420 mW and 2200 mW of power, and limited hardware resources.
respectively. It also shows the power consumption during the 1) Sensor Node Implementation: Several sensors were con-
execution of the AEAD algorithms. nected with the iMX233 through the I2C interface, and the
LoRa module was connected through the serial interface. The
sensor node scanned the sensors every 30 s and performed
C. Test Case 2: Different Message Sizes LWC encryption, then transmitted the encrypted messages
In the next phase, experiments were designed to examine the to the receiver over the LoRa packet. On the receiver side,
dependency of execution time and RAM requirement versus another LoRa module was connected to an iMX233 that
message size; 100 B, 1 kB, and 10 kB message sizes were received and decrypted the LoRa packet to get the sensor data.
used. Here, we used the iMX233 platform, since the goal of An illustration of the experiment is depicted in Fig. 11. The

Authorized licensed use limited to: Somaiya University. Downloaded on April 04,2025 at 06:19:37 UTC from IEEE Xplore. Restrictions apply.
8286 IEEE INTERNET OF THINGS JOURNAL, VOL. 8, NO. 10, MAY 15, 2021

Fig. 9. AEAD algorithm comparison for three different text lengths on iMX233 hardware platform in terms of processing time, arranged from the fastest
to slowest algorithm according to the 10-kB message size with non-LWC algorithms at the left (kept in the same sequence as in Fig. 4).

TABLE III
M EMORY U SAGE V ERSUS M ESSAGE S IZE

Fig. 10. Timing profile for IoT sensor node application using the ACE
algorithm.

TABLE IV
L O R A PARAMETERS

process (shown in Fig. 11), which is given as follows:

T = TSR + TENC + TLR + TTX (1)
where T is total processing time, TSR is sensor read time,
TENC is encryption time, TLR is CPU to LoRa module com-
munication time, and TTX is LoRa transmission time. In (1),
TSR , TLR , and TTX are fixed. TSR mainly depends on the sen-
sor type, TLR depends on the interface type and configuration
used in CPU to LoRa communication, and TENC depends on
reading time of a sensor depends on the complexity of the the LWC algorithms. Therefore, the total processing time (T)
library and the number of registers configured. For this experi- is only dependent on TENC for a hardware platform (or sen-
ment, I2C was configured to work at 100 kHz. The sensor node sor node). TTX depends on the LoRa configuration and can be
has the capability to store the sensor’s data with the timestamp calculated using (2), which is derived from the manufacturer
in local storage, which gives the flexibility to maintain connec- datasheet [64]. It is validated using the online calculator [65]
tivity or send the data offline in an unstable network. However, for the LoRa parameters given in Table IV
the sensor reading time is clearly related to the type of sensor     SF 
2PL − SF + 7 2
used for the sensor node. We used four sensors, and the total TTX = 20.25 + ceil 5 . (2)
reading time was around 14 ms. The timing profile for the SF BW
sensor node and the receiver is illustrated in Fig. 10. The parameters CR, CRC, D, H, and nPR used in the
2) Time Modeling: Based on our experimental data, we can datasheet are not shown here, as their corresponding values
derive the expression of the total time required for a complete were kept fixed for this experiment. However, their values

Authorized licensed use limited to: Somaiya University. Downloaded on April 04,2025 at 06:19:37 UTC from IEEE Xplore. Restrictions apply.
FOTOVVAT et al.: COMPARATIVE PERFORMANCE ANALYSIS OF LIGHTWEIGHT CRYPTOGRAPHY ALGORITHMS FOR IoT SENSOR NODES 8287

Fig. 11. Secure IoT sensor node.

TABLE V
can be varied depending on the application, as given in the T IME AND E NERGY C ONSUMPTION OF THE I MX P LATFORM AS AN I OT
datasheet. In that case, (2) needs to be updated accordingly. N ODE IN T EST C ASE 3
3) Energy Modeling: A sensor node’s energy usage
depends on the required time for different processing stages
and the power consumption of each stage. All results for power
consumption in this experiment are shown in Fig. 8. The total
energy consumption (E) for a complete process is given by
E = TSR · PSR + TENC · PENC + TLR · PLR + TTX · PTX (3)
where E is the total energy, PSR is the power at sensor
read, PENC is the power for encryption, PLR is the power at
CPU to LoRa module communication, and PTX is the power
at LoRa transmission. Equation (3) shows that the sensor
reading energy (TSR · PSR ), module communication energy
(TLR · PLR ), and LoRa transmission energy (TTX · PTX ) are
fixed for a specific sensor node. The total energy (E) con-
sumption varies depending on the specific AEAD algorithms
(TENC · PENC ) in the sensor node. For the iMX233 hard-
ware platform, these parameters are measured experimentally. V. C ONCLUSION
It should be noted that these values (the time and power In this article, we presented a comparative study of the
requirements) may change depending on the chosen hardware performance 32 LWC algorithms that were implemented on
platform and LoRa configuration. three embedded platforms as IoT nodes. The platforms cho-
Table V shows the time and energy consumption for the first sen in the work can be used in multiple layers (such as,
five algorithms for test case 3 (the IoT sensor node applica- edge, fog, or cloud) of an IoT ecosystem. Parameters, such
tion). The LoRa packet consists of a 30-B encrypted message as energy consumption, RAM usage, and total execution
with an 8-b preamble. From Table V, it can be seen that the time, were monitored in different test scenarios and com-
encryption time to the total processing time ratio (TENC /T) pared with conventional authenticated encryption algorithms,
varies from 5% (for ACE) to 8% (for Elephant) and may go up such as AES-GCM, AES-CCM, and AES-OCB. The execu-
to 10% (for slower algorithms), which is not very significant tion time of the algorithms varies significantly. For example,
for a sensor node implementation. However, this performance in test case 1, it starts from 0.81 s for the Sparkle using
dependency on the AEAD algorithms might be more signif- the IMX233 platform, and goes to 25.4 s for the Oribatida.
icant in terms of energy consumption (encryption energy to The permutation-based ciphers appear to take longer time to
total energy) if we could reduce the base power consump- execute. The RAM requirement remains almost similar among
tion (shown in Fig. 8). This is possible by optimizing the the algorithms, even if we increase the message size from
OS’s processes and the hardware components used in the IoT 100 B to 1 kB. However, running the algorithms with 10 kB
sensor node. leads to an increase in RAM usage. The Grain-128AEAD

Authorized licensed use limited to: Somaiya University. Downloaded on April 04,2025 at 06:19:37 UTC from IEEE Xplore. Restrictions apply.
8288 IEEE INTERNET OF THINGS JOURNAL, VOL. 8, NO. 10, MAY 15, 2021

algorithm, which is a stream cipher, has the highest RAM [12] M. Elhoseny et al., “Secure medical data transmission model for IoT-
usage. In the latter part of the article, a practical application based healthcare systems,” IEEE Access, vol. 6, pp. 20596–20608, 2018,
doi: 10.1109/ACCESS.2018.2817615.
of the cryptography algorithm was tested on an IoT sensor [13] S. Singh, P. K. Sharma, S. Y. Moon, and J. H. Park, “Advanced
node. The experiment showed that the encryption time of LWC lightweight encryption algorithms for IoT devices: Survey, challenges
algorithms is insignificant compared to other timing require- and solutions,” J. Ambient Intell. Humanized Comput., to be published,
doi: 10.1007/s12652-017-0494-4.
ments, such as the read time of sensors and transmission time [14] D. A. F. Saraiva, V. R. Q. Leithardt, D. D. Paula, A. S. Mendes,
for wireless communication using LoRa. Therefore, a user G. V. González, and P. Crocker, “PRISEC: Comparison of sym-
needs to carefully consider all these factors while choosing metric key algorithms for IoT devices,” Sensors, vol. 19, no. 19,
pp. 4312–4334, 2019, doi: 10.3390/s19194312.
components for different layers in an IoT system. [15] S. Maitra, D. Richards, A. Abdelgawad, and K. Yelamarthi,
In summary, the outcome of this study is twofold. It will “Performance evaluation of IoT encryption algorithms: Memory, timing,
provide useful information to general users on the type of and energy,” in Proc. IEEE Sensors Appl. Symp. (SAS), 2019, pp. 1–6,
doi: 10.1109/SAS.2019.8706017.
LWC algorithms to implement, as well as the hardware plat- [16] J. C. Pry and R. K. Lomotey, “Energy consumption cost analysis
forms to use in their particular resources-constrained IoT of mobile data encryption and decryption,” in Proc. IEEE Int. Conf.
applications. In addition, it will assist researchers in weighing Mobile Services (MS), San Francisco, CA, USA, 2016, pp. 178–181,
doi: 10.1109/MobServ.2016.35.
pros and cons of different design topologies (e.g., permutation [17] M. Alrowaithy and N. Thomas, “Investigating the performance of
versus block cipher) and develop future LWC algorithms that C and C++ cryptographic libraries,” in Proc. 12th EAI Int. Conf.
are more suitable for hardware-limited applications. Future Perform. Eval. Methodol. Tools, Palma, Spain, 2019, pp. 167–170,
doi: 10.1145/3306309.3306335.
research is directed toward evaluating the performance of these [18] N. Li, D. Liu, and S. Nepal, “Lightweight mutual authentication for
LWC algorithms using low-resource hardware platforms in IoT and Its applications,” IEEE Trans. Sustain. Comput., vol. 2, no. 4,
terms of security and integrity, especially against the side- pp. 359–370, Oct./Dec. 2017, doi: 10.1109/TSUSC.2017.2716953.
[19] T. Hwang and P. Gope, “IAR-CTR and IAR-CFB: Integrity aware real-
channel attacks. Moreover, due to the use of many 8-b or time based counter and cipher feedback modes,” Security Commun.
16-b processors in IoT edge nodes, the performance analysis Netw., vol. 8, no. 18, pp. 3939–3952, 2015, doi: 10.1002/sec.1312.
of LWC algorithms on such lower end devices is beneficial. [20] A. Esfahani et al., “A lightweight authentication mechanism for M2M
communications in industrial IoT environment,” IEEE Internet Things J.,
vol. 6, no. 1, pp. 288–296, Feb. 2019, doi: 10.1109/JIOT.2017.2737630.
R EFERENCES [21] S. Pugh, M. S. Raunak, D. R. Kuhn, and R. Kacker, “Systematic testing
of lightweight cryptographic implementations,” presented at the Lightw.
[1] Statista. Global Number of Connected IoT Devices 2015–2025. Cryptography Workshops, Gaithersburg, MD, USA, Nov. 6, 2019.
Accessed: Mar. 1, 2020. [Online]. Available: https://www.statista.com/ Accessed: Jul. 10, 2020. [Online]. Available: https://csrc.nist.gov/events/
statistics/1101442/iot-number-of-connected-devices-worldwide/? 2019/lightweight-cryptography-workshop-2019
[2] Z. B. Celik, E. Fernandes, E. Pauley, G. Tan, and P. D. Mcdaniel, [22] A. Abdulgadir, W. Diehl, and J. P. Kaps, “An open-source platform
“Program analysis of commodity IoT applications for security and for evaluating side-channel countermeasures in hardware implementa-
privacy,” ACM Comput. Surveys, vol. 52, no. 4, pp. 1–30, 2019, tions of lightweight authenticated ciphers,” presented at the Lightw.
doi: 10.1145/3333501. Cryptography Workshops, Gaithersburg, MD, USA, Nov. 5, 2019.
[3] E. Bertino and N. Islam, “Botnets and Internet of Things Accessed: Jul. 10, 2020. [Online]. Available: https://csrc.nist.gov/events/
security,” Computer, vol. 50, no. 2, pp. 76–79, Feb. 2017, 2019/lightweight-cryptography-workshop-2019
doi: 10.1109/MC.2017.62. [23] L. C. dos Santos, J. Großschädl, and A. Biryukov, “FELICS-AEAD:
[4] L. Yan et al., “A 680 nA ECG acquisition IC for leadless pace- Benchmarking of lightweight authenticated encryption algorithms,”
maker applications,” IEEE Trans. Biomed. Circuits Syst., vol. 8, no. 6, presented at the Lightw. Cryptography Workshops, Gaithersburg, MD,
pp. 779–786, Dec. 2014, doi: 10.1109/TBCAS.2014.2377073. USA, Nov. 4, 2019. Accessed: Jul. 10, 2020. [Online]. Available: https://
[5] G. Zheng, G. Fang, R. Shankaran, and M. A. Orgun, csrc.nist.gov/events/2019/lightweight-cryptography-workshop-2019
“Encryption for implantable medical devices using modi- [24] B. Rezvani and W. Diehl, “Hardware implementations of NIST
fied one-time pads,” IEEE Access, vol. 3, pp. 825–836, 2015, lightweight cryptographic candidates: A first look,” presented at
doi: 10.1109/ACCESS.2015.2445336. the Lightw. Cryptography Workshops, Gaithersburg, MD, USA,
[6] M. N. Khan, A. Rao, and S. Camtepe, “Lightweight cryptographic pro- Nov. 5, 2019. Accessed: Jul. 10, 2020. [Online]. Available: https://csrc.
tocols for IoT constrained devices: A survey,” IEEE Internet Things J., nist.gov/events/2019/lightweight-cryptography-workshop-2019
early access, Sep. 24, 2020, doi: 10.1109/JIOT.2020.3026493. [25] G. Nisanci, R. Atay, M. K. Pehlivanoglu, E. B. Kavun, and T. Yalcin,
[7] K. A. McKay, L. E. Bassham, M. S. Turan, and N. Mouha, “Report on “Will the future lightweight standard be RISC-V friendly?” presented
lightweight cryptography,” NIST, Gaithersburg, MD, USA, Rep. NISTIR at the Lightw. Cryptography Workshops, Gaithersburg, MD, USA,
8114, 2016, doi: 10.6028/NIST.IR.8114. Nov. 4, 2019. Accessed: Jul. 10, 2020. [Online]. Available: https://
[8] N. A. Gunathilake, W. J. Buchanan, and R. Asif, “Next genera- csrc.nist.gov/events/2019/lightweight-cryptography-workshop-2019
tion lightweight cryptography for smart IoT devices: Implementation, [26] M. Aagard, R. AlTawy, G. Gong, K. Mandal, and R. Rohit. (2019).
challenges and applications,” in Proc. IEEE 5th World Forum ACE: An Authenticated Encryption and Hash Algorithm, Second Round
Internet Things (WF-IoT), Limerick, Ireland, 2019, pp. 707–710, Candidate of the NIST LWC Competition. [Online]. Available: https://
doi: 10.1109/WF-IoT.2019.8767250. csrc.nist.gov/events/2019/lightweight-cryptography-workshop-2019
[9] H. Bock, A. Zauner, S. Devlin, J. Somorovsky, and P. Jovanovic, [27] C. Dobraunig, M. Eichlseder, F. Mendel, and M. Schläffer. (2019).
“Nonce-disrespecting adversaries: Practical forgery attacks on GCM in ASCON, Second Round Candidate of the NIST LWC Competition.
TLS,” in Proc. 10th USENIX Workshop Offensive Technol. (WOOT), [Online]. Available: https://csrc.nist.gov/projects/lightweight-
Austin, TX, USA, 2016, p. 475. Accessed: Jul. 7, 2020. [Online]. cryptography/round-2-candidates
Available: https://www.usenix.org/conference/woot16/workshop- [28] S. Gueron, A. Jha, and M. Nandi. (2019). COMET: Counter Mode
program/presentation/bock Encryption With Authentication Tag, Second Round Candidate of
[10] C. Gonzalez, S. M. Charfadine, O. Flauzac, and F. Nolot, “SDN- the NIST LWC Competition. [Online]. Available: https://csrc.nist.gov/
based security framework for the IoT in distributed grid,” in Proc. Int. projects/lightweight-cryptography/round-2-candidates
Multidiscipl. Conf. Comput. Energy Sci. (SpliTech), 2016, pp. 67–72, [29] S. Riou. (2019). DryGASCON, Second Round Candidate of the NIST
doi: 10.1109/SpliTech.2016.7555946. LWC Competition. [Online]. Available: https://csrc.nist.gov/projects/
[11] M. Miettinen, S. Marchal, I. Hafeez, N. Asokan, A. Sadeghi, and lightweight-cryptography/round-2-candidates
S. Tarkoma, “IoT SENTINEL: Automated device-type identification for [30] T. Beyne, Y. L. Chen, and C. Dobraunig. (2019). Elephant V1.1,
security enforcement in IoT,” in Proc. IEEE 37th Int. Conf. Distrib. Second Round Candidate of the NIST LWC Competition. [Online].
Comput. Syst. (ICDCS), Atlanta, GA, USA, 2017, pp. 2177–2184, Available: https://csrc.nist.gov/projects/lightweight-cryptography/round-
doi: 10.1109/ICDCS.2017.283. 2-candidates

Authorized licensed use limited to: Somaiya University. Downloaded on April 04,2025 at 06:19:37 UTC from IEEE Xplore. Restrictions apply.
FOTOVVAT et al.: COMPARATIVE PERFORMANCE ANALYSIS OF LIGHTWEIGHT CRYPTOGRAPHY ALGORITHMS FOR IoT SENSOR NODES 8289

[31] A. Chakraborti, N. Datta, A. Jha, C. M. Lopez, M. Nandi, and [52] D. Bellizia et al. (2019). Spook: Sponge-Based Leakage-Resistant
Y. Sasaki. (2019). ESTATE. Second Round Candidate of the NIST Authenticated Encryption With a Masked Tweakable Block Cipher,
LWC Competition. [Online]. Available: https://csrc.nist.gov/projects/ Second Round Candidate of the NIST LWC Competition. [Online].
lightweight-cryptography/round-2-candidates Available: https://csrc.nist.gov/projects/lightweight-cryptography/round-
[32] E. Andreeva, V. Lallemand, A. Purnal, R. Reyhanitabar, A. Roy, and 2-candidates
D. Vizár. (2019). ForkAE V.1, Second Round Candidate of the NIST [53] J. Daemen, P. M. C. Massolino, and Y. Rotella. (2019). The
LWC Competition. [Online]. Available: https://csrc.nist.gov/projects/ Subterranean 2.0 Cipher Suite, Second Round Candidate of the NIST
lightweight-cryptography/round-2-candidates LWC Competition. [Online]. Available: https://csrc.nist.gov/projects/
[33] S. Banik et al. (2019). GIFT-COFB V1.0, Second Round Candidate lightweight-cryptography/round-2-candidates
of the NIST LWC Competition. [online]. Available: https://csrc.nist.gov/ [54] S. Banik et al. (2019). SUNDAE-GIFT V1.0, Second Round Candidate
events/2019/lightweight-cryptography-workshop-2019 of the NIST LWC Competition. [Online]. Available: https://csrc.nist.gov/
[34] D. J. Bernstein et al. (2019). Gimili, Second Round Candidate of projects/lightweight-cryptography/round-2-candidates
the NIST LWC Competition. [Online]. Available: https://csrc.nist.gov/ [55] H. Wu and T. Huang. (2019). TinyJAMBU: A Family of Lightweight
projects/lightweight-cryptography/round-2-candidates Authenticated Encryption AlgorithmsForkAE, Second Round Candidate
[35] M. Hell, T. Johansson, W. Meier, J. Sönnerup, and H. Yoshida. (2019). of the NIST LWC Competition. [Online]. Available: https://csrc.nist.gov/
Grain-128AEAD—A Lightweight AEAD Stream Cipher, Second Round projects/lightweight-cryptography/round-2-candidates
Candidate of the NIST LWC Competition. [Online]. Available: https:// [56] M. Aagaard, R. AlTawy, G. Gong, K. Mandal, R. Rohit, and
csrc.nist.gov/projects/lightweight-cryptography/round-2-candidates N. Zidaric. (2019). WAGE: An Authenticated Cipher, Second Round
[36] A. Chakraborti, N. Datta, A. Jha, and M. Nandi. (2019). HyENA, Candidate of the NIST LWC Competition. [Online]. Available: https://
Second Round Candidate of the NIST LWC Competition. [Online]. csrc.nist.gov/projects/lightweight-cryptography/round-2-candidates
Available: https://csrc.nist.gov/projects/lightweight-cryptography/round- [57] J. Daemen, S. Hoffert, M. Peeters, G. V. Assche, and R. V. Keer.
2-candidates (2019). A Lightweight Cryptographic Scheme Second Round Candidate
[37] C. Dobraunig et al. (2019). ISAP v2.0, Second Round Candidate of of the NIST LWC Competition. [Online]. Available: https://csrc.nist.gov/
the NIST LWC Competition. [Online]. Available: https://csrc.nist.gov/ projects/lightweight-cryptography/round-2-candidates
projects/lightweight-cryptography/round-2-candidates [58] Raspberry Pi Foundation. Raspberry Pi 3 Model B+. Accessed:
[38] W. Zhang et al. (2019). KNOT, Second Round Candidate of the NIST Jul. 12, 2020. [Online]. Available: https://www.raspberrypi.org/products/
LWC Competition. [Online]. Available: https://csrc.nist.gov/projects/ raspberry-pi-3-model-b-plus/
lightweight-cryptography/round-2-candidates [59] Raspberry Pi Foundation. Raspberry Pi Zero W. Accessed: Jul. 12, 2020.
[39] A. Chakraborti, N. Datta, A. Jha, C. M. Lopez, M. Nandi, and Y. Sasaki. [Online]. Available: https://www.raspberrypi.org/products/raspberry-pi-
(2019). LOTUS-AEAD and LOCUS-AEAD, Second Round Candidate of zero-w/
the NIST LWC Competition. [Online]. Available: https://csrc.nist.gov/ [60] Olimex. iMX233-OLinuXino-MICRO—Open Source Hardware Board.
projects/lightweight-cryptography/round-2-candidates Accessed: Jul. 12, 2020. [Online]. Available: https://www.olimex.com/
Products/OLinuXino/iMX233/iMX233-OLinuXino-MICRO/
[40] B. Chakraborty and M. Nandi. (2019). mixFeed, Second Round
open-source-hardware
Candidate of the NIST LWC Competition. [Online]. Available: https:/
[61] M. Dworkin, Recommendation for Block Cipher Modes of Operation:
/csrc.nist.gov/projects/lightweight-cryptography/round-2-candidates
Galois/Counter Mode (GCM) and GMAC, document NIST SP 800-
[41] B. Chakraborty and M. Nandi. (2019). ORANGE, Second Round
38D, NIST, Gaithersburg, MD, USA, 2007. [online]. Available: https://
Candidate of the NIST LWC Competition. [Online]. Available: https://
nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800–38d.pdf
csrc.nist.gov/projects/lightweight-cryptography/round-2-candidates
[62] P. Rogaway, M. Bellare, and J. Black, “OCB: A block-cipher mode of
[42] A. Bhattacharjee, E. List, C. M. López, and M. Nandi. (2019).
operation for efficient authenticated encryption,” ACM Trans. Inf. Syst.
Oribatida V1.2, Second Round Candidate of the NIST LWC
Security, vol. 6, no. 3, pp. 365–403, 2003, doi: 10.1145/937527.937529.
Competition. [Online]. Available: https://csrc.nist.gov/projects/
[63] M. Dworkin, Recommendation for Block Cipher Modes of Operation:
lightweight-cryptography/round-2-candidates
The CCM Mode for Authentication and Confidentiality, docu-
[43] Z. Bao et al. (2019). PHOTON-Beetle, Second Round Candidate of the ment NIST SP 800-38C, NIST, Gaithersburg, MD, USA, 2007.
NIST LWC Competition. [Online]. Availale: https://csrc.nist.gov/projects/ [Online]. Available: https://nvlpubs.nist.gov/nistpubs/Legacy/SP/
lightweight-cryptography/round-2-candidates nistspecialpublication800-38c.pdf
[44] D. Goudarzi et al. (2019). Pyjamask V1.0, Second Round Candidate [64] Semtech Corporation. SX1276 Datasheet. Accessed:
of the NIST LWC Competition. [Online]. Available: https://csrc.nist.gov/ Mar. 31, 2020. [Online]. Available: https://semtech.
projects/lightweight-cryptography/round-2-candidates my.salesforce.com/sfc/p/#E0000000JelG/a/2R0000001OKs/
[45] T. Iwata, M. Khairallah, K. Minematsu, and T. Peyrin. (2019). Romulus Bs97dmPXeatnbdoJNVMIDaKDlQz8q1N_gxDcgqi7g2o
V1.2, Second Round Candidate of the NIST LWC Competition. [Online]. [65] LoRa Online Calculator. Accessed: Mar. 31, 2020. [Online]. Available:
Available: https://csrc.nist.gov/projects/lightweight-cryptography/round- https://www.loratools.nl/#/airtime
2-candidates
[46] Y. Naito, M. Matsui, Y. Sakai, D. Suzuki, K. Sakiyama, and
T. Sugawara. (2019). SAEAES, Second Round Candidate of the NIST
LWC Competition. [Online]. Available: https://csrc.nist.gov/projects/
lightweight-cryptography/round-2-candidates
[47] A. Canteaut et al. (2019). “SATURNIN: A Suite of Lightweight
Symmetric Algorithms for Post-Quantum Security v1.1, Second Round
Candidate of the NIST LWC Competition. [Online]. Available: https://
csrc.nist.gov/projects/lightweight-cryptography/round-2-candidates
[48] C. Beierle et al. (2019). SKINNY-AEAD and SKINNY-Hash v1.1,
Second Round Candidate of the NIST LWC Competition. [Online].
Available: https://csrc.nist.gov/projects/lightweight-cryptography/round-
2-candidates Amir Fotovvat received the B.Sc. degree with
[49] C. Beierle et al. (2019). Schwaemm and Esch: Lightweight Authenticated a major in electrical engineering, telecommunica-
Encryption and Hashing Using the Sparkle Permutation Family tions, and a minor in computer software engineering
Second Round Candidate of the NIST LWC Competition. [Online]. from K. N. Toosi University of Technology, Tehran,
Available: https://csrc.nist.gov/projects/lightweight-cryptography/round- Iran, in 2019. He is currently pursuing the M.Sc.
2-candidates degree in electrical and computer engineering with
[50] R. AlTawy, G. Gong, M. He, K. Mandal, and R. Rohit. (2019). the University of Saskatchewan, Saskatoon, SK,
Spix: An Authenticated Cipher, Second Round Candidate of the NIST Canada.
LWC Competition. [Online]. Available: https://csrc.nist.gov/projects/ Since September 2019, he has been working as
lightweight-cryptography/round-2-candidates a Research Assistant with the Multimedia Processing
[51] R. AlTawy et al. (2019). SpoC: An Authenticated Cipher, Second Round and Prototyping Laboratory, University of
Candidate of the NIST LWC Competition. [online]. Available: https:// Saskatchewan. His research interests mainly include computer networks,
csrc.nist.gov/projects/lightweight-cryptography/round-2-candidates Internet security, Internet of Things, machine learning, and image processing.

Authorized licensed use limited to: Somaiya University. Downloaded on April 04,2025 at 06:19:37 UTC from IEEE Xplore. Restrictions apply.
8290 IEEE INTERNET OF THINGS JOURNAL, VOL. 8, NO. 10, MAY 15, 2021

Gazi M. E. Rahman (Graduate Student Member, Khan A. Wahid (Senior Member, IEEE) received
IEEE) received the B.Sc. and M.Sc. degrees in elec- the B.Sc. degree from Bangladesh University of
trical and electronic engineering from Bangladesh Engineering and Technology, Dhaka, Bangladesh, in
University of Engineering and Technology, Dhaka, 2000, and the M.Sc. and Ph.D. degrees from the
Bangladesh, in 1999 and 2008, respectively. He is University of Calgary, Calgary, AB, Canada, in 2003
currently pursuing the Ph.D. degree in electrical and 2007, respectively.
and computer engineering with the University of He is a Professor with the Department of
Saskatchewan, Saskatoon, SK, Canada. Electrical and Computer Engineering, University
He started his career with cellular communication of Saskatchewan, Saskatoon, SK, Canada. He has
service provider and continued for ten years, and coauthored three book chapters and over 180 peer-
contributed to automate some system management, reviewed journal and international conference papers
planning, and reporting system over there. He also worked as an Assistant in the field of health informatics, wireless capsule endoscopy, wearable health
Professor with the Electrical and Electronic Engineering Department, United monitoring, smart health, Internet of Things, and smart city. He has three
International University, Dhaka. He contributed to the commercial product patents. His research on capsule endoscopy was featured in local and Canadian
development based on embedded system and IoT for various industries. He national media (CBC, CTV, and Global). His work attracted funding from
has been working as a Research Assistant with the Multimedia Processing major Canadian and international agencies (NSERC, CFI, WED Canada,
and Prototyping Laboratory, University of Saskatchewan since May 2018. Grand Challenges, and Government of Saskatchewan).
His main research focuses on IoT-based WSN, embedded system design, and Prof. Wahid received many prestigious awards and scholarships, including
machine learning. the Most Distinguished Killam Scholarship and the NSERC Canada Graduate
Scholarship for his doctoral research, along with the Award of Innovation in
2016. He has been serving on the multidisciplinary review panel of several
national funding programs, including NSERC Discovery, I2I, New Frontiers
in Research Fund, and MITACS. He has served on the Technical Program and
Seyed Shahim Vedaei received the B.S. degree in Advisory Committee of numerous IEEE sponsored international conferences.
electrical and electronic engineering from Islamic He is a registered Professional Engineer in the Province of Saskatchewan.
Azad University Central Tehran Branch, Tehran,
Iran, in 2015, and the M.S. degree in electrical
and electronic engineering from Khajeh Nasir Toosi
University, Tehran, Iran, in 2018. He is currently
pursuing the Ph.D. degree in electrical engineering
with the University of Saskatchewan, Saskatoon, SK,
Canada.
He has been a Research Assistant with the
Multimedia Processing and Prototyping Laboratory,
University of Saskatchewan since January 2019. His current research interests
include, but not limited to, hardware design, the Internet-of-Things-based
smart systems, embedded software development, machine learning, and
biomedical system.

Authorized licensed use limited to: Somaiya University. Downloaded on April 04,2025 at 06:19:37 UTC from IEEE Xplore. Restrictions apply.