A Comparison of Lightweight Ciphers Meeting Nist

Home , AES instruction set, CRYPTREC, LEA (cipher), Prince (cipher)

A COMPARISON OF LIGHTWEIGHT CIPHERS MEETING NIST

LIGHTWEIGHT CRYPTOGRAPHY

REQUIREMENTS TO THE ADVANCED ENCRYPTION STANDARD

A Thesis

Presented to the

Faculty of

California State Polytechnic University, Pomona

In Partial Fulfillment

Of the Requirements for the Degree

Master of Science

Computer Science

Jose S. Figueroa-Hernandez

2018

SIGNATURE PAGE

THESIS: A COMPARISON OF LIGHTWEIGHT CIPHERS MEETING NIST LIGHTWEIGHT CRYPTOGRAPHY REQUIREMENTS TO THE ADVANCED ENCRYPTION STANDARD

AUTHOR: Jose S. Figueroa-Hernandez

DATE SUBMITTED: Fall 2018 Department of Computer Science

Dr. Ting Ting Chen Thesis Committee Chair Computer Science

Dr. Mohammad Husain Computer Science

Dr. Abdelfattah Amamra ___ Computer Science

ABSTRACT

As the Internet has become a major part of a person’s daily life, the type of devices connected to the Internet has expanded. Network access, including the Internet, is no longer just limited to general systems such as desktops, laptops, or servers. Now it has expanded to appliances, vehicles, cameras, pacemakers, and many others. These devices fall under the umbrella of the Internet of Things (IoT) which are non-general systems which are connected to a network, and since they are connected to a network, these IoT devices should also adhere to Information Security principles (confidentiality, integrity, availability) in order to protect their data. Encryption is a tool which provides confidentiality by making the data unreadable for those without the proper access; however, it is a costly process. Due to the nature of IoT devices, these devices may be constrained in their resources (e.g. power, memory, processor speed, etc.). This has led to the development of lightweight ciphers which can operate in those resource-constrained devices, such as those in IoT, compared to other general ciphers. This paper presents a comparison between the lightweight symmetric ciphers Present, Modified Symmetric

Encryption Algorithm, and LEA, and the current general symmetric standard Advanced

Encryption Standard (AES) on IoT devices across memory usage, execution time, and charge usage. A comparison will identify if lightweight ciphers provide a benefit over general ciphers, and it also provides the use cases in which a lightweight cipher can excel over other ciphers.

iii

TABLE OF CONTENTS Signature Page ...... ii

Abstract ...... iii

List of Tables ...... vii

List of Figures ...... ix

I. Introduction ...... 1

II. Literature Survey ...... 4

A. Overview of IoT ...... 4

1) IoT Technologies ...... 5

2) IoT Architecture: ...... 7

3) IoT Security ...... 11

4) IoT Security Challenges ...... 13

B. Overview of Cryptography and IoT ...... 15

1) Advanced Encryption Standard (AES) ...... 18

2) AES Instruction Set ...... 20

C. Overview of Lightweight Cryptography ...... 22

1) NIST Lightweight Cryptography Standardization ...... 23

2) PRESENT ...... 24

3) Modified Symmetric Encryption Algorithm (MSEA) ...... 26

4) LEA ...... 32

III. Research Goals...... 35

IV. Methodology ...... 36

A. Cipher Implementation ...... 36

1) AES ...... 36

2) PRESENT ...... 37

3) MSEA ...... 37

4) LEA ...... 37

5) Block Cipher Mode ...... 38

B. Testing Environment ...... 38

C. Cipher Testing ...... 39

V. Evaluation of Results ...... 40

VI. Results and Findings ...... 41

A. Individual Cipher Findings...... 41

1) AES ...... 41

2) AES-NI ...... 49

3) PRESENT ...... 57

4) MSEA ...... 65

5) MSEA-128 ...... 73

6) LEA ...... 82

B. Cipher Comparison ...... 90

1) Encryption/Decryption Times ...... 90

2) Charge Usage ...... 97

3) Memory Usage ...... 101

VII. Conclusion ...... 102

VIII. Future Works ...... 103

References ...... 104

LIST OF TABLES

Table I Sensing Layer Protocols ...... 9

Table II Examples of Network Services (Adapted from [16]) ...... 10

Table III Service Layer Components (Adapted from [1], [9]) ...... 11

Table IV AES Strength (Adapted from [27]) ...... 18

Table V AES-NI Set Instructions (Adapted from [29]) ...... 22

Table VI MSEA Parameter Values (Adapted from [38]) ...... 27

Table VII LEA Constants (Adapted from [39]) ...... 33

Table VIII AES memory usage...... 49

Table IX AES-NI memory usage ...... 56

Table X PRESENT Memory Usage ...... 64

Table XI MSEA Memory Usage ...... 73

Table XII MSEA128 Memory Usage ...... 81

Table XIII LEA Memory Usage ...... 89

Table XIV Encryption Times - 900 MHz ...... 92

Table XV Decryption Times - 900 MHz ...... 92

Table XVI Encryption Times - 1.0 GHz ...... 93

Table XVII Decryption Times - 1.0 GHz ...... 93

Table XVIII Encryption Times - 1.1 GHz ...... 95

Table XIX Decryption Times - 1.1 GHz ...... 95

Table XX Encryption Times - 1.2 GHz ...... 96

Table XXI Decryption Times - 1.2 GHz ...... 96

Table XXII Encryption Memory Usage of All Ciphers...... 102

vii

Table XXIII Decryption Memory Usage of All Ciphers ...... 102

viii

LIST OF FIGURES

Fig. 1 IoT architecture and transmission path of data ...... 8

Fig. 2 Encryption and Decryption process of AES (adapted from [18], [26], [27]) ...... 19

Fig. 3 PRESENT encryption and decryption processes...... 26

Fig. 4 MSEA Round Key Generation ...... 28

Fig. 5 Overall MSEA encryption process ...... 30

Fig. 6 Message expansion. Converts 8-bit blocks to 16-bit blocks which doubles the size of the overall message ...... 30

Fig. 7 Process performed each round in order to encrypt ...... 31

Fig. 8 LEA encryption rounds. Number of rounds performed dependent on selected key size ...... 34

Fig. 9 AES Encryption time at 900 MHz ...... 43

Fig. 10 AES Encryption time at 1.0 GHz ...... 44

Fig. 11 AES Encryption time at 1.1 GHz ...... 44

Fig. 12 AES Encryption time at 1.2 GHz ...... 45

Fig. 13 Average AES encryption time across all files and processor speeds ...... 45

Fig. 14 AES Decryption time at 900 MHz ...... 46

Fig. 15 AES Decryption time at 1.0 GHz ...... 46

Fig. 16 AES Decryption time at 1.1 GHz ...... 47

Fig. 17 AES Decryption time at 1.2 GHz ...... 47

Fig. 18 Average AES decryption time across all files and processor speeds ...... 48

Fig. 19 Charge usage of AES Encryption across file sizes...... 48

Fig. 20 Charge usage of AES Decryption across file sizes...... 49

Fig. 21 AES-NI Encryption time at 900 MHz ...... 51

Fig. 22 AES-NI Encryption time at 1.0 GHz ...... 51

Fig. 23 AES-NI Encryption time at 1.1 GHz ...... 52

Fig. 24 AES-NI Encryption time at 1.2 GHz ...... 52

Fig. 25 Average AES encryption time across all files and processor speeds ...... 53

Fig. 26 AES-NI Decryption time at 900 MHz ...... 53

Fig. 27 AES-NI Decryption time at 1.0 GHz...... 54

Fig. 28 AES-NI Decryption time at 1.1 GHz...... 54

Fig. 29 AES-NI Decryption time at 1.2 GHz...... 55

Fig. 30 Average AES-NI decryption time across all files and processor speeds ...... 55

Fig. 31 Charge usage of AES-NI Encryption across file sizes ...... 56

Fig. 32 Charge usage of AES-NI Decryption across file sizes ...... 56

Fig. 33 PRESENT Encryption time at 900 MHz ...... 59

Fig. 34 PRESENT Encryption time at 1.0 GHz...... 59

Fig. 35 PRESENT Encryption time at 1.1 GHz...... 60

Fig. 36 PRESENT Encryption time at 1.2 GHz...... 60

Fig. 37 Average PRESENT encryption time across all files and processor speeds ...... 61

Fig. 38 PRESENT Decryption time at 900 MHz ...... 61

Fig. 39 PRESENT Decryption time at 1.0 GHz ...... 62

Fig. 40 PRESENT Decryption time at 1.1 GHz ...... 62

Fig. 41 PRESENT Decryption time at 1.2 GHz ...... 63

Fig. 42 Average PRESENT decryption time across all files and processor speeds ...... 63

Fig. 43 Charge usage of PRESENT Encryption across file sizes ...... 64

Fig. 44 Charge usage of PRESENT Decryption across file sizes ...... 64

Fig. 45 MSEA Encryption time at 900 MHz ...... 67

Fig. 46 MSEA Encryption time at 1.0 GHz ...... 68

Fig. 47 MSEA Encryption time at 1.1 GHz ...... 68

Fig. 48 MSEA Encryption time at 1.2 GHz ...... 69

Fig. 49 Average MSEA encryption time across all files and processor speeds ...... 69

Fig. 50 MSEA Decryption time at 900 MHz ...... 70

Fig. 51 MSEA Decryption time at 1.0 GHz...... 70

Fig. 52 MSEA Decryption time at 1.1 GHz...... 71

Fig. 53 MSEA Decryption time at 1.2 GHz...... 71

Fig. 54 Average MSEA decryption time across all files and processor speeds ...... 72

Fig. 55 Charge usage of MSEA Encryption across file sizes ...... 72

Fig. 56 Charge usage of MSEA Decryption across file sizes ...... 73

Fig. 57 MSEA-128 Encryption time at 900 MHz ...... 76

Fig. 58 MSEA-128 Encryption time at 1.1 GHz ...... 76

Fig. 59 MSEA-128 Encryption time at 1.1 GHz ...... 77

Fig. 60 MSEA-128 Encryption time at 1.2 GHz ...... 77

Fig. 61 Average MSEA-128 encryption time across all files and processor speeds ...... 78

Fig. 62 MSEA-128 Decryption time at 900 MHz...... 78

Fig. 63 MSEA-128 Decryption time at 1.0 GHz ...... 79

Fig. 64 MSEA-128 Decryption time at 1.1 GHz ...... 79

Fig. 65 MSEA-128 Decryption time at 1.2 GHz ...... 80

Fig. 66 Average MSEA-128 decryption time across all files and processor speeds ...... 80

Fig. 67 Charge usage of MSEA-128 Encryption across file sizes ...... 81

Fig. 68 Charge usage of MSEA-128 Decryption across file sizes ...... 81

Fig. 69 LEA Encryption time at 900 MHz ...... 84

Fig. 70 LEA Encryption time at 1.0 GHz ...... 84

Fig. 71 LEA Encryption time at 1.1 GHz ...... 85

Fig. 72 LEA Encryption time at 1.2 GHz ...... 85

Fig. 73 Average LEA encryption time across all files and processor speeds ...... 86

Fig. 74 LEA Decryption time at 900 MHz ...... 86

Fig. 75 LEA Decryption time at 1.0 GHz ...... 87

Fig. 76 LEA Decryption time at 1.1 GHz ...... 87

Fig. 77 LEA Decryption time at 1.2 GHz ...... 88

Fig. 78 Average LEA decryption time across all files and processor speeds ...... 88

Fig. 79 Charge usage of LEA Encryption across file sizes ...... 89

Fig. 80 Charge usage of LEA Decryption across file sizes ...... 89

Fig. 81 Encryption time comparison at 900 MHz...... 91

Fig. 82 Decryption time comparison at 900 MHz ...... 91

Fig. 83 Encryption time comparison at 1.0 GHz ...... 92

Fig. 84 Decryption time comparison at 1.0 GHz ...... 93

Fig. 85 Encryption time comparison at 1.1 GHz ...... 94

Fig. 86 Decryption time comparison at 1.1 GHz ...... 94

Fig. 87 Encryption time comparison at 1.2 GHz ...... 95

Fig. 88 Decryption time comparison at 1.2 GHz ...... 96

Fig. 89 Cipher charge usage for encryption at 900 MHz ...... 97

xii

Fig. 90 Cipher charge usage for decryption at 900 MHz ...... 98

Fig. 91 Cipher charge usage for encryption at 1.0 GHz ...... 98

Fig. 92 Cipher charge usage for decryption at 1.0 GHz ...... 99

Fig. 93 Cipher charge usage for encryption at 1.1 GHz ...... 99

Fig. 94 Cipher charge usage for decryption at 1.1 GHz ...... 100

Fig. 95 Cipher charge usage for encryption at 1.2 GHz ...... 100

Fig. 96 Cipher charge usage for decryption at 1.2 GHz ...... 101

xiii

I. INTRODUCTION

With the development of mobile devices, and the introduction of the smartphone, the

Internet has become an integral part of a person’s daily life. Any type of information, from weather to flight times to the average speed of a cheetah, is available at a few keystrokes. This high availability of data has led for the push for more and more devices to become connected and accessible from anywhere in the world. A subset of these devices fall under the moniker of Internet of Things (IoT). However, a specific definition of what constitutes an IoT device has not been formally set due to the different technologies that exist and are being developed [1]. This has led to different definitions appearing based on the current viewpoint of the author or speaker. When the idea of IoT was first proposed in 1999, it referred to “uniquely identifiable interoperable connected objects with radio-frequency identification (RFID) technology [1].” Since this time, multiple types of communication technologies have been developed (e.g. nearfield communication (NFC), Bluetooth, wireless, etc.), and these technologies each have their own standards and communication protocols. As these new technologies have been created, an IoT definition has been created to cover it. By taking these definitions a broad definition of an IoT device can be inferred as: “everyday objects [that] can be equipped with identifying, sensing, networking, and processing capabilities that will allow them to communicate with one another and with other devices and services over the Internet to achieve some useful objective [2].” This general definition helps cover any existing and new concepts that may arise as networking capabilities are added to more and more devices.

As the definition above states, the development of new communication technologies is allowing devices which do not normally contain communication capabilities to be connected to networks and the Internet. Unlike devices that are normally networked

(servers, desktops, laptops, etc.), IoT devices are mostly composed of embedded systems with networking/communicating capabilities [3]. These embedded systems can exist in many common objects such as televisions, smoke detectors, door bells, etc., and their use continues to expand to different consumer and industrial applications. With this expansion, networking and communication technologies have been introduced to provide more functionality to the embedded systems [1]. The introduction of these major technologies and the evolution of IoT is shown in [1]. However, as with any device that communicates across a network (including the Internet), security issues are introduced for both the device and its end user(s) [3]. The security issue we are concerned with is the protection of data, or as it is known in Information Security, the confidentiality of the data. The confidentiality of data ensures that only authorized entities (users, other devices, services, etc.) are able to access the data; for all others, the data should not be usable [4]. Currently, one of the major methods used to maintain data confidentiality is by using encryption [5]. Encryption protects the data from unauthorized access, but at the cost of performing computationally expensive mathematical calculations. For systems such as desktops, servers, laptops, etc., these calculations are not a major concern since the systems have adequate computing resources (i.e. memory, processor speed, storage, power, etc.) [6]. These systems have the ability to allocate more resources to perform encryption operations without causing major impact to other system programs. However, due to the nature of IoT devices, the resources allocated to a device may be constrained

because of any number of factors. Some of these factors may deal with cost, and others

may deal with physical constrains of the device. With this constrain on resources, the use

of general cryptographic algorithms can cause a higher performance impact to other

device operations [6].

Since IoT devices must still provide confidentiality of data, these devices require

cryptographic algorithms that provide protection while maintaining device operation and

can be executed in devices with constrained resources. The need for these types of

algorithms has gave rise to the concept of Lightweight Cryptography. The concept of

lightweight cryptography is for the creation of algorithms which have require less

hardware and software resources [7]. At the same time, those algorithms must still

provide adequate security and performance without being overly costly in its deployment

[7]. In March 2017, the U.S. Department of Commerce National Institute of Standards

and Technology (NIST) released a report stating the current findings of their lightweight cryptography project, and their plans for lightweight cryptography standards [8]. The purpose of the NIST project is to “study the performance of the current NIST-approved cryptographic standards on constrained devices and to understand the need for dedicated lightweight cryptography standards, and if the need is identified, to design a transparent process for standardization [8].” The current NIST block cipher standard is the Advanced

Encryption Standard (AES) cipher family, and the Triple Data Encryption Algorithm

(TDEA) with NIST considering the AES-128 cipher as the most suitable for IoT applications [8]. In addition to the current standard, NIST provides requirements for the design of lightweight cryptography algorithms. In this paper, we compare proposed lightweight cryptography block ciphers with the NIST block cipher standard (AES-128)

3 across multiple factors (system resources susceptible to restriction) of an embedded system. The proposed lightweight ciphers will meet the requirements given by NIST; these requirements are discussed in section 2.C.1.

II. LITERATURE SURVEY

In this section, we will cover existing research covering the current state of IoT,

current IoT cryptography, and lightweight cryptography. These sections provide an

understanding for the emergence of lightweight cryptography. The first subsection covers

the current state of IoT security and the challenges in providing security to those IoT

devices. The second subsection covers the state IoT cryptography, challenges, and an

overview of AES. The final subsection goes into lightweight cryptography, the NIST

report and standards, and the proposed lightweight algorithms which will be compared to

AES in this report.

A. Overview of IoT

The definition of what is an IoT device, as stated before, has not been standardized.

However, there is a common notion behind most definitions of IoT. As stated in [2], the

common idea is: “… everyday objects can be equipped with identifying, sensing,

networking and processing capabilities that will allow them to communicate with one

another and with other devices and services over the Internet to achieve some useful

objective.” Prior to the introduction of IoT devices, most of the devices attached to a

network, including the Internet, were designed with this networking capability; these

devices are the typical servers, desktops, laptops, etc. which are equipped with adequate

resources to handle networking capabilities [2]. Unlike those devices, IoT devices are

made available in a network even if that capability was not part of the initial design [2].

Examples of these IoT devices are home appliances such as refrigerators or smart televisions, light bulbs, or monitoring devices such as thermostats. These devices have become more adopted due to the development of various technologies.

1) IoT Technologies

The rise of IoT has come about due to the expansion of a couple of key technologies.

The first foundational technology is RFID in which a microchip (tag) transfers identification data to a reader using wireless communication [9]. This type of technology has seen a rise in many different sectors including retail, logistics, and other areas which conduct tracking [1]. By using RFID, organizations are able to track and/or monitor items automatically without the need for manual intervention. RFID tags use radio frequencies via an antenna embedded within the tag’s microchip to transmit information [3]. This tracking information can then be communicated to monitoring/back-end systems and be used to aggregate tracking for multiple items. In these types of applications, the RFID readers are the can be considered the first IoT devices due to their network communication capabilities [9]. With these networking capabilities, the RFID microchips, RFID readers, and back-end server(s) create an IoT network which can span across an organization’s internal network or across the Internet [10]. For this reason,

RFID is considered one of those IoT foundation technology [1].

The second foundational technology are wireless sensor networks (WSNs). With this technology, as its name states, intelligent sensors are interconnected using wireless communication [9]. These type of sensor networks have been applied multiple areas including traffic monitoring, military tracking, healthcare, and much more [9], [11].

Unlike RFID, or other network technologies, WSNs do not typically have an

5 infrastructure since they consist of many sensors monitoring an environment [11]. WSNs can appear in two types: structured and unstructured. In unstructured WSNs, there is no planning in the deployment of the sensors; they are deployed randomly across the environment [11]. With a structured WSN, pre-planning occurs for the deployment of sensors which allows for better management [11]. Besides their deployment, these

sensors use their radio transmitter to transfer data with a base station; this base station can

be from a simple handheld device to a fixed access point [11]. With the sensors and a

base station, a rudimentary IoT network which can be used in a local area. However, by

using a base station with a network connection (Internet or others), these sensors can be

deployed in remote environments without the need for users to be present.

Although RFID and WSNs are the foundational technologies for IoT, as other

technologies have been developed, many have also become a part of IoT. These new

additions to IoT are composed of both hardware and software advances. One of the new

hardware technologies added to IoT is NFC which allows devices to communicate when

they are brought together [2]. NFC has seen a rise in use as a payment method via mobile

phones; in 2014 this form of payment was 2 million, and in 2015 it increased to 31

million [12]. By using an NFC-capable smartphone, users are able to pay by bringing

their phone in contact with an NFC terminal at the point of sale [12]. Similar to RFID, an

NFC terminal is connected to a central system, in this case a financial institution, which

handles the payment processing[12]. Overall, NFC payment methods have a similar setup

to an RFID IoT network with the RFID tags and RFID readers replaced with smartphones

and NFC terminals respectively.

In terms of software advances, IoT has spurred the creation of middleware to handle the different types of IoT devices [2]. The purpose of this middleware is to provide a single interface which handles the data from the different devices, and it allows developers to deploy new services without having to deal with converting data from different devices [2]. A current middleware is the Open Source Gateway Initiative

(OSGi) Java software framework. This framework is used as a gateway for IoT devices which allows for the deployment and/or download of service applications (bundles) [13].

The bundles allow the gateway to handle the different IoT devices by using a bundle specific to a device [13]. In addition to these applications, the framework provides different layers to handle bundle security, bundle modules, bundle life-cycle, and bundle services; each of these layers work together to provide developers with resources to handle multiple devices and a stable gateway [14]. By using the framework, a gateway can quickly adapt to changing IoT network, and add or remove functionality as needed.

2) IoT Architecture:

Besides the introduction of new hardware and software technologies, new architecture models have been developed to handle IoT. For IoT, models follow a service-oriented architecture (SoA) which ensures the interoperability of different IoT devices [1]. By using a SoA approach, a complex system can be treated “as a set of well-

defined simple objects or subsystems… [1].” These simple objects can then be handled

individually which implies the software and hardware implementations of those objects

can also be handled individually [1].

Similar to other architectures, there is not a consensus on the layers for the IoT

architecture. Different researches have proposed SoA architectures consisting of three,

four, or five layers [9], [15]. We will focus on the four layer architecture presented in [1],

[9], and will also make some references to the three layer architecture in [15]. The

architecture presented in [1], [9] consists of the following layers: sensing, network, service, and interface; Fig. 1 gives the hierarchy of the layers and the transmission path of

data. The rest of this section covers each layer in more details.

an smit Recei ve l ay ers D a t a D a t a

Int erface

Service

Ne t w o rking

Sen sing

Fig. 1 IoT architecture and transmission path of data The base of the architecture, and first layer, consists of the sensing layer; some

architectures also call this the perception layer. In this layer, the systems on IoT devices

can sense their environment and exchange information with other devices [1]. IoT

devices sense their environment by using their sensors to “detect, collect, and [process]

information [15].” For information exchange among devices, this can occur using short

range or local networks [15]. An example of this information exchange is RFID which, as

mentioned previously, RFID tags communicate with RFID readers by using the tag’s

8 antenna [3]. Of course, with all of these IoT devices exchanging information, the devices need a method to identify each other. A universal unique identifier (UUID) can be assigned to a device or service, and this UUID can be used to identify and retrieve information from a device [9]. Without UUIDs, managing an IoT network can become a difficult task as the network expands [1]. Table I below lists some protocols which are a part of the sensing layer.

TABLE I SENSING LAYER PROTOCOLS Protocol Standard(s) RFID ISO 11784, ISO 11785, ISO 18000 NFC ISO/IEC 18092, ISO/IEC 29143 WLAN IEEE 802.11 Bluetooth IEEE 802.15.1

The next layer is the network layer which operates similar to the network layer of other architecture models (e.g. Department of Defense model, OSI model, etc.). Within this layer, objects are connected together and have the capability to share data with other connected objects [9]. In short, this allows an IoT device to communicate with other devices across local networks, remote networks, or the Internet. Besides the IoT devices, this layer contains network devices such as routers, switches, bridges, etc. that provide network services [15]. Within the network layer, an IoT device can connect to the existing network infrastructure, and it can use the network services provided by the other devices [1]. In addition to IoT devices using a network, the network must also be able to automatically handle the introduction and removal of devices; this includes discovering and mapping objects, and also granting roles to those devices [1]. Table II below lists some common network services that are provided in a typical network infrastructure.

TABLE II EXAMPLES OF NETWORK SERVICES (ADAPTED FROM [16]) Protocol Description Dynamic Host Provides configuration information such as IP Configuration address, gateway, DNS servers, etc. to hosts. Protocol (DHCP) Internet Control Defines error messages that are sent back to a host Message when the destination is unable to process a packet. Protocol (ICMP) Domain Name Maps IP addresses to a more user-friendly host Service (DNS) name. Address Maps a devices physical address to an IP address. Translation Protocol (ARP)

The third layer consists of the service layer, and its deals with the services used by end-users or applications [1]. Unlike the previous layers, the service layer does not seem to be a requirement for IoT devices, and it appears as more of a goal for IoT; this is the reason some models only contain three layers since they skip this layer. It is at this layer in which the middleware software mentioned in the previous section exists. The middleware technology “provides a cost-effective platform, where the hardware and software platforms can be reused [9].” To accomplish this goal, specifications for services which will run on middleware must be established; currently different organizations, such as OSGi mentioned previously, create their own standards [9]. For a useful service layer, there must exist some common requirements of applications, protocols, and interfaces. Activities such as data management, information exchange and storage, and search engines and communications are a part of this layer [1]. Table III lists the components which conduct the service layer activities.

TABLE III SERVICE LAYER COMPONENTS (ADAPTED FROM [1], [9]) Component Description Service Finds objects that can provide the required service Discovery and information effectively Service Allows interactions among connected objects Composition Trustworthiness Determine trust and reputation mechanisms by Management evaluating and using information from other services

Service APIs Provides interactions between services

The final layer is the interface/application layer, and within this layer, functions are provided to users and/or other applications for interaction [1]. Since there are many types of IoT devices which may not follow the same standards or protocols, there can be issues with information exchange, communications, and event processing between devices [9].

In order for the devices to work together, they must provide an interface which allows interactions with other applications on the IoT network. This is known as an interface

profile (IFP), and it can be considered a subset of the service standards which promotes

the interaction [9]. By using these profiles, applications can connect to the underlying

services, and they can gain access to new services that meet the application’s

requirements [9].

With this type of architecture, IoT devices can easily integrate into networks of mixed devices. This approach pushes for the use of more standards to allow IoT devices, and applications, to communicate effectively without requiring specialized applications between the different devices

3) IoT Security

Pertaining to information security, there are three core security goals which any system should attempt to meet. These security goals are composed of confidentiality,

11 integrity, and availability; they are also known as the CIA triad [5]. IoT devices are no exception and should also attempt to reach these three goals.

The goal of confidentiality is to ensure that data is only accessible to authorized entities [15]. For IoT, in addition to users, authorized entities also include other IoT devices and services which may be on internal or external networks [15]. IoT device confidentiality must also address the management of data. Users must be aware of the mechanisms used for data management, who or what is responsible for management, and ensure protection of data during a process [15]. There are multiple methods to implement confidentiality which protect different areas, and by implementing all methods, overall confidentiality can be ensured. The first method to provide confidentiality is encryption

[4]. Encryption makes data unreadable to those without the key to decrypt; this is covered in more depth in section 2.B [16]. The second method is access controls which allow only authorized entities access[4]. This is accomplished by using identification, authentication, and authorization [4]. Identification is accomplished using a unique ID such as a username. Authentication is used by an entity to prove their identity; an example is a user’s password [4]. Finally, authorization grants or restricts access based on the type of authorization methods used; an example is permissions which may grant read, write, and/or execution capabilities to a resource [4].

For integrity, the goal is to ensure data has not been tampered – intentionally or unintentionally, and that the right sender has sent the data [15]. Data tampering can occur due to unauthorized users, malicious software, and system or human errors [4]. For data senders, certain attacks – such as a replay attack in which an attacker sends a copy of the data – can impersonate a sender [16]. Similar to confidentiality, there are multiple

12 methods to provide integrity. The first method deals with data integrity; this method is called hashing [4]. With hashing, data is passed through an algorithm, and a value is generated. As long as the data is not changed, performing another pass with the hashing algorithm will produce the same value; this is also known as integrity verification [4].

The second method is the use of digital signatures. Digital signatures work similar to a

person’s signature which let a receiver know that data came from the stated sender [4].

IoT devices must not only ensure that the data they send remains valid, but they must also

verify the data they receive is from valid senders.

Finally, with availability, the goal is for data, devices, and services to be available

when they are needed [15]. However, availability does not mean that the device, and its

services, must always be available; the availability is dependent on the need of the users

and/or organization [4]. The first method to ensure availability is through redundancy and

fault tolerance. By using redundancy, multiple components are used to perform similar

task or tasks [4]. If a component fails, the other components can continue without an

interruption; this is also known as fault tolerance since a fault does not break a system

[4]. For IoT, this can be implemented by using multiple devices to provide coverage for

faulty devices. The second method to provide availability is through software patching

[4]. By fixing software bugs, devices can be prevented from breaking due to faulty code.

Since IoT devices may be in remote areas, have time sensitive tasks, and much more,

ensuring these devices remain operational is important.

4) IoT Security Challenges

Although information security is a very important aspect of IoT, due to the nature of

IoT devices, this can be a difficult goal to accomplish. Each of the layers (perception,

13 network, and interface/application) in the IoT architecture contains challenges to implementing security.

Due to the nature of the perception layer, mentioned in section 2.A.2, there are a few challenges to security. The first challenge is concerned with wireless communications of

IoT devices. Many IoT devices operate using wireless signals, and these signals can be disturbed (jamming) or captured [15]. Although these challenges also exist for other non-

IoT devices such as wireless access points, these two types of security challenges pose a bigger risk to IoT devices due to their use across different types of environments

(external, outdoors, indoors, etc.) [15]. This also leads into the second security challenge for IoT devices. IoT devices may be located in areas where they are susceptible to tampering or theft [15]. Besides being damaged or destroyed, the data stored in the IoT device can also be extracted [3].

The network layer also maintains the same security challenges which non-IoT devices experience. Network traffic generated by an IoT device can be captured, analyzed, and much more [15]. However, the security challenge with IoT is the compatibility of devices. IoT devices are composed of many different network components which must work together to maintain security [15]. These network components (Bluetooth, RFID,

NFC, etc.) have their own protocols to communicate amongst each other, but in a network consisting of different IoT devices, security mechanisms must still exist between those protocols [15]. The different security mechanisms must operate together to ensure data is not compromised.

Finally, in the application/interface layer, the major security challenge is the lack of standards and global policies [15]. The different applications and interfaces in IoT will

14 have their own methods of authentication, and other IoT devices and applications that must communicate with an application must know how to perform this authentication.

With the large market of different IoT devices, this is a difficult task to anticipate all applications an IoT device or application will utilize. Besides a lack of standards, another security challenge is the access control to the data [15]. Since some applications are on the Internet, users must be able to control what data will be sent and how it will be used

[15].

B. Overview of Cryptography and IoT

As mentioned above, IoT devices should meet the CIA security goal. One of the methods used to meet confidentiality and integrity is cryptography. With cryptography, data is converted to an unreadable form, and only those entities with a specific key can read the data [17]. This is done through two processes: encryption and decryption.

Encryption is the process used to convert a readable message to the unreadable format; the readable message is known as plaintext, and the unreadable format is known as ciphertext [18]. Decryption is the process of converting the ciphertext to plaintext [18].

The algorithms (ciphers) used for encryption perform substitutions and transformations, along with a key, on the plaintext to create the ciphertext, and they perform a similar process to convert the ciphertext back to plaintext [18]. A key is the secret which will be used to decrypt ciphertext [17]. These ciphers are grouped into two types: symmetric and asymmetric, which dictate how a key, or keys, are used during the encryption and decryption process.

With symmetric encryption, only a single key is used for encryption and decryption

[17]. For asymmetric encryption, two keys are used: public and private. The public key is

15 used to encrypt a message; it is named the public key since this is given out to anyone

[16]. The private key is maintained by the owner of the keys, and it is the only key able to

decrypt [16]. Compared to symmetric ciphers, asymmetric ciphers are considered much

slower which can be an issue when processing large amounts of data [19]. Due to this

performance difference, asymmetric ciphers are mostly used for authentication and

session keys; the symmetric ciphers are then used to perform encryption and decryption

[16].

For IoT devices, these ciphers can be used in each of the layers depending on the

technologies and protocols implemented by a device at each layer. In the perception

layer, since it deals with the device itself and its sensors, both of these should be

protected. For the data on the device, encryption can be implemented on the data at rest

[4]. This ensures the data is protected from unauthorized access, and it also protects the

data from tampering; the encryption provides both confidentiality and integrity for the

data at rest. Disk and file encryption is a functionality provided by most existing

operating systems; however, this does cause a performance impact [4]. For example, the

Linux kernel provides disk and system encryption via a tool called dm-crypt [20]. For the device sensors, this is dependent on the technology being used, and its support for cryptography. However, communications between IoT devices should still be encrypted to provide data protection during those transmissions [21]. As an example, the IEEE

802.11 standard (Wi-Fi) can provide data transmission encryption using the Advanced

Encryption Standard symmetric cipher [22]. This cipher is covered in more detail in the next section.

In the network layer, the goal is to protect the communication channels between an

IoT device and a system on a local or remote network. By protecting the data at this layer, the upper layers are not required to implement their own encryption; however, depending on how the communication channel is encrypted (by-hop or end-to-end), data may be read by network devices [21], [23]. For many IoT devices that use the standard

Internet Protocol (IP) version 4 or version 6, the IP Security (IPSec) protocol suite can also be used. IPSec provides confidentiality via encryption through the Encapsulating

Security Payload (ESP) protocol [16], [23]. Similar to the protocols mentioned in the physical layer, IPSec uses the AES cipher; although, IPSec does provide other ciphers which are less commonly used [24].

Finally, in the application and service layers, the goal is to protect the data between an IoT application and another application or service and vice versa. This allows an application or service to provide full end-to-end encryption regardless of the cryptographic services provided by the lower layers [21]. The application can implement its own cryptographic security or by the use of third-party protocols or libraries. An example of an existing third-party protocol is the Transport Layer Protocol (TLS) [16].

This protocol is what provides the encryption security for Secure Hyper Text Transport

Protocol (HTTPS), and it can be used by other applications or services [16]. TLS uses two protocol, record and handshake protocols, to provide security. The handshake protocol is used by the source and destination to select the cryptography parameters such as symmetric cipher algorithm and session keys [25]. Once the handshake is complete, the record protocol is used to encrypt the data and transmit, and at the destination, it

receives the data and decrypts [25]. Similar to IPSec and WPA2, TLS also uses AES as

the standard symmetric cipher [25].

1) Advanced Encryption Standard (AES)

As mentioned above, the AES cipher is used in many protocols to provide confidentiality. It was accepted as the standard symmetric algorithm by NIST in 2001 to replace the Data Encryption Standard (DES) [18]. NIST provides the details of the AES algorithm in [26]. The AES algorithm is a symmetric block cipher; a block cipher operates on set size of data called data blocks [17], [26]. For AES, the block size consists of 128 bits, and it can use keys of 128, 192, or 256 bits which are known as AES-128,

AES-192, and AES-256 [26]. A larger key improves the strength of AES since the most efficient attack on AES is key recovery. Table IV displays the number of applications of

AES must be performed on a plaintext or ciphertext to find a key. Fig. 2 gives the

algorithm for AES which covers encryption and decryption.

TABLE IV AES STRENGTH (ADAPTED FROM [27]) AES Strength (applications of AES) Key Rounds AES-128 2 10 AES-192 2127 12 AES-256 2191 14 255

n cryption Decr yption

,._.fCl).t l*l

Fig. 2 Encryption and Decryption process of AES (adapted from [18], [26], [27]) As shown in Fig. 2, AES encryption and decryption perform four functions within a

round; except for the final round, which performs only three of the functions. The number

of rounds is determined by the key size which is shown in Table IV. As is shown in the

image, decryption is an inverse of the encryption process with the inverse of the functions

used during encryption. The input consists of the key, the starting round (i = 1 for

encryption or i = last round for decryption), and the 128-bit text (plain or cipher

depending on encryption or decryption) in a 4x4 byte array; the array is also known as the

state, and all of the functions are performed on this array [18]. Prior to starting, the key

and text undergo the AddRoundKey, and the key is also expanded which creates a 128-bit key for each round. The four functions performed during the rounds are SubBytes,

ShiftRows, MixColumns, and AddRoundKey; except for AddRoundKey, the other functions have an inverse function used during decryption.

The following explanations of the functions performed in AES follow the encryption process. Decryption follows a different order for the inverse functions, but they perform the reverse task as their encryption counterparts; this order can be seen in Fig. 2. The

SubBytes function performs a substitution on each byte of the state using the Rijndael substitution box (Sbox); in Fig. 7 and Fig. 14 (inverse) of [26] are the Sboxes used during this function [18]. Next is the ShiftRows function which performs a cyclical shift to the last three rows [18]. The second row is shifted once, the third row is shifted twice, and the fourth row is shifted three times [26]. The MixColumns function performs matrix multiplication (using exclusive OR (XOR)) between a fixed matrix and each column of the state; this function is not performed on the final round [18], [26]. Similar to the Sbox, the fixed matrix is given in equations 5.5 and 5.6 of [26]. The last function,

AddRoundKey, performs an XOR between the state and the current round’s key. Once all of the rounds are complete, the final result is contained within the state.

2) AES Instruction Set

With the widespread use of AES in both the public and private sectors, performance and security improvements are important for the cipher. Performance improvements are needed in order to have minimal impact on the user experience when performing large amounts of encryption and decryption operations [28]. An example mentioned above is the use of full disk encryption which requires constant encryption and decryption operations. In terms of security, although the AES algorithm is a strong cipher, the actual implementations of the AES algorithm can have security flaws. Many implementations of

AES use a lookup table to store the secret round keys [28]. These lookup tables are stored in memory, and may be read by another malicious process; this is known as a side channel attack [28].

In 2008, in order to increase performance and security Intel created the AES New

Instruction (AES-NI) set for their x86 processor architecture [28], [29]. This new instruction set introduces six new instructions to handle not only AES, but also the overall Rjindael algorithm which allows larger block sizes [28]. These new instructions are listed in Table V. In order to increase performance, these instructions use the 128-bit data path provided by Intel’s architecture, and they are optimized for the initial generation of the round keys and storage in registers or cache [28]. This allows the instructions to quickly retrieve the round keys, and there is no need to reach out to the main memory [28]. In terms of security, as long as the instructions are properly used, all operations occur within the processor, so no lookup table is used; this removes the side channel vector introduced by using a lookup table [28]. Finally, although Intel introduced this for its architecture, other processor manufactures, such as AMD and ARM, have also introduced these instructions into their architectures [30], [31].

TABLE V AES-NI SET INSTRUCTIONS (ADAPTED FROM [29]) Instruction Description AESENC xmm1, xmm2 /m128 Performs a round of the AES encryption. The first parameter is the state, and the second is the round key.

AESENCLAST xmm1, xmm2 Performs the final round of AES encryption. Parameters /m128 are the same as above.

AESDEC xmm1, xmm2 /m128 Performs a round of the AES decryption. Parameters are the same as above. AESDECLAST xmm1, xmm2 Performs the final round of AES decryption. Parameters /m128 are the same as above.

AESKEYGENASSIST xmm1, Generates a round key from a given key. The first xmm2 /m128, imm8 parameter will hold the result, the second contains the key being used to generate the next key, and the third holds the RCON value given in the AES algorithm.

AESIMC xmm1, xmm2 /m128 Converts a round key to a usable format for decryption. This step performs the InvMixColumns function. The first parameter holds the result, and the second hold the round key being converted.

C. Overview of Lightweight Cryptography

AES and many of the other currently existing ciphers are considered part of the conventional cryptography [8]. As mentioned previously, these ciphers are meant to be used in general systems such as desktops, servers, and even smartphones. These devices contain the adequate resources to perform encryption without too much impact to performance. However, for resource-constrained devices, these conventional ciphers may

not be able to be implemented or their performance may not be acceptable [8]. With

lightweight cryptography, the goal is to find ciphers which are able to operate in these

constrained devices. These lightweight ciphers attempt to reduce the “weight” in software

and in hardware [7].

The software weight of a cipher is determined by its time complexity and the memory complexity [7]. The time complexity is how long it takes for the cipher to complete, and the memory complexity is how much memory is needed by the cipher to complete its task

[7]. For the hardware weight, this is determined by the cipher’s time complexity and power consumption [7]. The time complexity is similar to the software complexity, and the power consumption weight is determined by the power used by the cipher during execution [7]. Although the power consumption is a hardware weight, it also applies to the software weight since many lightweight devices may have limited power [7].

1) NIST Lightweight Cryptography Standardization

In 2017, NIST released a report on their current ongoing lightweight cryptography project and their findings of the current state of lightweight cryptography [8]. For the current state of lightweight cryptography, the ISO/IEC 29129 standard contains lightweight ciphers for different applications; one of these applications deals with block ciphers [8]. The standard currently contains two ciphers called PRESENT and CLEFIA which have performed faster when compared to AES [32]. In addition to the ISO/IEC standard, the Japanese government’s Cryptography Research and Evaluation Committee

(CRYPTREC), published their own report of acceptable ciphers for lightweight implementation which included AES, PRESENT, CLEFIA, Camellia, LED, Piccolo,

TWINE, and Prince [8], [33].

For NIST, the purpose of their lightweight cryptography project is to find suitable ciphers which can be used depending on their targeted profile(s). Unlike AES, which is a general cipher, NIST has established profiles for which have specific cipher goals and metric ranges, and classes of devices and applications will fall into these profiles [8]. For

23 the NIST project, two profiles were created. Profile I is Authenticated Encryption with

Associated Data (AEAD) and hashing for constrained software and hardware environments, and Profile II is AEAD for constrained hardware environments; Profile II is considered a subset of Profile I, so ciphers that cover profile I will cover Profile II [34].

The main difference between Profile I and II is that Profile II ciphers require hardware implementation due to high constraint requirements, and these constraints may not be met by software implementation alone [34].

As of June 2018, NIST only has a draft of their requirements for lightweight cipher submissions; this draft is [35]. This draft is currently undergoing a public comments period prior to setting formal submission requirements. Currently, in this draft, submissions can be a family of AEAD algorithms in which these member algorithms use different parameters, and the submission is limited to ten members [35]. An example is

AES and the different key sizes that can be chosen; AES-128 is a member algorithm of

AES. In terms of key lengths, submissions cannot use keys smaller than 128-bits, and if larger keys are used, NIST recommends at least one member algorithm which uses keys of 256-bits [35]. For security, algorithms using the minimum 128-bit key length should take at least 2 computations, and for the 256-bit key algorithms, it should take at least 112 2 computations [35]. 224 In the following sections, we will cover the lightweight ciphers which will be tested. These ciphers meet the draft requirements set by NIST for lightweight ciphers.

2) PRESENT

The PRESENT cipher was introduced in 2007 with the goal of operating on constrained environments [36]. When implemented on a device, PRESENT can include

24 both encryption and decryption, or it can be encryption-only with decryption being handled somewhere else [36]. It consists of two algorithms which can use 80 (PRESENT-

80) or 128-bit (PRESENT-128) keys [36]. For its data block size, PRESENT uses 64-bits

[36]. Although PRESENT has been compared to AES in [32], only PRESENT-80 was used which does not meet the minimum key requirement from NIST. In terms of security,

PRESENT-80 takes 2 computations, and, although no formal linear cryptanalysis has 84 been performed on PRESENT-128, it can be assumed that PRESENT-128 will be of a

higher order [36].

The PRESENT cipher, similar to AES, uses both substitutions and permutations

(shift) which is also known as an SP-Network (SPN) [36]. Fig. 3 shows the encryption

and decryption process used by PRESENT; the only difference is the order and use of

inverse functions for decryption. The initial input, as well as the input for each round, is

the 64-bit STATE and a 64-bit round key. The first step is the addRoundKey which

performs an XOR between the STATE and the round key [36], [37]. The new state is

then input into the sBoxLayer. In this function, the STATE is broken into groups of 4

bits, and, using sixteen (16) Sboxes, the groups are processed in parallel [36], [37]. The

Sbox used in this function, and its inverse, are defined in [36] (encryption) and [37]

(encryption and decryption); these references also list some of the security features implemented in the Sbox to improve security. The last function in a round is the pLayer function which shifts the STATE bits using equation 1 [36], [37]. This process is performed for 31 rounds with round 32 consisting of a single addRoundKey. After this final round, the STATE now holds the ciphertext. The decryption process is just the

25 reverse of the encryption process.

ncryption Decryption

Pbin To.t i : 1 j :)1

'"""'""''""- "'" A.dd Roun~ -·- Kqoi --"""' ... _ .....,.. lrnS&olll~ ·- Adcl Roun cW.ty ..... ; .,~

~ - ~ l(qo J2 --"""' e CiphC'l'Tt:1.t

Fig. 3 PRESENT encryption and decryption processes 16 63, {0, … , 62} ( ) = ( 1 ) 63, = 63 𝑖𝑖 ∗ 𝑚𝑚𝑚𝑚𝑚𝑚 𝑖𝑖 ∈ 𝑃𝑃 𝑖𝑖 � 3) Modified Symmetric Encryption Algorithm𝑖𝑖 (MSEA)

The MSEA cipher was introduced in 2014, and it is focused on using combinations of simple operations to perform encryption and decryption [38]. In addition, unlike AES and

PRESENT, MSEA allows for a variable data block size and variable number of rounds, and the key size is double the chosen block size [38]. Although each of those is variable, they do have a minimum and maximum value which are covered in Table VI. In terms of security, the variability of these rounds and block size, in addition to the addition and random rotations, help provide greater security. By changing a single plaintext bit, more than 50% of the ciphertext bits are affected by this change after nine rounds [38].

TABLE VI MSEA PARAMETER VALUES (ADAPTED FROM [38]) Parameter Min. Max. Block Size 128 2048

Rounds 1 63

Key Size 256 4096 Previously we mentioned AES and PRESENT use an SPN approach for their

algorithm design, however, this is not the only design approach available to cryptography

algorithms. The MSEA algorithm uses the modular addition, rotation, and XOR (ARX)

design approach [38]. These are the simple operations which can be used without the introduction of larger overhead due to substitutions or permutations.

The MSEA algorithm operates in two stages with the first stage being the creation of the round keys, and the second stage being the actual encryption or decryption operation.

However, prior to starting, there are a few parameters that must be chosen: the number of rounds (r), the data block size (s), the swap key (k), and the master key ( ); this is

𝑀𝑀 known as the cumulative key since it is shared between the sender and receiver𝐾𝐾 [38].

With the number of rounds, this value can be between 1 and 63 inclusively [38]. The data

block size value is an integer representing the number of bits for the data block. This

value can be between 128 and 2048, but it must also be a multiple of 8 [38]. The swap

key is used during the round key generation stage, and the number of bits used for this

key is based off of the data block size; the number of swap key bits is determined by

calculating log [38]. For a data block size value of 128, the swap key is 7 bits. The

2 final parameter is𝑠𝑠 master key which is the same as AES and PRESENT, however, it has

the constraint that it must bet twice the number of bits of the data block size (2s) [38]. For

a 128-bit data block, the master key will use 256-bits.

of Round$ Mast er Key

4-btt sw ap

Round Key/ Generated

Round Ke;s Generated

Fig. 4 MSEA Round Key Generation With the parameters above determined, the first stage is to generate the round keys;

Fig. 4 shows the process used to generate the round keys. This step will use the number

of rounds and the master key parameters. Each round of the round key generation outputs a round key with the same key size as the master key [38]. In this process, the first

function performed on the master key, or the previous round’s key, is a 4-bit swap. In this

function, a block of 4-bits is swapped with the next block of 4-bits[38]. After the swap,

one of the blocks undergoes a left bit-wise rotation, and the other block undergoes a right

bit-wise rotation followed by a one’s complement [38]. Once all 4-bit blocks are

processed, the result undergoes a data dependent rotation. This rotation takes the log

2 least significant bits to determine the rotation; the first bit determines whether it is a left𝑠𝑠

or right rotation, and the remaining bits give the number of bits to rotate [38]. Using this 28 information, the result is rotated left or right for the number of determined bits, and this result is the round key.

With the round keys created, encryption or decryption is performed. In the case of decryption, unlike AES or PRESENT which use inverse functions, MSEA is just the reverse of the encryption process [38]. Fig. 5 shows the encryption process which consists of the three stages: message expansion, encryption rounds, and 2-phase swap. In the message expansion, the plaintext message is broken into 8-bit blocks, and these blocks are expanded into 16-bits; this results in a message with the same number of bits as the key size [38]. In order to perform this expansion, the 4 least significant bits are appended in front of the most significant bit, and the 4 most significant bits are appended before the least significant bit [38]. The resulting 16-bit block then undergoes two data dependent rotations similar to the rotation in key generation. In the first rotation, the last

4 bits are used to determine how the rotation will occur. Just as before, the most significant bit is the direction, and the remaining bits are the number of bits to rotate; the rotation is then performed on the remaining 12 bits [38]. The next rotation uses the first 4 bits, and it follows the same process as the first rotation. Finally, a one’s complement is performed on the 16-bit block [38]. This process is performed for the other 8-bit blocks which results in the expanded message. The message expansion function is shown in Fig.

Plal.,,.xt # of Rounds I : I

Round Process

Fig. 5 Overall MSEA encryption process

Plalntext

(8 4 blt Block)

Copy 8 Block A Copy A

Data Dependent Rotation

DOR Data Dependent Rotation Options

Extended M essage Block (1 6-blts)

Fig. 6 Message expansion. Converts 8-bit blocks to 16-bit blocks which doubles the size of the overall message

~ .:: o I 11 :;s" " 30

<] ~~ . . .,. •0 8 ' • s!1- ' i! i~ i~ :- i :- ., ,., 11 ;!. "Mi ,.,, i 3"<~- < S ;!. "

Fig. 7 Process performed each round in order to encrypt

Once the message has been expanded, the message is sent through the encryption process shown in Fig. 7. First, the input message is broken into 4 equal blocks which can be called blocks A, B, C, and D. Once these blocks are created, they will be sent through modular addition; D is the result of D and C, C is the result of B and C, B is the result of

A and B, and A is the result of A and the new D [38]. After the modular addition, the next step is a data dependent rotation using the last log where m is the size of a

2 block[38]. Once the blocks have been rotated, the round 𝑚𝑚key is broken into 4 subkeys called , , , and . These subkeys are used to perform XOR ( ) with the

𝑖𝑖𝑖𝑖 𝑖𝑖𝑖𝑖 𝑖𝑖𝑖𝑖 𝑖𝑖𝑖𝑖 blocks;𝐾𝐾 A is𝐾𝐾 the 𝐾𝐾result of 𝐾𝐾 , B is the result of , C ⊕is the result of

𝑖𝑖𝑖𝑖 𝑖𝑖𝑖𝑖 𝑖𝑖𝑖𝑖 , and D is𝐴𝐴 the⊕ result𝐾𝐾 of 𝐵𝐵 ⊕ [38]𝐾𝐾 . Next,⊕ 𝐾𝐾 blocks C and A, and

𝑖𝑖𝑖𝑖 𝑖𝑖𝑖𝑖 𝑖𝑖𝑖𝑖 𝑖𝑖𝑖𝑖 𝐶𝐶blocks⊕ 𝐾𝐾 D and⊕ 𝐾𝐾 B are concatenated in the𝐷𝐷 given⊕ 𝐾𝐾 order⊕ 𝐾𝐾to create two new blocks called E and

F [38]. Block F undergoes an XOR with E, and this result is stored in F; block E

31 undergoes modular addition with the new result in F, and this result is stored in E [38].

Finally, F and E are concatenated in the given order which is back in its original expanded size. This process is repeated for the number of rounds given in parameter r.

Once the encryption rounds have been performed, the output from the last round undergoes a 2-phase swap using the swap key k. This stage contains two steps. In the first step, every kth bit is swapped from 0 to 1 or 1 to 0 [38]. The second step is similar to the

4-bit swap performed during key generation; however, instead of 4-bits, the swap occurs on k-bits [38]. The output of the 2-phase swap is the encrypted message which is the same size as the key size.

4) LEA

The final cipher, which was also introduced in 2014, is the LEA cipher. Its name stems from the use of constants based on the square root of 766995 where 76, 69, and 95 are the ASCII codes for ‘L’, ‘E’, and ‘A’ [39]. LEA, just like MSEA, uses an ARX design for its algorithm [39]. In terms of data block size and key size, LEA uses a similar approach as AES with a block size of 128 bits, and key sizes of 128, 192, and 256-bits; these follow the same naming convention as AES with LEA-128, LEA-192, and LEA-

256 [39]. For security, the authors of LEA provide a security analysis against many different types of attacks. For the linear attack, at 11 rounds of the cipher, it would require 2 plaintexts to get information about the round keys; the authors claim that 126 LEA-128 is secure up to 14 rounds, so it can be assumed that the number of plaintext also increases [39].

The LEA algorithm operates in two stages with the first stage being round key generation, and the second stage being the encryption/decryption process. LEA is

designed to operate on an array of 32 bit blocks for the plaintext, ciphertext, and the keys

(round and master) [39]. As input, the algorithm takes the plaintext/ciphertext and the

master key. As mentioned previously, in order to generate keys, the LEA uses the

constants listed in Table VII which are hexadecimal representation of the square root of

766995 [39].

TABLE VII LEA CONSTANTS (ADAPTED FROM [39]) Constant Value (hex) δ[0] 0xc3efe9db δ[1] 0x44626b02 δ[2] 0x79e27c8a δ[3] 0x78df30ec δ[4] 0x715ea49e δ[5] 0xc785da0a δ[6] 0xe04ef22a δ[7] 0xe5c40957

For key generation, depending on which key size is chosen, dictates how the round

keys are generated. LEA-128 and LEA-192 follow a similar approach to round key

generation while LEA-256 uses a slightly different approach; we’ll cover the process

used for LEA-128, but the approach used for LEA-256 can be found in [39]. To begin,

since the master key is broken into block of 32 bits, these blocks are assigned as [ ] =

[ ] where [ ] is the xth block of the master key [39]. For the first T block, the𝑇𝑇 𝑥𝑥 constant𝐾𝐾 𝑥𝑥 for 𝐾𝐾the𝑥𝑥 round is retrieved using 4 where i is the current round starting from 0; this constant is then rotated left by𝑖𝑖 𝑚𝑚𝑚𝑚𝑚𝑚 i bits [39]. The result of this rotations undergoes modular addition with [0], and then the result is rotated left by 1 bit [39].

The other blocks follow a similar 𝑇𝑇approach, however, for the rotation of the constant, i + block index is used to determine the number of bits to rotate, and for the modular addition result rotation: block 1 rotates 3 bits, block 2 rotates 6 bits, and block 3 rotates

11 bits [39]. Finally, the round key for the ith round is the group of

( [0], [1], [2], [1], [3], [1]) in the given order; the input for the next round will be the𝑇𝑇 results𝑇𝑇 stored𝑇𝑇 in𝑇𝑇 T. This𝑇𝑇 pr𝑇𝑇ocess is performed 24 times for LEA-128, 28 times for

LEA-192, and 32 times for LEA-256 [39].

Round Input)( (128-blts)

RK(lJ RK( 2J RK(4J (32•blts) (32-blts) (32•blts)

RK(OJ RK(3l RK(SJ (32-blts) (32-blts) (32-blts)

~------'\ADO

Shift Left 19 bits)

+J(OJ X/+1(1) X/+1(2) X/+1(3)

Fig. 8 LEA encryption rounds. Number of rounds performed dependent on selected key size With the round keys generated, the next step is to perform encryption or decryption.

The encryption process, shown in Fig. 8, is covered here, however, the decryption

process is just a reverse of encryption. Prior to the first round, the plaintext blocks are

assigned to as [ ] = [ ] [39]. Before we begin, the output for a round is stored in

0 0 and 𝑋𝑋 is the𝑋𝑋 round𝑥𝑥 key𝑃𝑃 𝑥𝑥 where i is the current round. In order to calculate [0],

𝑖𝑖+1 𝑖𝑖 𝑖𝑖+1 𝑋𝑋 [0] is XOR𝑅𝑅𝐾𝐾 with [0], and [1] is XOR with [1]. Both of those XOR results𝑋𝑋

𝑖𝑖 𝑖𝑖 𝑖𝑖 𝑖𝑖 then𝑋𝑋 undergo modular𝑅𝑅𝐾𝐾 addition, 𝑋𝑋and the result of this𝑅𝑅𝐾𝐾 addition is rotated left 9 bits; this is

the result for [0] [39]. For [1], [1] is XOR with [2], and [2] is XOR

𝑖𝑖+1 𝑖𝑖+1 𝑖𝑖 𝑖𝑖 𝑖𝑖 with [3], and𝑋𝑋 these results undergo𝑋𝑋 modular𝑋𝑋 addition with𝑅𝑅𝐾𝐾 the addition𝑋𝑋 result being

𝑖𝑖 𝑅𝑅𝐾𝐾 34

rotated right 5 bits [39]. [2] is similar to [1], but instead uses [2], [3],

𝑖𝑖+1 𝑖𝑖+1 𝑖𝑖 𝑖𝑖 [4], and [5], and 𝑋𝑋rotates right 3 bits [39]𝑋𝑋 . Finally, [3] is just𝑋𝑋 assigned𝑋𝑋 [0].

𝑖𝑖 𝑖𝑖 𝑖𝑖+1 𝑖𝑖 𝑅𝑅𝐾𝐾This process𝑅𝑅𝐾𝐾 is repeated for the number of rounds determined𝑋𝑋 previously, and the 𝑋𝑋final

ciphertext is stored in where r is the final round output (i.e. for LEA-128) [39].

𝑟𝑟 24 𝑋𝑋 III. RESEARCH GOALS 𝑋𝑋

The goal of this research is to compare lightweight ciphers to AES, and to identify if

these lightweight ciphers can provide better performance in a resource-constrained

environment such as an IoT device. The lightweight ciphers will consist of PRESENT,

MSEA, and LEA. Each of these ciphers either contains a version or meets the NIST lightweight cipher requirements. These ciphers will be compared across three resources.

The three resources are covered below:

• Execution Time – The execution time is the time a cipher takes for

encrypting or decrypting. For this research, execution time will cover

encryption execution time and decryption execution time. Each of these will

be measured across the time to encrypt or decrypt a file of a certain size.

• Memory Use – This is the memory used during the encrypting or decrypting

process of a cipher. Similar to execution time, memory use will cover the use

during encryption and use during decryption.

• Charge Usage – This is the battery usage used during encryption or

decryption process of a cipher. This can be represented using the standard

kilowatt-hour (kWh) or milliamp-hour (mAh) which is typically used for

batteries.

By using these resources, we will identify the strengths and weaknesses of each of the

cipher, and where each of those lightweight ciphers may have an application if one or

more resource is limited. In addition, by comparing to AES, we will identify any

improvements or drawbacks of using these lightweight ciphers over AES.

IV. METHODOLOGY

In this section we will cover the different components used for the testing of the

different ciphers. This will cover the implementation of the ciphers, the testing

environment, and the testing processes for the different testing resources.

A. Cipher Implementation

Most of the ciphers that will be tested are theoretical and/or prototypes which require

their implementation in order for them to be evaluated. The algorithms for these ciphers

will be implemented using C++ and compiled using the GNU Compiler Collection

(GCC).

1) AES

Since AES has been a standard for nearly 20 years, and it has been implemented in different variations, a version implemented in a library will be used. The library which will be used is Crypto++ which is a C++ cryptography library. Crypto++ contains both a software-only implementation and a hardware-enhanced implementation using AES-NI

(or architecture equivalent if supported). The AES version being tested is AES-128. For this version, AES will be tested on both the software and hardware-enhanced implementations.

2) PRESENT

For PRESENT, the PRESENT-128 version will be implemented since it is the only version which meets the NIST requirements. This will also include implementing the inverse functions used for decryption since they are not an exact reversal of the encryption process. The functions and SBox will follow the specifications given in [36],

[37].

3) MSEA

Since MSEA is meant to use simple operations, the bitwise operations provided by

C++ assist with ensuring these operations remain simple. Due to MSEA allowing for different values in rounds and data block size, these will be locked to certain values in order to maintain a consistent testing environment. For testing, in terms of implementation, two types of implementations will be tested. In the first, the MSEA specifications will be followed which allows for the MSEA parameters to be dynamically set, and in the second, the data block will be constrained. For both, the data block size will be set to the minimum value of 128 bits since it requires 256-bit keys. Since decryption is the reverse of the encryption process, the implementations will also be the reverse of the implemented encryption. Finally, for the number of rounds, the authors choose 18 for more security, so this number will also be used for testing [38].

4) LEA

Similar to MSEA, the LEA implementation will also use the bitwise operators provided by C++. Since LEA can use 128, 192, or 256-bit keys, only the LEA-128 version will be tested. All other options will be implemented using the LEA specification

37 in [39]. For the decryption implementation, it will also be a reverse of the encryption process.

5) Block Cipher Mode

Since testing will require using files larger than 128 bits, the ciphers will have to be able to handle the encryption and decryption of multiple blocks. These ciphers will be implemented using the Electronic Code Book (ECB) block cipher mode since it is the fastest mode and introduces very little overhead compared to other modes; however, this mode is considered the weakest in terms of security [17]. For AES, the Crypto++ library provides ECB as one of the available block cipher modes. This will not require any additional implementation since it is provided by the library. For the other ciphers, since

ECB treats each block independently, no extra handling outside of breaking a file into the necessary data blocks used by the cipher is required.

B. Testing Environment

For testing, the ciphers will be executed on a Raspberry Pi 3. This version of the

Raspberry Pi contains a quad core processor operating at 1.2 GHz and 1 GB of RAM

[40]. The processor is a 64-bit Broadcom BCM2837 which uses the ARMv8 instruction set. This instruction set allows for the use of AES hardware instructions with similar functionality to the Intel AES-NI set [40]. Although the processor is set to 1.2 GHz, the processor speed can be modified to lower speeds. This will allow for testing of execution times across multiple speeds. In terms of the device’s operating system, the device uses the Arch Linux 64-bit operating system [41]. Unlike other Linux distributions, Arch

Linux is a lightweight variant with only minimal applications to operate. This will allow

38 the use of monitoring tools only available for Linux; an example is the tool which will monitor memory use.

In addition to the Raspberry Pi, an energy monitor will also be a part of the testing environment. This monitor is a TP-Link HS110 which is a smart plug with an integrated energy monitor. The plug provides an API in order to facilitate monitoring. The

Raspberry Pi will be plugged into the smart plug, and energy consumption will be monitored at the plug. By monitoring at the plug, the overall power used by Raspberry Pi during encryption and decryption can be tracked.

C. Cipher Testing

As mentioned previously, the ciphers will be compared on execution time across different speeds, memory use, and charge usage. In addition, each of those resources will be compared across different file sizes. These file sizes will be: ~10 KB, 512 KB, ~1 MB, and ~2 MB.

For the first resource, execution time, the Raspberry Pi will be set to operate at 4 processor speeds: 900 MHz, 1 GHz, 1.1 GHz, and 1.2 GHz. At each speed, encryption and decryption for each cipher will be performed. Each of those cipher functions will be performed over the different file sizes.

For the cipher memory use, this will be performed using the monitoring tool Massif

[42]. This tool by default measures the heap memory used by a process. However, the tool can also be used to measure all memory used by a process including code. By using

Massif, the memory that is used during encryption or decryption will be monitored. Due to the nature of the tool, which performs slower executions of a program’s code, this test will be performed separately from the other resources.

Finally, for charge consumption, this will be performed by using the energy monitor mentioned previously. This test will measure the current during the encryption and decryption process of a cipher which is the execution time. Due to this relationship, the

execution time and charge consumption tests will be executed at the same time. The

different file sizes will also be used since those files are tested in the execution time test.

V. EVALUATION OF RESULTS

In this section, we will cover how the three resources will be evaluated. This will

ensure that the resources are evaluated consistently during testing, and that the results can be compared between the ciphers.

First, the execution time results will be represented in seconds. To evaluate the execution time of a cipher, each cipher (including multiple version) will undergo 25

rounds of encryption and decryption. The average of these results will be taken as the

encryption execution time and decryption execution time. In order to ensure there is

variance in the ciphers, different keys will be used; for MSEA, this also includes a

different swap key. This testing procedure will be performed for each of the previously

mentioned file sizes.

Next, the amount of memory used by a cipher will be represented in bytes. The output

of Massif is a graph of snapshots with snapshot memory usage over total bytes used, and

detailed information about the snapshot which includes which code statements caused a

change in memory usage. Massif executes each individual machine instruction, and

monitors its usage of memory. If memory usage changes more than 1%, a snapshot is

taken. Massif will be executed on the encryption and decryption operations across all file

sizes.

Finally, the charge usage will be represented in milliamp-hours. As mentioned

previously, this evaluation will be performed at the same time as the execution time

testing milliamp-hours are dependent on the execution time. The charge usage test will

follow the same procedure as the execution time test with each round result being the

average current used during encryption and current used during decryption. The

milliamp-hours will be calculated from the average current using equation 2. In the

equation, variable I is the current in amperes, and variable T is the time in hours. The 3.6

is due to the conversion of amps to milliamps (1000), and the conversion of seconds to

hours (3600) which reduces to 3.6. As the other tests, this test procedure will also be

performed across the different file sizes.

= --- ( 2 ) 3.6 𝐼𝐼 ∗ 𝑇𝑇 𝑄𝑄𝑚𝑚𝑚𝑚ℎ

VI. RESULTS AND FINDINGS

In the following sections, the findings of the cipher tests will be covered. The first

section will cover the results of each individual cipher across their testing parameters. For

the second section, the results of each of the ciphers will be compared. Finally, before

covering the individual results, it should be noted that initially, the file sizes being tested

were much larger than values mentioned in section 4.C. The reason for this change is due

to limitations in the MSEA cipher which will be covered later in this section.

A. Individual Cipher Findings

1) AES

As mentioned previously, this version of AES is the software implementation of that cipher with no hardware support. First, Fig. 9 - 13 at the end of this subsection cover the

41 results of the individual testing rounds for AES encryption across the different processor speeds and file sizes. As it can be seen in the figures, the encryption times vary greatly from round to round for most of the file sizes; only the 10KB file encryption maintained consistent times. There were some slight increases in some of the rounds, but overall there was very little variance. However, for the other files, the encryption times followed a high/low pattern which is more prominent with the 2MB file. When comparing the encryption results across the different processor speeds, there is almost no performance increase at higher processor speeds. With the high variance in encryption time, in some rounds, the lower processor speeds perform faster than the higher speeds, but the reverse is also true.

Second, Fig. 14 – 18 cover the individual testing round results for AES decryption across the different processor speeds and file sizes. Similar to encryption, AES decryption also has great variance between rounds, and also minimal difference between the different processor speeds. Also, just like encryption, the 10KB file showed the least variance between the decryption rounds. Overall, AES decryption and encryption have similar performance, and seem to be affected by the same issues which impact their performance. Although it is not certain what is causing the variance, it could stem from other processes being executed by the operating system.

Next, the charge used to encrypt and decrypt the different files are covered in Fig. 19 and Fig. 20 respectively. These figures show the milliamp-hours used for each file across the different processor speeds. The data points are based on the average current of all of the rounds of encryption or decryption of a file. As it is to be expected, the bigger the file, the more charge is used due to the time. This can be seen with the reduction in charge

42 usage with the higher processor speeds. Overall, the amount of charge is very minimal, even for the larger files; for the 2MB file, AES uses just over a tenth of a milliamp-hour.

However, since these results are using the average, the variance present in encryption and decryption times also affects these results. This is the reason in both figures the operations on the 1MB file are using less charge than the 512KB file.

Finally, Table VIII represents the memory used by encryption and decryption for all of the file sizes. The peak memory usage is the most memory used by a cipher during an operation. Regardless of size, AES has a peak memory usage of approximately 100KB.

The second column for each operation is the total memory usage which is the total memory used to perform the encryption or decryption. AES maintains a consistent total memory usage of approximately 214KB for all file sizes.

AES Encryption - 900 MHz

1.4

1.2

1 ~ Cl) 0.8 E i= 0.6

0.4

0.2

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Round

~ l0KB ~ 512KB ~ lMB ....2MB

Fig. 9 AES Encryption time at 900 MHz

AES Encryption - 1.0 GHz

2.5

~ 1.5

Q) E i= 1

0.5

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Round

~ l0KB ~ 512KB ~ lMB ~ 2MB

Fig. 10 AES Encryption time at 1.0 GHz

AES Encryption - 1.1 GHz

3.5

2.5

~ 2 Q) E i= 1.5 1

0.5

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Round

~ lOKB ~ 512KB ~ lMB 2MB

Fig. 11 AES Encryption time at 1.1 GHz

AES Encryption - 1.2 GHz

2 1.8 1.6 1.4 3 1.2 E 1 i= 0.8 0.6 0.4 0.2 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Round

~ l0KB ~ 512KB ~ lMB ~ 2MB

Fig. 12 AES Encryption time at 1.2 GHz

Overall Average Encryption Time - AES

1.2

0.8 3 E o.6 i= 0.4

0.2

0 10KB 512KB 1MB 2MB File Size

~ 900 MHz ~ 1.0 GHz ~ 1.1 GHz ~ 1.2 GHz

Fig. 13 Average AES encryption time across all files and processor speeds

AES Decryption - 900 MHz

1.8 1.6 1.4 1.2 ~ 1 Q) E 0.8 i= 0.6 0.4 0.2 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Round

~ l0KB ~ 512KB ~ lMB ~ 2MB

Fig. 14 AES Decryption time at 900 MHz

AES Decryption - 1.0 GHz

3.5

2.5

~ 2 Q) E i= 1.5 1

0.5

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Round

~ lOKB ~ 512KB ~ lMB 2MB

Fig. 15 AES Decryption time at 1.0 GHz

AES Decryption - 1.1 GHz

2.5

2 ~ Q) 1.5 E i= 1

0.5

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Round

~ l0KB ~ 512KB ~ lMB ~ 2MB

Fig. 16 AES Decryption time at 1.1 GHz

AES Decryption - 1.2 GHz

3.5

2.5

~ 2 Q) E i= 1.5 1

0.5

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Round

~ lOKB ~ 512KB ~ lMB 2MB

Fig. 17 AES Decryption time at 1.2 GHz

Overall Average Decryption Time - AES

1.2

0.8 ~ E o.6 i= 0.4

0.2

0 10KB 512KB 1MB 2MB File Size

~ 900 MHz ~ 1.0 GHz ~ 1.1 GHz ~ 1.2 GHz

Fig. 18 Average AES decryption time across all files and processor speeds

AES Encryption Charge Usage

0.016

~ 0.014 .s:: 1 0.012 -; 0.01 Q.0 rn 0.008 :::> a, 0.006 Q.0 ~ 0.004 .s:: u 0.002 0 10KB 512KB 1MB 2MB File Size

~ 900MHz ~ 1.0GHz ~ 1.lGHz ~ 1.2GHz

Fig. 19 Charge usage of AES Encryption across file sizes.

AES Decryption Charge Usage

- 0.014 ..c: 1 0.012 -; 0.01 ~ Cl o.oos :::, Q.J 0.006 ~ ro 0.004 ..c: u 0.002 0 10KB 512KB 1MB 2MB File Size

~ 900 MHz ~ 1.0 GHz ~ 1.1 GHz ~ 1.2 GHz

Fig. 20 Charge usage of AES Decryption across file sizes.

TABLE VIII AES MEMORY USAGE Encryption Decryption File Size Peak Total Peak Total 10KB 97.95KB 213.4KB 98.02KB 213.KB 512KB 97.97KB 213.5KB 98.02KB 213.6KB 1MB 97.97KB 213.5KB 98.02KB 213.6KB 2MB 97.97KB 213.5KB 98.02KB 213.6KB 2) AES-NI

With this version of AES, hardware support was enabled to allow the Crypto++

library to use the ARMv8 AES instruction set. This was performed by compiling the

Crypto++ library with this support enabled. Besides enabling this setting, the testing

application used for AES is reused. To go over the results, first, Fig. 21 – 25 contain the

individual rounds results for encryption across the different files and processor speeds.

Similar to the AES encryption results, the AES-NI results also contain variance between the individual rounds for most of the file sizes; only the 10KB has a consistent encryption time with little variance. For the different processor speeds, there is an identifiable increase in performance as the speed increases. When accounting for some of the round

49 outliers, when comparing the encryption time of the 2MB file at 900 MHz and 1.2 GHz, the round times at 900 MHz are around 1 second while for 1.2 GHz they are around 0.5 seconds. This implies the processor speed does play an important role in encryption time of AES-NI.

Second, the results for the individual AES-NI decryption rounds across the different file sizes and processor speeds are covered in Fig. 26 – 30. Just like encryption, the AES-

NI decryption rounds also show variance between the individual testing rounds except for the 10KB file. However, unlike encryption, there does not seem to be an increase in performance between the different processor speeds. When comparing the 900 MHz decryption times for the 2MB file and the encryption times for 1.2 GHz, these results are similar at around 1 second for each speed.

Next, the charge results for AES-NI encryption and decryption are covered in Fig. 31 and Fig. 32. Each of the lines represents a processor speed with each point being a file size. The points are the milliamp-hours based on the average current across the rounds for a specific file size and processor speed. As is expected, an increase in size results in an increase in charge used. There are some discrepancies in the results (i.e. 512KB using more charge than 1MB), but this can be attributed to the variance in the encryption and decryption times. Overall, the charge used by AES-NI is low with the 2MB file using only over a tenth of a milliamp-hour. For the different processor speeds, charge usage was similar across all with only some variance between the speeds.

Finally, for the memory, Table IX cover the memory usage for encryption and decryption of all files. As mentioned previously, these are snapshots of the AES-NI operation with the memory used at each snapshot. Similar to AES, the AES-NI

50 operations use approximately 100KB of memory at the peak usage. For the total memory usage, all files use approximately 213.5KB for encryption or decryption.

AES-NI Encryption - 900 MHz

2.5

2 3 QJ 1.5 E i= 1

0.5

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Round

~ l0KB ~ 512KB ~ lMB 2MB

Fig. 21 AES-NI Encryption time at 900 MHz

AES-NI Encryption - 1.0 GHz

2.5

3 1.5 QJ E i= 1

0.5

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Round

~ l0KB ~ 512KB ~ lMB ....2MB

Fig. 22 AES-NI Encryption time at 1.0 GHz

AES-NI Encryption - 1.1 GHz

2.5

2 ~ Q) 1.5 E i= 1

0.5

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Round

~ l0KB ~ 512KB ~ lMB ~ 2MB

Fig. 23 AES-NI Encryption time at 1.1 GHz

AES-NI Encryption - 1.2 GHz

1.8 1.6 1.4 1.2 ~ 1 Q) .§ 0.8 r- 0.6 0.4 0.2 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Round

~ lOKB ~ 512KB ~ lMB 2MB

Fig. 24 AES-NI Encryption time at 1.2 GHz

Overall Average Encryption Time - AES-NI

0.8

~ 0.6

0.2

0 10KB 512KB 1MB 2MB File Size

~ 900MHz ~ 1.0GHz ~ 1.lGHz ~ 1.2GHz

Fig. 25 Average AES encryption time across all files and processor speeds

AES-NI Decryption - 900 MHz

2.5

~ 1.5

0.5

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Round

~ l0KB ~ 512KB ~ lMB ~ 2MB

Fig. 26 AES-NI Decryption time at 900 MHz

AES-NI Decryption - 1.0 GHz

3.5

2.5

~ 2 Q) E i= 1.5 1

0.5

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Round

~ l0KB ~ 512KB ~ lMB ~ 2MB

Fig. 27 AES-NI Decryption time at 1.0 GHz

AES-NI Decryption - 1.1 GHz

3.5

- 2.5 ~ E 2 i= 1.5

0.5

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Round

~ lOKB ~ 512KB ~ lMB 2MB

Fig. 28 AES-NI Decryption time at 1.1 GHz

AES-NI Decryption - 1.2 GHz

2.5

2 3 Q) 1.5 E i= 1

0.5

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Round

~ l0KB ~ 512KB ~ lMB ~ 2MB

Fig. 29 AES-NI Decryption time at 1.2 GHz

Overall Average Decryption Time - AES-NI

0.8

30.6 Q) E i= 0.4

0.2

0 10KB 512KB 1MB 2MB File Size

~ 900MHz ~ 1.0GHz ~ 1.lGHz ~ 1.2GHz

Fig. 30 Average AES-NI decryption time across all files and processor speeds

AES-NI Encryption Charge Usage

0.016 - 0.014 ..c: 1 0.012 -; 0.01 ~ Cl o.oos :::, Q.J 0.006 ~ ro 0.004 ..c: u 0.002 0 10KB 512KB 1MB 2MB File Size

~ 900 MHz ~ 1.0 GHz ~ 1.1 GHz ~ 1.2 GHz

Fig. 31 Charge usage of AES-NI Encryption across file sizes

AES-NI Decryption Charge Usage

0.016 - 0.014 ..c: 1 0.012 -; 0.01 ~ Cl o.oos :::, Q.J 0.006 ~ ro 0.004 ..c: u 0.002 0 10KB 512KB 1MB 2MB File Size

~ 900 MHz ~ 1.0 GHz ~ 1.1 GHz ~ 1.2 GHz

Fig. 32 Charge usage of AES-NI Decryption across file sizes

TABLE IX AES-NI MEMORY USAGE Encryption Decryption File Size Peak Total Peak Total 10KB 97.95KB 213.4KB 98.02KB 213.6KB 512KB 98.02KB 213.6KB 98.02KB 213.6KB 1MB 97.97KB 213.5KB 98.02KB 213.6KB 2MB 97.97KB 213.5KB 98.02KB 213.6KB

3) PRESENT

Unlike AES which is part of a library, PRESENT required being implemented before being tested. This implementation follows the encryption and decryption algorithms provided in [36], [37].

First, Fig. 33 – 37 show the times of the individual encryption rounds for the different file sizes across the different processor speeds. The first observation with these results is the consistency of the encryption times across most of the rounds. There are a few rounds which show some variance, but they are very few and with only a slight change. The second observation is the impact of the processor speed on the encryption time. For

10KB file this is not as noticeable since encryption for this file was less than 1 second.

However, for the other files it is more noticeable. The 2MB file encryption time at 900

MHz is around 65 seconds for each round, and at 1.2 GHz this time drops to 50 seconds.

Overall, PRESENT’s encryption does not appear to be impacted by outside processes, and it benefits from faster processor speeds. The only issue is the high encryption times.

The 10KB file is not impacted, but the other 50 – 65 second encryption time for the 2MB file could be considered high for this type of operation.

Second, Fig. 38 – 42 cover the individual decryption rounds for the different file sizes and processor speeds. The decryption time results display the same observations that were mentioned for encryption. The individual rounds show very little variances in time with only a few inconsistent rounds. For the processor speed, the increasing processor speeds also display the same decrease in decryption time that was seen for encryption. A noticeable observation is the similar encryption and decryption time for the same file size

57 and processor speed. When those two items are same, encryption and decryption are the same.

Next, the charge usage results for encryption and decryption are shown in Fig. 43 and

Fig. 44. Since the milliamp-hours are based on the average current of the testing rounds for a processor speed and file size, the charge usage shows an upward slope as the file size increase. Since the encryption and decryption times are higher, these operations use more charge. Encryption and decryption for the 2MB file uses approximately 1 milliamp- hour for all of the processor speeds.

Fourth, the memory usage of encryption and decryption are covered in Table X for all files. For PRESENT, the snapshots show it has a max usage of 100KB for all operations across all file sizes. However, the total memory used by PRESENT has inconsistencies between encryption and decryption. For the 2MB file, during encryption total usage is at

25MB while decryption is at 15MB. The only difference between encryption and decryption is the order of the stages in each operation, yet these stages are the same regardless of the operation. The impact may be due to the optimization of the compiler since there are conditional statements which handle encryption or decryption for those stages. This optimization may be introducing changes which could be impacting the memory usage for encryption.

Finally, the reason for the high encryption and decryption time, and in turn the high charge usage, could be attributed to the permutation layer of PRESENT. Since this portion of the cipher requires accessing each single bit of the data block and moving it to another location, programmatically, this is an expensive task. It requires multiple memory read and write operations in order to update a single bit, and these actions must be

58 repeated 62 times per round. The high amount of these types of operations greatly increase the time.

PRESENT Encryption - 900 MHz

70 ► 1 I I I I I I 8 8 8 ♦ I 8 8 8 8 I 8 8 8 8 I 8 8 60 _ 50 ~ Q) 40 E i= 30

20 • • • • • • • • • • • • • • • • • • • • • • • • • ► 1 I 8 I I I I I 8 I I I I 8 8 I 8 8 8 I I 8 8 8 10

0 8 8 8 8 I 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Round

~ lOKB ~ 512KB ~ lMB ~ 2MB

Fig. 33 PRESENT Encryption time at 900 MHz

PRESENT Encryption - 1.0 GHz

E 40 Q) E i= 30 8 8 8 8 I ♦ I I • I 8 8 8 I •• ♦ I 8 8 8 8 8 I,. 20

10 • • • • • • • • • • • • • • • • • • • • • • • • •

0 • • • • • • • • • • • • • • • • • • • • • • • • • 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Round

~ l0KB ~ 512KB ~ lMB ~ 2MB

Fig. 34 PRESENT Encryption time at 1.0 GHz

PRESENT Encryption - 1.1 GHz

60 .A-a... ..a.. ~ ...... ~ ~..,...... -...... 50 ...... ~.~·--··--·~·~·---·

40 ~ Q) E 30 i= 20 I I I • I I I I • I I I • • I I I I I •• I I ...... I I I I I I I I I 10 • • • • • • • • • • • • • • •

0 • • • • • • • • • • • • • • • • • • • • • • • • • 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Round

~ lOKB ~ 512KB ~ lMB ~ 2MB

Fig. 35 PRESENT Encryption time at 1.1 GHz

PRESENT Encryption - 1.2 GHz

50 ~ I I • I e I • I ... • , ... • I I e • I I I I •

E 30 i= 20 I • I • • • • • • • • • • • • • • • • • • • I • •

10 • • • • • • • • I ♦ I • • • • • • • • I • I • • •

0 • • • • • • • • • • • • • • • • • • • • • • • • • 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Round

~ lOKB ~ 512KB ~ lMB ~ 2MB

Fig. 36 PRESENT Encryption time at 1.2 GHz

Overall Average Encryption Time - PRESENT

50 ~ 40

0 10KB 512KB 1MB 2MB File Size

~ 900 MHz ~ 1.0 GHz ~ 1.1 GHz ~ 1.2 GHz

Fig. 37 Average PRESENT encryption time across all files and processor speeds

PRESENT Decryption - 900 MHz

70 4,..1 e e e e e e e e I• a a e e e e e e I a I e e 60

~50 ~

20 • • • • • • • • • • • • • • • • • • • • • • • • • I I 10 •• • • • • • • • • • • • • • • • • • • • • • 0 • • • • • • • • • • • • • • • • • • • • • • • • • 1 2 3 4 5 6 7 8 9 10 1112 13 14 15 16 17 18 19 20 21 22 23 24 25 Round

~ l0KB ~ 512KB ~ lMB ~ 2MB

Fig. 38 PRESENT Decryption time at 900 MHz

PRESENT Decryption - 1.0 GHz

60 ~ • .A,.... """ ...... """ ...... ---4 ...... --• ..... -=-...... ~.

~40 Q) E i= 30

20 • • • • • • • • • • • • • • • • • • • • • • • • •

10 • • • • • • • • • • • • • • • • • • • • • • • • •

0 ••••••••••••••••••••••••• 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Round

~ l0KB ~ 512KB ~ lMB ~ 2MB

Fig. 39 PRESENT Decryption time at 1.0 GHz

PRESENT Decryption - 1.1 GHz

70 60 -----... -----... 50 ...... ·~ ...... ~40 Q) .§ 30 r- 20 ...... ~ 10 • • • • • • • • • • • • • • • • • • • • • • • • • 0 ••••••••••••••••••••••••• 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Round

~ lOKB ~ 512KB ~ lMB ~ 2MB

Fig. 40 PRESENT Decryption time at 1.1 GHz

PRESENT Decryption - 1.2 GHz

a! 30 E i= 20 e e e e e I I e ♦ e e e e e e e e e e e e e e e e

10 8 8 8 I I I 8 8 8 I I 8 8 8 I I I 8 8 I I I I 8 8

0 ••••••••••••••••••••••••• 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Round

~ l0KB ~ 512KB ~ lMB ~ 2MB

Fig. 41 PRESENT Decryption time at 1.2 GHz

Overall Average Decryption Time - PRESENT

70 60 50 3 40 Q) -~ 30 f- 20 10 0 10KB 512KB 1MB 2MB File Size

~ 900 MHz ~ 1.0 GHz ~ 1.1 GHz ~ 1.2 GHz

Fig. 42 Average PRESENT decryption time across all files and processor speeds

PRESENT Encryption Charge Usage

1.2

:2 1 <( _s 0.8 Q.J ~ Cl o.6 :::, ~ 0.4 ro i5 0.2

0 10KB 512KB 1MB 2MB File Size

~ 900 MHz ~ 1.0 GHz ~ 1.1 GHz ~ 1.2 GHz

Fig. 43 Charge usage of PRESENT Encryption across file sizes

PRESENT Decryption Charge Usage

1.2

:2 1 <( _s 0.8 Q.J ~ Cl o.6 :::, ~ 0.4 ro i5 0.2

0 10KB 512KB 1MB 2MB File Size

~ 900 MHz ~ 1.0 GHz ~ 1.1 GHz ~ 1.2 GHz

Fig. 44 Charge usage of PRESENT Decryption across file sizes

TABLE X PRESENT MEMORY USAGE Encryption Decryption File Size Peak Total Peak Total 10KB 98.64KB 329.8KB 98.62KB 276.8KB 512KB 98.64KB 5.938MB 98.62KB 3.640MB 1MB 98.64KB 10.31MB 98.62KB 6.261MB 2MB 98.64KB 24.88MB 98.62KB 15.03MB

4) MSEA

Similar to PRESENT, MSEA was also implemented before testing. The

implementation follows the algorithm provided in [38].

First, Fig. 45 – 49 cover the MSEA encryption time results across the different

file sizes and processor speeds. The first observation with these results is the consistent

results among most of the rounds. There are some rounds which have some variance, but

these are few rounds. A second observation is the effect that the processor speed has on

the encryption time. The higher processor speeds perform the encryption in faster times.

The 2MB file at 900 MHz was encrypted around 250 second while at 1.2 GHz the time

drops to around 175 seconds. Overall, MSEA does not seem to be affected by other

processes. The main issue with MSEA encryption is the extremely high encryption times.

The only feasible encryption is for the 10KB file which is at most 1 second; all other files

take too much time to be considered usable. The reasoning for these high times is covered

further below.

Second, Fig. 50 – 54 cover the decryption times across the different files and speeds. The results for decryption are similar to the encryption results. First, the decryption times are consistent across most of the individual rounds. Second, just like encryption, the processor speed also impacts the decryption time. These decryption times are similar to the encryption for the same file size and processor speed. However, since encryption is similar to decryption, it also has the same issue with high decryption times for the larger files. The reasoning for these high times is the same as encryption, and will

be covered below.

Next, the charge used by encryption and decryption are covered in Fig. 55 and

Fig. 56. As is expected, as the file size increases, the charge used by encryption or

decryption also increases. Due to the high encryption and decryption times, this results in

high charge usage for those operations. For the 2MB file, charge usage is between 3 and

4 milliamp-hours depending on the processor speed. This high charge usage also makes

MSEA’s use unfeasible.

Fourth, the memory usage for encryption and decryption of all files is covered in

Table XI. Overall, Massif reports a peak usage of approximately 100KB for all files.

However, although the usage is at 100KB, the total memory usage of MSEA very high.

For the 2MB file, it is using approximately 1.5GB of memory. The other files show a similar high usage for both operations which even for the 10KB is high. The reasoning for this high total usage is also covered below with the encryption and decryption time reasoning.

Finally, there are a few reasons why MSEA has such high times and memory. The first reason would be dynamic block size. The block size impacts the key size and also the subblocks used during the encryption and decryption rounds with the most impact on the time from the subblocks. Since the expanded message is dynamic, the splitting of the message into four equal parts must account for those sizes which do not equally divide.

This required implementing a general approach which would handle any message size.

With this approach, the creation of the subblocks requires copying the state, and this action introduces more memory allocation and reading. This high use of memory read and write increase the memory usage and encryption and decryption times. However, the biggest reason for the high encryption/decryption times and memory usage is the data

66 dependent rotation. This type of rotation requires a complex implementation to perform its task since it is not the common type of rotation. The operation requires memory copying, conditional statements, and shift operations to only shift the relevant portion of the message while leaving the rotation information in its place. The complexity is also increased with the introduction of the dynamic block size since the data dependent rotation must now account varying data dependent rotation bits. Overall, these two are the major reason why MSEA has such high encryption and decryption times, charge usage, and memory usage. These expensive results were the reason testing was limited to a max of 2MB; anything higher than this size greatly increased the overall cipher testing.

Encryption - 900 MHz

300 250 •• .,---- . -.- .Ii -.- •• .--...-A,- .- • -.- -.- -.- • -.- ....- 200 ~ Q) 150 E i= 100 • • • I • • • • • • • • • I • ~ • • • • • • • 50 •• • • • • • • • • I • I • I • • • • I • • • • • 0 • •1 •2 • 3 • 4 5 • 6 • 7 • 8 • 9 10• 11• 12• 13• 14• 15• 16• 17• 18• 19• 20• 21• 22• 23• 24• 25• Round

~ lOKB ~ 512KB ~ lMB ~ 2MB

Fig. 45 MSEA Encryption time at 900 MHz

MSEA Encryption - 1.0 GHz

250

I I I I I I I I I I I I I I I I I I I I I I 200 • ••

~ 150

Q) E i= 100 I --e I I I I I I I I I I I I I I I I I I I I I I • 50 I I I I I I I I • • I I I I I I I I I I I I I I I

0 I I I I I I I I I I I I I I I I I I I I I I I I I 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Round

~ l0KB ~ 512KB ~ lMB ~ 2MB

Fig. 46 MSEA Encryption time at 1.0 GHz

MSEA Encryption - 1.1 GHz

250

200 I I I I I 9 I I I I ..a,• ...... I I I I I I I I I I

~ 150

Q) E i= 100 ..__ I I • I I I I I I I I I I I I I I I I I I I . 50 ... • I I • I I I I • I • I • I I • • I I I I I I

0 I I I I I I I I I I I I I I I I I I I I I I I I I 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Round

~ lOKB ~ 512KB ~ lMB ~ 2MB

Fig. 47 MSEA Encryption time at 1.1 GHz

MSEA Encryption - 1.2 GHz

250

200 A I 8 8 I I 8 8 8 8 8 8 8 ...... I 8 8 8 e _,A

3 150 Q) E i= 100 8 8 8 8 8 8 I I 8 8 8 I 8 8 8 I I 8 8 I I I I 8 8 50 e I 8 I e I 8 I I 8 8 I I 8 8 8 8 8 8 8 8 8 8 8 8

0 • • • • • • • • • • • • • • • • • • • • • • • • • 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Round

~ l0KB ~ 512KB ~ lMB ~ 2MB

Fig. 48 MSEA Encryption time at 1.2 GHz

Overall Average Encryption Time - MSEA

300

250

200 3 Q) 150 E i= 100

0 10KB 512KB 1MB 2MB File Size

~ 900 MHz ~ 1.0 GHz ~ 1.1 GHz ~ 1.2 GHz

Fig. 49 Average MSEA encryption time across all files and processor speeds

MSEA Decryption - 900 MHz

300

250

200 ~ Q) E 150 i= 100 • • • • • I • • • • • • I I • •• I • • I • • I • so • • • • • • I • • • • I I • • • I I • I • I I • •

0 • • • • • • • • • • • • • • • • • • • • • • • • • 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Round

~ lOKB ~ 512KB ~ lMB ~ 2MB

Fig. 50 MSEA Decryption time at 900 MHz

MSEA Decryption - 1.0 GHz

250 e I e I e • e e I • • e e ♦ I e e e e e e e e e e 200

~ 150

Q) E i= 100

50 e e I e e e e e e e e e I e e e e e e e e e e e e

0 • • • • • • • • • • • • • • • • • • • • • • • • • 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Round

~ lOKB ~ 512KB ~ lMB ~ 2MB

Fig. 51 MSEA Decryption time at 1.0 GHz

MSEA Decryption - 1.1 GHz

250

200 J 8 I 8 a 8 e 8 ~ I I ■ + 0 8 I ♦ I e•

~ 150

Q) E i= 100 • • • • •• • • • • • I • •• • • I • I • 50 • • I I • • • I • • • I • • • • • • •• I -~• I • • 0 • • • • • • • • • • • • • • • • • • • • • • • • • 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Round

~ lOKB ~ 512KB ~ lMB ~ 2MB

Fig. 52 MSEA Decryption time at 1.1 GHz

MSEA Decryption - 1.2 GHz

250

200 .... • I I I • • • • • • • • • • • ••• • • • I ... ~ 150

Q) E i= 100 • • • • • • • • • I • • • • • • • • • • • • • ... 50 • I I I • • • • I • • • • I • I I I I • • I I I • 0 •1 •2 • 3 • 4 •5 •6 • 7 • 8 • 9 10• 11• 12• 13• 14• 15• 16• 17• 18• 19• 20• 21• 22• 23• 24• 25• Round

~ lOKB ~ 512KB ~ lMB ~ 2MB

Fig. 53 MSEA Decryption time at 1.2 GHz

Overall Average Decryption Time - MSEA

300

250

200 ~

0 10KB 512KB 1MB 2MB File Size

~ 900 MHz ~ 1.0 GHz ~ 1.1 GHz ~ 1.2 GHz

Fig. 54 Average MSEA decryption time across all files and processor speeds

MSEA Encryption Charge Usage

4.5 4 :2

~ 900 MHz ~ 1.0 GHz ~ 1.1 GHz ~ 1.2 GHz

Fig. 55 Charge usage of MSEA Encryption across file sizes

MSEA Decryption Charge Usage

4 :2 <( 3.5 _§_ 3 Q.J ~ 2.5 ::S 2 ~ 1.5 ~ 1 u 0.5 0 10KB 512KB 1MB 2MB File Size

~ 900 MHz ~ 1.0 GHz ~ 1.1 GHz ~ 1.2 GHz

Fig. 56 Charge usage of MSEA Decryption across file sizes

TABLE XI MSEA MEMORY USAGE Encryption Decryption File Size Peak Total Peak Total 10KB 98.70KB 7.959MB 98.69KB 8.424MB 512KB 98.70KB 345.7MB 98.69KB 365.9MB 1MB 98.70KB 607.4MB 98.69KB 643.0MB 2MB 98.70KB 1.466GB 98.69KB 1.558GB

5) MSEA-128

Due to the issues that arose with the MSEA, the choice was made to implement a version which constrained the data block size to only 128 bits. This is similar to what was done with the Rjindael cipher which resulted in AES cipher. By limiting the data block size, this limited the key size and expanded message block to 256 bits, and it also set the data dependent rotation bits to only be 7 bits. In addition, the subblocks used during the encryption and decryption rounds are now limited to 64 bits. By constraining the data block size, the encryption and decryption algorithms for MSEA

73 can be optimized since many of the dynamic memory allocations are no longer needed.

First, Fig. 57 – 61 cover the MSEA-128 encryption time results for the individual rounds across the different files and processor speeds. Most of the encryption times are consistent across each of the individual rounds. The only file size which has high variance across its rounds is the 2MB file; the 1MB file has a few outliers, but is mostly consistent. In general, the larger the file size, the higher the encryption time.

For the different processor speeds, there does appear to be some reduction in encryption time with higher speeds, but not enough to be considered impactful. For the 2MB file, most of the encryption times range between 8 and 14 seconds.

Second, Fig. 62 – 66 cover the decryption times for the individual round results.

Similar to encryption, the decryption times are consistent across each of the individual rounds for most of the file sizes except the 2MB file. The decryption times of the 2MB file also contain high variance across the individual rounds. For the different processor speeds, the decryption times do reduce with higher processor speeds, but just like encryption, there does not seem to be a major impact. At 2MB, the decryption times range between 4 and 10 seconds. An observation with decryption is the lower times when compared to the encryption times of the same file and processor speed.

Next, the charge used by encryption and decryption are shown in Fig. 67 and Fig.

68. The charge used increases as the file size increases. For most of the processor speeds, there is little variance between the charge used to encrypt or decrypt a file. At

2MB, there is a noticeable difference between the charge used at 900 MHz and 1.2

GHz. Another observation is the difference between charge used for encryption and decryption. The decryption charge usage is lower than encryption. This is noticeable with the 2MB file with encryption being in the range of 0.12 – 0.16 mAh wile decryption is in the range of 0.08 – 0.12 mAh.

Fourth, the memory usage of encryption and decryption for all of the files is shown in Table XII. For encryption and decryption, the peak memory usage is at approximately 100KB for all of the files. The total memory usage for encryption and

decryption of a file is consistent. For example, the encryption and decryption memory

usage for the 2MB file is at 25MB for each.

Finally, by constraining the data block size, the performance of MSEA was

greatly increased. The removal of the expensive memory allocations allowed the

encryption/decryption times and the memory usage to be reduced. However, the data

dependent rotation still introduces some complexity into the cipher which somewhat

impacts the encryption and decryption times. This could be considered a reason why

the 2MB file has such great variance between the individual rounds.

MSEA-128 Encryption - 900 MHz

12 _ 10 ~ E 8 i= 6

4 .--....._ ... .,_,....,...... -.... ~ • • • • • • • • • • • ✓ 0 • • • • • • • • • • • • • • • • • • • • • • • • • 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Round

~ lOKB ~ 512KB ~ lMB ~ 2MB

Fig. 57 MSEA-128 Encryption time at 900 MHz

MSEA-128 Encryption - 1.0 GHz

16 14

12 _ 10 ~ E 8 i= 6 ~ :?.:52 :::-::::::::f:::1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Round

~ lOKB ~ 512KB ~ lMB 2MB

Fig. 58 MSEA-128 Encryption time at 1.1 GHz

MSEA-128 Encryption - 1.1 GHz

Q) 6 E i= 4

2 r• a a a • ...,... I a a a a e I a a a a

0 • a a a a a a a a a a a a 8 a a a I a a a a I ... 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Round

~ lOKB ~ 512KB ~ lMB ~ 2MB

Fig. 59 MSEA-128 Encryption time at 1.1 GHz

MSEA-128 Encryption - 1.2 GHz

10 9 8 7 6 ~ Q) 5 E i= 4 3 2 1 0 • a a a a 8 I a a a a a I I a e a a a a a a a a e 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Round

~ lOKB ~ 512KB ~ lMB 2MB

Fig. 60 MSEA-128 Encryption time at 1.2 GHz

Overall Average Encryption Time - MSEA-128

8 ~

0 10KB 512KB 1MB 2MB File Size

~ 900 MHz ~ 1.0 GHz ~ 1.1 GHz ~ 1.2 GHz

Fig. 61 Average MSEA-128 encryption time across all files and processor speeds

MSEA-128 Decryption - 900 MHz

0 •••••••• 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Round

~ l0KB ~ 512KB ~ lMB ~ 2MB

Fig. 62 MSEA-128 Decryption time at 900 MHz

MSEA-128 Decryption - 1.0 GHz

10 9 8 7

~ 6 Q) E 5 i= 4 3 2 1 0 • • • • • • • • • • • • • • • • • • • • • • • • • 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Round

~ lOKB ~ 512KB ~ lMB ~ 2MB

Fig. 63 MSEA-128 Decryption time at 1.0 GHz

MSEA-128 Decryption - 1.1 GHz

10 9 8 7 6 ~ Q) 5 E i= 4 3 2 1 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Round

~ lOKB ~ 512KB ~ lMB 2MB

Fig. 64 MSEA-128 Decryption time at 1.1 GHz

MSEA-128 Decryption - 1.2 GHz

8 7

6 ~5 Q) -~ 4 1- 3 2

1 0 ••••••••••••••••••••••••• 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Round

~ lOKB ~ 512KB ~ lMB ~ 2MB

Fig. 65 MSEA-128 Decryption time at 1.2 GHz

Overall Average Decryption Time - MSEA-128

8 ~ Q) 6 E i= 4

0 10KB 512KB 1MB 2MB File Size

~ 900 MHz ~ 1.0 GHz ~ 1.1 GHz ~ 1.2 GHz

Fig. 66 Average MSEA-128 decryption time across all files and processor speeds

MSEA-128 Encryption Charge Usage

0.18 _ 0.16 ..c: <( 0.14 _§.. 0.12 Q.J ~ 0.1 ::J 0.08 ~ 0.06 ~ 0.04 u 0.02 0 10KB 512KB 1MB 2MB File Size

~ 900 MHz ~ 1.0 GHz ~ 1.1 GHz ~ 1.2 GHz

Fig. 67 Charge usage of MSEA-128 Encryption across file sizes

MSEA-128 Decryption Charge Usage

0.14

:2 0.12 <( E 0.1 fill 0.08 ro V, ::J 0.06 Q.J ~ 0.04 ro ..c: u 0.02

0 10KB 512KB 1MB 2MB File Size

~ 900 MHz ~ 1.0 GHz ~ 1.1 GHz ~ 1.2 GHz

Fig. 68 Charge usage of MSEA-128 Decryption across file sizes

TABLE XII MSEA128 MEMORY USAGE Encryption Decryption File Size Peak Total Peak Total 10KB 98.70KB 349.7KB 98.69KB 349.7KB 512KB 98.70KB 5.957MB 98.69KB 5.957MB 1MB 98.70KB 10.21MB 98.69KB 10.21MB 2MB 98.70KB 25.15MB 98.69KB 25.05MB

6) LEA

Just like MSEA and PRESENT, the LEA cipher required implementation in order to be tested. The implementation follows the algorithm given in [39]. As a note, although the implementation supports using keys of 128, 192, and 256 bits, only the 128-bit portion of the cipher was tested.

First, Fig. 69 – 73 cover the individual round results for encryption across the file sizes and processor speeds. The encryption times for most of the rounds are consistent.

The few rounds that are not, could be considered outliers. However, even though they are outliers, the variance is small with only two rounds having an increase of 1 second. For the different processor speeds, there is a notable decrease in encryption time with higher speeds. With the 2MB file, at 900 MHz, the encryption time is approximately 3 seconds while at 1.2 GHz it is 2.25 seconds.

Second, Fig. 74 – 78 cover the individual decryption round results for the different file sizes and processor speeds. Similar to encryption, the decryption times for most of the rounds are consistent. There are a few rounds that were not consistent, but these could be considered outliers. For the different processor speeds, the decryption times also have a notable decrease with higher processor speeds. For the 2MB file, the average decryption time for 900 MHz was 3 seconds while for 1.2 GHz average decryption was

2.25 seconds.

Third, the charge usage results for encryption and decryption are covered in Fig. 79 and Fig. 80. As is expected, the increase in file sizes also results in an increase in charge usage. For most of the files, regardless of the processor speed, the charge usage is very similar. Only the 2MB file has a difference between the 900 MHz and 1.2 GHz, however,

this difference is only within 0.01 mAh. Overall, the charge usage of LEA is small with

the highest usage being approximately 0.05 mAh for the 2MB file at 900 MHz for

encryption and decryption.

Fourth, the memory usage for encryption and decryption of the all files is covered in

Table XIII. Just like the previous ciphers, LEA has a peak memory snapshot usage of

100KB for all files and operations. For the total memory usage, it is approximately 7.6 to

7.7 MB for the 2MB file. The other files also show a small usage of memory for the

operations. Overall, this is a small amount of memory since it can be assumed that about

half of the total usage deals with the plaintext and ciphertext; these two would cover

4MB of the total memory usage.

Finally, LEA does not seem to have many drawbacks. The implementation of the

algorithms is direct with mostly using basic operations. LEA also relies on 32-bit subblocks which can be converted to unsigned integers, and it allows for the use of those basic operations. The memory usage may be able to be reduced by modifying the cipher implementation to be in-place rather than copying the plaintext/ciphertext. Overall, this implementation does not seem to have many drawbacks when compared to other ciphers.

LEA Encryption - 900 MHz

4.5

4 3.5

3 ~ 2.5 Q) ! 2 1.5 ..."""4.l'-4 ...... """4.l'-4 ...... """4.l'-4·~· ...... 1 • • • • • J\► 0.5

0 .. • • • • • I • • • • • • • • • • • • • • • e e e 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Round

~ lOKB ~ 512KB ~ lMB 2MB

Fig. 69 LEA Encryption time at 900 MHz

LEA Encryption - 1.0 GHz

4.5

4 3.5 3 ~ 2.5 Q) E 2 i= 1.5

1 : : : :::::: : : 0.5 :;>-:::: : : : : : : : :;;::::: : :

O • I • • • e • 8 • • • • I I • • 8 • • e • • • • • 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Round

~ lOKB ~ 512KB ~ lMB _._2MB

Fig. 70 LEA Encryption time at 1.0 GHz

LEA Encryption - 1.1 GHz

2.5

2 ~ Q) E 1.5 i=

1 : : ::::::: : : : : : : : : 0.5 ~ r:x::::

o e e e e e e e e e e e e e e e I e e I I ♦ ♦ I e 8 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Round

~ lOKB ~ 512KB ~ lMB ~ 2MB

Fig. 71 LEA Encryption time at 1.1 GHz

LEA Encryption - 1.2 GHz

2.5 ...... -A,...... , ....,...... ••••• 2

~ 1.5 Q) E i= 1

0.5

0 e e e e e e e e e I I e e • ■ e • • 8 • • I e e 8 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Round

~ lOKB ~ 512KB ~ lMB _._2MB

Fig. 72 LEA Encryption time at 1.2 GHz

Overall Average Encryption Time - LEA

3.5

2.5 ~ 2

0.5

0 10KB 512KB 1MB 2MB File Size

~ 900 MHz ~ 1.0 GHz ~ 1.1 GHz ~ 1.2 GHz

Fig. 73 Average LEA encryption time across all files and processor speeds

LEA Decryption - 900 MHz

3.5

2.5

~ 2

0.5 :: :: :;:I.;::: :~ ::x:: O • I e e 8 8 a I I I I I I I I I 8 I a I 8 I I 8 a 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Round

~ l0KB ~ 512KB ~ lMB _._2MB

Fig. 74 LEA Decryption time at 900 MHz

LEA Decryption - 1.0 GHz

3.5 3 ~ ~ 2.5 __..__ ...... A ...... ~ Q) E 2 i= 1.5 I 1 • • • • • • • • •• • • • • • • • • • • • I ... I 0.5 • ! • • ~ • • • ! _ ... ·- I -· 0 I I • • I • • • I • • • • I • • • • • • I • • • 1 2 3 4 5 6 7 8 9 10 111213 14 15 16 17 18 19 20 21 22 23 24 25 Round

~ lOKB ~ 512KB ~ lMB 2MB

Fig. 75 LEA Decryption time at 1.0 GHz

LEA Decryption - 1.1 GHz

2.5

2 ~ Q) 1.5 E i= 1

0.5 ~::::::::A:: :A:: 0 I I I I I I I I I I I I I I I I I I I I I I I I I 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Round

~ lOKB ~ 512KB ~ lMB ~ 2MB

Fig. 76 LEA Decryption time at 1.1 GHz

LEA Decryption - 1.2 GHz

3 2.5 ...... a a••~- a•••..,,.• a•• a A,.. a a 2 3 Q) 1.5 E i= 1

0.5

0 •••••••• ... A ...... 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Round

~ lOKB ~ 512KB ~ lMB 2MB

Fig. 77 LEA Decryption time at 1.2 GHz

Overall Average Decryption Time - LEA

3.5

3 2.5 3 2 Q) ! 1.5 1 0.5

0 10KB 512KB 1MB 2MB File Size

~ 900 MHz ~ 1.0 GHz ~ 1.1 GHz ~ 1.2 GHz

Fig. 78 Average LEA decryption time across all files and processor speeds

LEA Encryption Charge Usage

0.06

:2 0.05 <( _§.. 0.04 Q.J ~ Cl o.o3 :::, ~ 0.02 ro i5 0.01

0 10KB 512KB 1MB 2MB File Size

~ 900 MHz ~ 1.0 GHz ~ 1.1 GHz ~ 1.2 GHz

Fig. 79 Charge usage of LEA Encryption across file sizes

LEA Decryption Charge Usage

0.06

:2 0.05 <( _§.. 0.04 Q.J ~ Cl o.o3 :::, ~ 0.02 ro i5 0.01

0 10KB 512KB 1MB 2MB File Size

~ 900 MHz ~ 1.0 GHz ~ 1.1 GHz ~ 1.2 GHz

Fig. 80 Charge usage of LEA Decryption across file sizes

TABLE XIII LEA MEMORY USAGE Encryption Decryption I File Size Peak Total Peak Total 10KB 98.64KB 329.8KB 98.62KB 276.8KB 512KB 98.64KB 5.938MB 98.62KB 3.640MB 1MB 98.64KB 10.31MB 98.62KB 6.261MB 2MB 98.64KB 24.88MB 98.62KB 15.03MB

B. Cipher Comparison

In this section the individual cipher results will be compared. This section is split into the testing categories.

1) Encryption/Decryption Times

The figures (Fig. 81 – Fig. 88) and tables (Table XIV – Table XXI) below compare

the different ciphers; they are grouped in the different processor speeds. The tables

contain the specific values used for the comparison at each processor speed. Overall, only

the encryption or decryption time for the 10KB file is where there is some form of

competition between all of the ciphers. With all other file sizes, the MSEA and

PRESENT provide no competition to the other ciphers. From the remaining ciphers

(AES, AES-NI, LEA, MSEA-128), MSEA-128 is the slowest with most operations on

512KB files and larger being over 1 second. The only cipher which can compete with

AES/AES-NI is the LEA cipher; however, it is still a bit slower when compared to both versions of AES. This could be attributed to the implementation of LEA which there may

be a possibility to increase its performance through proper optimization. Finally, out of

both AES versions, the hardware version (AES-NI) performs slightly better. Of course,

this requires that the underlying hardware provides support for this version.

Encryption - 900 MHz

300

250

200 :§: Cl) 150 E i= 100

0 10KB 512KB 1MB 2MB File Size

~ AES w/NI ~ AES ~ PRESENT ~ MSEA ~ MSEA-128 ~ LEA

Fig. 81 Encryption time comparison at 900 MHz

Decryption - 900 MHz

300

250

200 :§: Cl) 150 E i= 100

0 10KB 512KB 1MB 2MB File Size

~ AES w/NI ~ AES ~ PRESENT ~ MSEA ~ MSEA-128 ~ LEA

Fig. 82 Decryption time comparison at 900 MHz

TABLE XIV ENCRYPTION TIMES - 900 MHZ Cipher 10KB 512KB 1MB 2MB AES w/NI 0.036561375 0.406123133 0.3310429 0.805720091 AES 0.041328812 0.485640535 0.461058168 0.74743331 PRESENT 0.415949841 15.35969563 26.75543036 65.9489232 MSEA 1.312102003 56.53490675 99.57462336 244.7061781 MSEA- 128 0.079899979 2.205999622 3.999214659 9.698362932 LEA 0.046031637 0.736690044 1.271600351 3.09079298

TABLE XV DECRYPTION TIMES - 900 MHZ Cipher 10KB 512KB 1MB 2MB AES w/NI 0.023287392 0.404521942 0.331219854 0.805720091 AES 0.02783885 0.728718147 0.26803071 0.74743331 PRESENT 0.361842079 15.24337824 26.64027146 65.9489232 MSEA 1.292318497 56.5321081 100.2845337 244.7061781 MSEA- 128 0.051734228 1.567492971 2.911474342 9.698362932 LEA 0.037309675 0.785080538 1.245656281 3.09079298

- 1.0 GHz

250

200

~ 150 Cl.I E i= 100

0 10KB 512KB 1MB 2MB File Size

~ AES w/NI ~ AES ~ PRESENT ~ MSEA ~ MSEA-128 ~ LEA

Fig. 83 Encryption time comparison at 1.0 GHz

- 1.0 GHz

250

200

~ 150 a., E i= 100

0 10KB 512KB 1MB 2MB File Size

~ AES w/NI ~ AES ~ PRESENT ~ MSEA ~ MSEA-128 ~ LEA

Fig. 84 Decryption time comparison at 1.0 GHz

TABLE XVI ENCRYPTION TIMES - 1.0 GHZ Cipher 10KB 512KB 1MB 2MB AES w/NI 0.035207634 0.426270504 0.337765265 0.911273537 AES 0.040890779 0.492385807 0.312651415 0.9870152 PRESENT 0.327417631 13.70683043 24.21627411 59.99087222 MSEA 1.168256607 50.45711139 89.31873894 219.4728751 MSEA- 128 0.121037512 2.082288084 3.589845781 9.212213297 LEA 0.056847563 0.688727436 1.096411457 2.758111115

TABLE XVII DECRYPTION TIMES - 1.0 GHZ Cipher 10KB 512KB 1MB 2MB AES w/NI 0.02260066 0.39116683 0.388022995 0.911273537 AES 0.047567272 0.506279049 0.343830004 0.9870152 PRESENT 0.323391151 13.61818179 23.988963 59.99087222 MSEA 1.164528732 50.47603217 90.49911601 219.4728751 MSEA- 128 0.047117691 1.510478754 2.611582012 9.212213297 LEA 0.039259138 0.657138519 1.099959431 2.758111115

Encryption - 1.1 GHz

250

200

~ 150

0 10KB 512KB 1MB 2MB File Size

~ AES w/NI ~ AES ~ PRESENT ~ MSEA ~ MSEA-128 ~ LEA

Fig. 85 Encryption time comparison at 1.1 GHz

Decryption - 1.1 GHz

250

200

~ 150

0 10KB 512KB 1MB 2MB File Size

~ AES w/NI ~ AES ~ PRESENT ~ MSEA ~ MSEA-128 ~ LEA

Fig. 86 Decryption time comparison at 1.1 GHz

TABLE XVIII ENCRYPTION TIMES - 1.1 GHZ Cipher 10KB 512KB 1MB 2MB AES w/NI 0.073843098 0.459408703 0.443527346 0.693531532 AES 0.022358227 0.338779383 0.38657649 0.576605606 PRESENT 0.322343988 12.721849 21.87261001 54.39608027 MSEA 1.056008701 46.63980384 82.34802528 200.1441879 MSEA- 128 0.080356045 1.819217892 3.441139736 7.950496111 LEA 0.033612223 0.641526375 0.998793573 2.470516224

TABLE XIX DECRYPTION TIMES - 1.1 GHZ Cipher 10KB 512KB 1MB 2MB AES w/NI 0.020755701 0.385308971 0.281057081 0.693531532 AES 0.024632883 0.540957785 0.276826305 0.576605606 PRESENT 0.297120543 12.57350369 22.05833353 54.39608027 MSEA 1.065919132 46.37768875 83.34906972 200.1441879 MSEA- 128 0.077823582 1.359039335 2.541555252 7.950496111 LEA 0.026987429 0.633082924 1.002041245 2.470516224

Encryption - 1.2 GHz

150

a.J 100 E i= 50

0 10KB 512KB 1MB 2MB File Size

~ AES w/NI ~ AES ~ PRESENT ~ MSEA ~ MSEA-128 ~ LEA

Fig. 87 Encryption time comparison at 1.2 GHz

Decryption - 1.2 GHz

150

a.J 100 E i= 50

0 10KB 512KB 1MB 2MB File Size

~ AES w/NI ~ AES ~ PRESENT ~ MSEA ~ MSEA-128 ~ LEA

Fig. 88 Decryption time comparison at 1.2 GHz

TABLE XX ENCRYPTION TIMES - 1.2 GHZ Cipher 10KB 512KB 1MB 2MB AES w/NI 0.040965624 0.38931262 0.407029581 0.789779091 AES 0.024709454 0.496618576 0.302436543 0.415392561 PRESENT 0.275897617 11.51841415 20.08442968 49.57141211 MSEA 1.002002449 42.64795679 73.73856224 184.2500286 MSEA- 128 0.078128605 1.696294785 3.106973171 7.324689198 LEA 0.047372026 0.623178053 0.924406576 2.253172436

TABLE XXI DECRYPTION TIMES - 1.2 GHZ Cipher 10KB 512KB 1MB 2MB AES w/NI 0.025513067 0.369736624 0.523797188 0.789779091 AES 0.017016439 0.441902704 0.490962725 0.415392561 PRESENT 0.26972806 11.42026425 20.03557709 49.57141211 MSEA 0.969998007 42.31522377 74.31311958 184.2500286 MSEA- 128 0.041307182 1.206096439 2.292667007 7.324689198 LEA 0.045608931 0.665288553 0.916484728 2.253172436

2) Charge Usage

Since the charge usage is dependent on the encryption or decryption time, the charge usage for the ciphers follow a similar pattern as encryption/decryption. Fig. 89 - Fig. 96 show a similar representation to encryption/decryption for the results even though it is representing charge usage. This means that MSEA and PRESENT use much more charge than the other four ciphers, and cannot be considered as a competition for AES. MSEA-

128 provides some competition at the smaller file sizes, but at lager files, it is still slower when compared to other three ciphers. Again, the only cipher which offers any competition to AES is LEA. It still uses slightly more charge when compared to AES, but

LEA’s charge usage could also be improved by optimizing the implementation. Finally,

AES-NI has the least amount of charge usage when compared to AES, but this difference could be considered insignificant.

Encryption Charge Usage - 900 MHz

~ 4 .s::

~ AES ~ AES w/ NI ~ PRESENT ~ MSEA ~ MSEA-128 ~ LEA

Fig. 89 Cipher charge usage for encryption at 900 MHz

Decryption Charge Usage - 900 MHz

4.5 ~ 4 .s::

~ AES ~ AES w/ NI ~ PRESENT ~ MSEA ~ MSEA-128 ~ LEA

Fig. 90 Cipher charge usage for decryption at 900 MHz

Encryption Charge Usage - 1.0 GHz

~ 3.5 .s:: 1 3 -; 2.5 Q.0 Bl 2 ::::) (l) 1.5 Q.0 ~ 1 .s:: u 0.5 0 10KB 512KB 1MB 2MB File Size

~ AES ~ AES w/ NI ~ PRESENT ~ MSEA ~ MSEA-128 ~ LEA

Fig. 91 Cipher charge usage for encryption at 1.0 GHz

Decryption Charge Usage - 1.0 GHz

~ 3.5 .s:: 1 3 -; 2.5 QC Cl 2 :::) Cl) 1.5 QC ~ 1 .s:: u 0.5 0 10KB 512KB 1MB 2MB File Size

~ AES ~ AES w/ NI ~ PRESENT ~ MSEA ~ MSEA-128 ~ LEA

Fig. 92 Cipher charge usage for decryption at 1.0 GHz

Encryption Charge Usage - 1.1 GHz

3.5

:2 3

~ 2 ro V, :::) 1.5 Cl) ~ 1 ro .s:: u 0.5

0 10KB 512KB 1MB 2MB File Size

~ AES ~ AES w/ NI ~ PRESENT ~ MSEA ~ MSEA-128 ~ LEA

Fig. 93 Cipher charge usage for encryption at 1.1 GHz

Decryption Charge Usage - 1.1 GHz

~ 3.5 .s:: 1 3 -; 2.5 QC Cl 2 :::) Cl) 1.5 QC ~ 1 .s:: u 0.5 0 10KB 512KB 1MB 2MB File Size

~ AES ~ AES w/ NI ~ PRESENT ~ MSEA ~ MSEA-128 ~ LEA

Fig. 94 Cipher charge usage for decryption at 1.1 GHz

Encryption Charge Usage - 1.2 GHz

3.5

:2 3

~ 2 ro V, :::) 1.5 Cl) ~ 1 ro .s:: u 0.5

0 10KB 512KB 1MB 2MB File Size

~ AES ~ AES w/ NI ~ PRESENT ~ MSEA ~ MSEA-128 ~ LEA

Fig. 95 Cipher charge usage for encryption at 1.2 GHz

100

Decryption Charge Usage - 1.2 GHz

:2 3

~ 2 Cl :::) 1.5 Cl) ~ 1 ro ..r:: u 0.5

0 10KB 512KB 1MB 2MB File Size

~ AES ~ AES w/ NI ~ PRESENT ~ MSEA ~ MSEA-128 ~ LEA

Fig. 96 Cipher charge usage for decryption at 1.2 GHz

3) Memory Usage

Since the peak memory usage is approximately 100KB for all of the ciphers, the cipher comparison will be performed using the total byte usage. Table XXII and Table

XXIII contain the encryption and decryption total usage for all ciphers across all files.

For the 10KB file, both AES ciphers use the least amount of memory followed by LEA,

PRESENT, and MSEA128. LEA is the closest to AES by just using 30KB more; the other two use approximately 100KB more for their operations. For the remaining files, only the AES ciphers continue to use the same amount of memory. LEA increases in usage, but as it was mentioned previously, this may be due to not using in-place encryption. PRESENT and MSEA128 increases as with both using the same amount of memory; decryption for PRESENT uses less memory, but since results are for the overall cipher, the higher memory usage can be considered the ciphers true usage. There has not been a mention of MSEA due to its extremely high memory usage which provides no competition with the other ciphers.

101

TABLE XXII ENCRYPTION MEMORY USAGE OF ALL CIPHERS Cipher 10KB 512KB 1MB 2MB AES 213.4KB 213.5KB 213.5KB 213.5KB AES-NI 213.4KB 213.6KB 213.5KB 213.5KB PRESENT 329.8KB 5.938MB 10.31MB 24.88MB MSEA 7.959MB 345.7MB 607.4MB 1.466GB MSEA128 349.7KB 5.957MB 10.21MB 25.15MB LEA 240.2KB 1.919MB 3.230MB 7.631MB

TABLE XXIII DECRYPTION MEMORY USAGE OF ALL CIPHERS Cipher 10KB 512KB 1MB 2MB AES 213.KB 213.6KB 213.6KB 213.6KB AES-NI 213.6KB 213.6KB 213.6KB 213.6KB PRESENT 276.8KB 3.640MB 6.261MB 15.03MB MSEA 8.424MB 365.9MB 643.0MB 1.558GB MSEA128 349.7KB 5.957MB 10.21MB 25.05MB LEA 240.2KB 1.919MB 3.230MB 7.702MB

VII. CONCLUSION

Most of the lightweight ciphers presented in this paper cannot be considered candidates for replacement of the AES cipher in lightweight environments. These ciphers could be considered in a general setting such as a server or desktop. PRESENT and

MSEA are too costly in terms of time, charge usage, and memory. PRESENT requires hardware support in order to increase its performance, but this has the impact of increasing the manufacturing cost due to that specialized hardware. For MSEA, although it provides some great security with some of the options it introduces, it is too costly to operate in a lightweight device. However, by placing constraints on MSEA (MSEA-128), its performance can be greatly increased. The constrained version is still slow when compared to the tested version of AES (AES-128) since MSEA-128 is similar to AES-

256.

102

Out of all of the lightweight ciphers tested, LEA is the only cipher which could compete against AES. LEA is just slightly slower than AES, but this could be improved with optimization. This is also true for the charge usage since the encryption/decryption times are related to the charge. The only costly part of LEA is the memory usage, but this

could also be improved with optimization. Overall, LEA, or a very similar cipher, could

be considered as a replacement for AES in lightweight devices.

VIII. FUTURE WORKS

Due to the rise in IoT devices and the major differences between those devices, there

will need to be more than a general cipher. Although this paper covers some lightweight

ciphers, these may only be specialized to certain applications. There may never be a

single lightweight cipher which can be used for all applications of an IoT device. Each

application will have its own requirements, and these will have to be considered when

selecting the appropriate cipher. In order to cover these requirements, other lightweight

ciphers will have to be designed to fit within those constraints. First, these applications,

or at least a generalized version, will have to be identified. There is already research into

many of these applications, but new applications continue to appear as IoT continues to

expand into other areas [43]. Next, once they are identified, lightweight ciphers which meet the needs of the application can be selected. Finally, in this paper, only two cipher

design models were considered: SPN and ARX, however, there are other that also exist.

These other design models should also be considered since they may be better suited for

specific lightweight environments/applications.

103

REFERENCES

[1] S. Li, L. Da Xu, and S. Zhao, “The internet of things: a survey,” Inf. Syst. Front.,

vol. 17, no. 2, pp. 243–259, 2015.

[2] A. Whitmore, A. Agarwal, and L. Da Xu, “The Internet of Things—A survey of

topics and trends,” Inf. Syst. Front., vol. 17, no. 2, pp. 261–274, 2015.

[3] T. Borgohain, U. Kumar, and S. Sanyal, “Survey of Security and Privacy Issues of

Internet of Things,” arXiv Prepr. arXiv1501.02211, p. 7, 2015.

[4] D. Gibson, CompTIA Security+ get certified get ahead SYO-401 study guide.

Virgina Beach: YCDA, LLC, 2014.

[5] A. Amamra, “Introduction to Information Security.” Pomona, 2017.

[6] N. Kumar, J. Madhuri, and M. ChanneGowda, “Review on security and privacy

concerns in Internet of Things,” 2017 Int. Conf. IoT Appl., no. November, pp. 1–5,

2017.

[7] W. Julian Okello, Q. Liu, F. Ali Siddiqui, and C. Zhang, “A survey of the current

state of lightweight cryptography for the Internet of things,” IEEE CITS 2017 -

2017 Int. Conf. Comput. Inf. Telecommun. Syst., pp. 292–296, 2017.

[8] K. A. McKay, L. Bassham, M. S. Turan, and N. Mouha, “Report on lightweight

cryptography,” 2017.

[9] L. Da Xu, W. He, and S. Li, “Internet of things in industries: A survey,” IEEE

Trans. Ind. Informatics, vol. 10, no. 4, pp. 2233–2243, 2014.

[10] I. Erguler, “A potential weakness in RFID-based Internet-of-things systems,”

Pervasive Mob. Comput., vol. 20, pp. 115–126, 2015.

[11] J. Yick, B. Mukherjee, and D. Ghosal, “Wireless sensor network survey,” Comput.

104

Networks, vol. 52, no. 12, pp. 2292–2330, 2008.

[12] T. J. Gerpott and P. Meinert, “Who signs up for NFC mobile payment services?

Mobile network operator subscribers in Germany,” Electron. Commer. Res. Appl.,

vol. 23, pp. 1–13, 2017.

[13] D. Valtchev and I. Frankov, “Service gateway architecture for a smart home,”

IEEE Commun. Mag., vol. 40, no. 4, pp. 126–132, 2002.

[14] T. O. Alliance, “The OSGi Alliance OSGi Compendium,” no. July, 2015.

[15] R. Mahmoud, T. Yousuf, F. Aloul, and I. Zualkernan, “Internet of things (IoT)

security: Current status, challenges and prospective measures,” 2015 10th Int.

Conf. Internet Technol. Secur. Trans. ICITST 2015, no. October, pp. 336–341,

2016.

[16] L. Peterson and B. Davie, Computer networks: a systems approach. Amsterdam:

Morgan Kaufmann, 2012.

[17] P. Kumar, S. Rawat, T. Choudhury, and S. Pradhan, “A performance based

comparison of various symmetric cryptographic algorithms in run-time scenario,”

Proc. 5th Int. Conf. Syst. Model. Adv. Res. Trends, SMART 2016, pp. 37–41, 2017.

[18] G. Singh and S. Supriya, “A Study of Encryption Algorithms (RSA, DES, 3DES

and AES) for Information Security,” Int. J. Comput. Appl., vol. 67, no. 19, pp. 33–

38, 2013.

[19] I. Journal and N. Security, “Performance Evaluation of Symmetric Encryption

Algorithms Performance Evaluation of Symmetric Encryption Algorithms,” no.

January, pp. 58–64, 2009.

[20] P. Teufl, A. Fitzek, D. Hein, A. Marsalek, A. Oprisnik, and T. Zefferer, “Android

105

encryption systems,” 2014 Int. Conf. Priv. Secur. Mob. Syst. Prism. 2014 - Co-

located with Glob. Wirel. Summit, 2014.

[21] H. Suo, J. Wan, C. Zou, and J. Liu, “Security in the internet of things: A review,”

Proc. - 2012 Int. Conf. Comput. Sci. Electron. Eng. ICCSEE 2012, vol. 3, pp. 648–

651, 2012.

[22] IEEE Computer Society Sponsored, “Part 11: Wireless LAN Medium Access

Control (MAC) and Physical Layer (PHY) Specifications IEEE Computer

Society,” Control, vol. 2007, no. June, 2007.

[23] H. Dhall, D. Dhall, S. Batra, and P. Rani, “Implementation of IPSec protocol,”

Proc. - 2012 2nd Int. Conf. Adv. Comput. Commun. Technol. ACCT 2012, pp.

176–181, 2011.

[24] L. Law and J. Solinas, “Suite B Cryptographic Suites for IPsec Abstract,” 2011.

[25] T. Dierks and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version

1.2 Status,” 2008.

[26] N. Fips, “197: Announcing the advanced encryption standard (AES),” … Technol.

Lab. Natl. Inst. Stand. …, vol. 2009, pp. 8–12, 2001.

[27] J. Daemen and V. Rijmen, The Rijndael Block Cipher: AES Proposal. 2003.

[28] S. Gueron, “Intel’s new AES instructions for enhanced performance and security,”

Lect. Notes Comput. Sci. (including Subser. Lect. Notes Artif. Intell. Lect. Notes

Bioinformatics), vol. 5665 LNCS, pp. 51–66, 2009.

[29] S. Gueron, Intel Advanced Encryption Standard ( AES ) New Instructions Set, no.

September. 2012.

[30] ARM Limited, “ARMv8 Instruction Set Overview,” pp. 1–115, 2013.

106

[31] amd, “AMD64 Technology AMD64 Architecture Programmer ’ s Manual Volume

1 : Application Programming,” vol. 1, no. 24592, 2012.

[32] A. Kuznetsov, Y. Gorbenko, A. Andrushkevych, and I. Belozersev, “Analysis of

block symmetric algorithms from international standard of lightweight

cryptography ISO/IEC 29192-2,” 2017 4th Int. Sci. Conf. Probl.

Infocommunications Sci. Technol. PIC S T 2017 - Proc., vol. 2018–Janua, pp.

203–206, 2018.

[33] S. Moriai, “Japan CRYPTREC Activity on Lightweight Cryptography.”

Cryptography Research and Evaluation Commitees, pp. 1–23, 2015.

[34] L. Bassham and K. Mckay, “Profiles for the Lightweight Cryptography

Standardization Process,” 2017.

[35] “DRAFT Submission Requirements and Evaluation Criteria for the Lightweight

Cryptography Standardization Process.”

[36] A. Bogdanov et al., “PRESENT : An Ultra-Lightweight Block Cipher,” Springer

Berlin Heidelb., pp. 450–466, 2007.

[37] A. Poschmann, “Lightweight cryptography-cryptographic engineering for a

pervasive world,” Electr. Eng., vol. 516, no. February, p. 197, 2009.

[38] R. Kumar, K. K. Mishra, A. Tripathi, A. Tomar, and S. Singh, “MSEA: Modified

Symmetric Encryption Algorithm,” pp. 1–14, 2014.

[39] D. Hong, J. K. Lee, D. C. Kim, D. Kwon, K. H. Ryu, and D. G. Lee, “LEA: A

128-bit block cipher for fast encryption on common processors,” Lect. Notes

Comput. Sci. (including Subser. Lect. Notes Artif. Intell. Lect. Notes

Bioinformatics), vol. 8267 LNCS, pp. 3–27, 2014.

107

[40] “Raspberry Pi 3 Model B - Raspberry Pi.” [Online]. Available:

https://www.raspberrypi.org/products/raspberry-pi-3-model-b/.

[41] J. Vinet and A. Griffin, “Arch Linux,” 2018. [Online]. Available:

https://www.archlinux.org/.

[42] “Massif: a heap profiler.” [Online]. Available: http://valgrind.org/docs/manual/ms-

manual.html.

[43] I. Lee and K. Lee, “The Internet of Things (IoT): Applications, investments, and

challenges for enterprises,” Bus. Horiz., vol. 58, no. 4, pp. 431–440, 2015.

108