FULLTEXT03

Master Thesis
Master’s in Network Forensics, 60hp
Post-Quantum Public Key Cryptography for

the Internet of Things
Digital Forensics, 15 credits
2019-08-26
Olof Magnusson and Mats Hurtig
HALMSTAD
UNIVERSITY
Post-Quantum Public Key
Cryptography for the Internet of
Things
This dissertation is submitted for the degree of Masters

Programme in Network Forensics
Department of Computer Science and Engineering

Halmstad University
Supervisor: Eric Järpe
August 26, 2019

© Olof Magnusson and Mats Hurtig 2019
Department of Computer Science and Engineering
University of Halmstad
ii
Acknowledgement
Looking into the cover of this thesis, there is nothing but two names associated
with it. The research would be harder to complete if we didn’t get valuable input
from numerous of people. We pestered some people, but they were only happy to
help. Thanks to Lidia Gridneva, Robin Kinnunen and Eric Järpe.

University of Halmstad, August 26, 2019
iv
Abstract
Recent progress in the field of quantum computers provide radically

improved muscles to search and sort in lists, solve systems of equations
and prime factorize – virtues that inflict an immediate threat to the most
common systems for public key cryptography used in a vast proportion of
today’s computer networks.
NTRUEncrypt is a lattice-based cryptography system which inhibits
quantum computers for breaking the algorithm in polynomial time. The
cryptographic algorithm is one of the seventeen that passed the first round
in the NIST Post-Quantum standardisation competition which serves an
indication that this system is robust against the efforts from a cryptanalysist
to compromise its security properties.
With the development of a server and client application that is built us-
ing Python3 integrated with WolfSSL, the results obtained from the exper-
iment show that the suggested model acquires the capabilities to overcome
the quantum computers capacities, providing fast quantum-safe asymmetric
encryption algorithm for TLS communication in smart homes. The hand-
shake process with NTRUEncrypt and WolfSSL is proven to be significantly
faster comparing to other algorithms tested.
Keywords: Cryptography, Post-quantum lightweight encryption, NTRU-

Encrypt, WolfSSL, Transport layer security, Application domain, Quantum
computers
Contents
1 Introduction 1
1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Method 5
3 Previous work 7
4 Theory 9
4.1 Transport layer Security . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.1 Confidentiality . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.2 Authentication and handshake . . . . . . . . . . . . . . . . 10
4.1.3 Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.4 WolfSSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2 Lightweight encryption . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.1 Symmetric block ciphers . . . . . . . . . . . . . . . . . . . . 12
4.2.2 Advanced Encryption Standard . . . . . . . . . . . . . . . . 12
4.3 NTRU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3.1 Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3.2 Key generation . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3.3 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3.4 Decryption . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3.5 Security considerations . . . . . . . . . . . . . . . . . . . . . 18
4.4 Internet of Things . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5 Experiment 22
5.1 Experiment set-up . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.1.1 Raspberry Pi . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.1.2 Temperature sensor . . . . . . . . . . . . . . . . . . . . . . 23
5.2 Implementation overview . . . . . . . . . . . . . . . . . . . . . . . . 24
5.3 Attack vectors towards the design . . . . . . . . . . . . . . . . . . . 28
6 Results 30
6.1 Key generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.2 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.3 Decryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
vii
6.4 Practical implementation . . . . . . . . . . . . . . . . . . . . . . . . 39
7 Discussion 42
7.1 Lightweight encryption for IoT . . . . . . . . . . . . . . . . . . . . 42
7.2 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
7.3 Result . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
8 Conclusion 48
viii
List of Figures
1 Illustration of classifications of symmetric and asymmetric crypto-
graphic algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2 Illustration of the sequence of operations for TLS communication
in a client-server model . . . . . . . . . . . . . . . . . . . . . . . . . 10
3 Illustration of how the Message Authentication Code is computed
at sender and verified at receiver . . . . . . . . . . . . . . . . . . . 11
4 Illustration of how the SubBytes step is formed using the bytes
(Ai,j ) and substitute the position in regards to the matrix B in the
non-linear S-box . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5 Illustration of Shif tRows is performed with the bytes cyclically
shift A depending on the offset . . . . . . . . . . . . . . . . . . . . 13
6 Illustration of how the M ixColumns step is performed using the
new value of the column for converting the element in the matrix . 14
7 Illustration of how the AddRoundKey is performed using the round
K to each byte in the state matrix . . . . . . . . . . . . . . . . . . 15
8 Illustration of the design of the network and the cryptographic
structure in the embedded system . . . . . . . . . . . . . . . . . . . 22
9 Illustration of the Raspberry Pi used in the experiment . . . . . . . 23
10 Illustration of the temperature sensor used to record the ambient
temperature connected to the Raspberry Pi . . . . . . . . . . . . . 23
11 Diagram of the used methods within the NTRUEncrypt library . . 25
12 Illustration of the sequence of operations for TLS communication
with the extension of quantum-safe cryptography in a client-server
model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
13 Overview of the security domain for the application . . . . . . . . . 27
14 Illustration of the application implementation with different smart
sensors integrated . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
15 The implementation assumes that the devices itself are trusted and
only the network communication is considered not trusted. . . . . . 28
16 Analog and digital capture of 1-Wire communication between the
IoT-Device and temperature sensor . . . . . . . . . . . . . . . . . . 29
17 Histogram of key generation time series of tested NTRUEncrypt
parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
18 Trend diagram over key generation time in microseconds using dif-
ferent parameters for NTRUEncrypt relative to the server timestamp 32
19 Key generation with time in microseconds for all the NTRUEncrypt
parameters sorted from 112 to 256 bit security level . . . . . . . . . 33
ix
20 Histogram of encryption time series of tested NTRUEncrypt pa-
rameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
21 Trend diagram over encryption time in microseconds using different
parameters for NTRUEncrypt relative to the server timestamp . . . 35
22 Encryption time in microseconds for all the NTRUEncrypt param-
eters sorted from 112 to 256 bit security level . . . . . . . . . . . . 36
23 Histogram of decryption time series of tested NTRUEncrypt pa-
rameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
24 Trend diagram over decryption time in microseconds using different
parameters for NTRUEncrypt relative to the server timestamp . . . 38
25 Decryption time in microseconds for all the NTRUEncrypt param-
eters sorted by security level 112 to 256 bit security level . . . . . . 39
26 Comparison in average time for TLS handshake in milliseconds with
different cipher suites, where dark blue is with QSH enabled . . . . 40
x
List of Tables
1 Table over common network protocols used in smart homes . . . . . 21
2 Table over attributes of the temperature sensor used in the experiment 24
3 Statistical representation over standard deviation, max value, min
value, average and standard error of the tested TLS handshakes on
cipher suites with QSH enabled . . . . . . . . . . . . . . . . . . . . 41
xii
List of Abbreviations
DES Data Encryption Standard

AES Advanced Encryption Standard
MAC Message Authentication Code
SHA Secure Hash Algorithm
GCM Galois/Counter Mode
IV Initialisation Vector
RSA Ron Rivest, Adi Shamir and Leonard Adleman
ABE Attribute-based encryption
IoT Internet of Things
LC Lightweight Cryptography
ECDH Elliptic-curve Diffie–Hellman
ECDSA Elliptic Curve Digital Signature Algorithm
NIST National Institute of Standard and Technologies
ISO International Organization for Standardization
NTRU N-Th Degree Truncated Polynomial Ring Units
BPGM Blinding Polynomial Generation Method
MGF Mask Generation Function
GCD Greatest Common Divisor
TLS Transport Layer Protocol
CA Certificate Authority
1 Introduction
This chapter presents a brief description of the cryptography and its protocols,
internet of things, the problem formulation and its limitations which lay the back-
ground of thesis work.
1.1 Background
For centuries, civil decision makers have relied on the communication for the strate-
gical information exchange between the military lands headquarters and troops.
The problem was if the information occurred in the wrong hands, it could lead to
dangerous consequences. Further the military headquarters initiated to evaluate
techniques that could be used to secure the transmission of the information. A
more refined approach of codemaking were adapted to ensure communication by
implementing the most appropriate possible codes [1]. On the other hand, their
enemies tried revealing the codes to gain advantage in the upcoming battles. The
so called Scytale known as ”code of ancient Sparta” could be considered the first
predecessor of cryptography. This tool was utilized during the war between Sparta
and Athens (431-404 BC) and consisted of a leather strap tightly wrapped around
a rod. The message could be discovered only when the strap was around the rod of
the correct diameter. Without the rod, one can just identify a number of letters.
Aristotle was the person who managed to decipher Scytale, by means of move-
ments of the parchment until the length of the text was readable. The diameter
of the Scytale is therefore known.
In today’s cryptographic systems, the similar methodology is used, but in-
stead of a leather strap wrapped around a stick, complex mathematical problems
are used to reduce the risk of unauthorized individuals being able to decipher
the message. The algorithms are usually categorized into two distinct parts as
symmetric and asymmetric keys encryption. Symmetric keys are algorithms that
deploy the same cryptographic key for both plaintext encryption and deciphering
the ciphertext. A shared secret code is utilized between two or more parties that
may be used to maintain a confidential information exchange [2]. The algorithms
DES, 3DES, Blowfish and AES (Rijndael) are some of the most common systems
based on this methodology. Asymmetric cryptography is based on the assumption
of using a pair keys: a public and a private key. With this consideration, the
algorithms use a different component of the keypair for the encryption, decryp-
tion or signature creation and signature verification. This approach is being used
by the cryptographic systems RSA, El-Gamal and cryptographic systems which
deploy the arithmetics of elliptical curves and finite fields. However, within the
1
Internet of Things (IoT), utilizing of these algorithms is challenging in the view of
the limited computational capacity.
The digitalization with Internet of Things have transformed the way people
and businesses interact with smart devices. Introduced more frequently in areas
of fleet management in transportation, health-care and smart-grids in the energy
sector [3]. IoT-devices is expected to reach 20 billion by 2020. While most of them
are consumer products, a significant amount of them is produced for business usage
[4]. Looking at the mobile industry’s product life-cycle, most devices stop receiving
support after only 3–5 years after release, including security related updates. This
potentially implies a large threat in the future by having a significant amounts of
vulnerable devices active and connected to the internet. It is of great interest to
research how post-quantum lightweight encryption protocol can be useful in the
context of IoT and their cohesion.
1.2 Problem
Industries and authorities view on digital development provides the foundation
for discussing its problems. Based on previous technical developments, there is no
coherent picture of whether lightweight protocols have the capacity for handling the
volume of data distributed in today’s network. Furthermore, the post-quantum
lightweight cryptographic algorithms have only been used for a few years and
many implementations are still in the development phase. There may be unknown
risks in applications that provide a window for potential attack vectors. It is
unclear today whether the lightweight protocols are the best or only a way to
overcome these problems, but they have a great potential for improving the security
properties of constrained devices with requirement of short response times.
The present work will commit to the problem of whether post-quantum light-
weight encryption protocols can be applied as a method for resource constrained
devices in IoT systems. This concerns vulnerabilities in the method and increased
security awareness as well risks taken during the implementation. The reason-
ing regarding the suitability considering the limitations for IoT systems will be
discussed. The work addresses:
• Implementation of technology: Implement a quantum-safe lightweight

encryption for securing the application layer for smart homes
• Analysis of suitability: Reasoning for the suitability of implemented tech-

nology with regards to smart homes.
2
1.3 Limitations
The first part of the work is a brief literature review over the lightweight crypto-
graphic protocols with the purpose to create an overview of the current landscape.
An experiment will be conducted to evaluate the post-quantum safe cryptographic
algorithm NTRUEncrypt with different security parameters in a smart home en-
vironment. Finally the thesis will show a more practical approach for a trusted
end-to-end communication with NTRUEncrypt and WolfSSL aggregated.
3
2 Method
The project begins with creating a review of the lightweight encryption and their
key parameters with a summary of IoT applications and protocols, for a greater
understanding of the landscape [5, 6]. An experiment will be conducted for evalu-
ating a lightweight post-quantum cryptographic protocol taking into consideration
the limitations on the chosen IoT device. The experiment will measure key gen-
eration, encryption and decryption times for different parameters of the NTRU-
Encrypt algorithm. In addition, the work presents a proof of concept combining
NTRUEncrypt and WolfSSL for a trusted end-to-end communication.
The data obtained through the experiment will be analysed and compared
to the available information to find patterns or signs of deviations from the es-
tablished norms. It is essential for the technology development and for a higher
understanding within the subject in association with Blooms taxonomy or ’knowl-
edge pyramid’ [7]. A literature review and analysis combined with an experiment
is chosen to evaluate the results by understanding relations, patterns and princi-
ples. Thus the knowledge acquired in this regard would lead to higher efficiency
and understanding in the fields of lightweight encryption and IoT [8].
There are some limitations to this methodology that need to be taken into
account. One of the problems with all the cryptographic projects are that the
cryptographic protocols are only relevant as long as the algorithms are proven
secure. The post-quantum cryptography competition by NIST is in today’s writing
in round two and the protocols are still in an initial state. The implemented
algorithm in this experiment could have vulnerabilities which have not yet been
discovered. Another problem with this method is that only one protocol will be
implemented in the experimental setup, which makes it possible for this project
to miss several protocols that could perform better. Thus the process of choosing
cryptographic algorithm is relevant and important.
Methods used in previous works can be problematic or even wrong to utilize
on the selected devices in the experiment. With implementing a post-quantum,
cryptographic protocol these methods would additionally allow for incorrect results
interpretation.
What distinguishes this work from previous research is the fact that it is first
conducted with a literature review of the lightweight encryption and its analysis
combined with an summary of IoT applications and protocols. Together with
an experimental implementation of selected protocols, it will prove the model in
function that may not be described in the literature yet. With this in mind,
the paper will reveal a higher understanding of the relationship between IoT and
lightweight encryption.
5
Among other methods like interviews or literature study, a literature review
combined with analysis and an experiment is chosen as more accurate and as it
gives a larger knowledge base. It combines several ways to gather information
and produces new results. Interviews could be useful in this type of project for
gathering the knowledge from the industry of describing which sort of information
the organizations keep in IoT environment and the need for the encryption level
in that area. This was not possible with the given limited time.
6
3 Previous work
The public interest in using the Internet for Things has in turn engaged many
researchers, the security and energy efficiency are facing the major challenges in
IoT. To address this, papers with significant contributions are presented below.
In [9], the authors define lightweight encryption importance in relation to IoT ad-
vancements. IoT devices are used in multitudes of application areas: health-care,
smart home, smart parking and smart grid. Smart applications are only beneficial
to users if the system can protect its security properties from cryptanalysist. Fur-
thermore, it is discussed that the conventional cryptography algorithm RSA is not
adaptable to constrained devices due to the high computation rate requirement.
In the article [10], authors present a secure IoT monitoring framework by intel-
ligent integration of video summary and image encryption. With the development
of a power-efficient system that can perform autonomous enough, it is possible to
collect the important data and take the necessary action accordingly. The exper-
iment demonstrates the framework can reduce bandwidth, storage, transmission
costs and time to analyze substantial amounts of data generated by the sensors.
In [11], a lightweight no-pairing ABE scheme based on elliptical curves encryption
is implemented to address security and privacy issues within IoT. The schedule
is based on ECDH theory instead of Bilinear Diffie-Hellman assumption, provid-
ing the ability to measure overhead and performing detailed analysis. Finally,
it appears that the schedule has a profound impact on the communication cost
and efficiency of a digital system. In [12], the authors have analyzed a different
type of existing protocols that is based on elliptic curve or bilinear pairing. The
new AHA protocol integrated with NTRUEncrypt public key system is introduced
for wireless networks. The result from the experiment shows that NTRUEncrypt
accomplishes the security requirement and imposes less computational time for
generating a public-key pair.
More initial studies [10, 11, 12], demonstrate how lightweight encryption can
be used in different application areas for securing the communication. The surveys
mention different type of attacks that are important to take into consideration.
An article from 2017 [13], investigates the feasibility of implementing the NTRU-
Encrypt protocol in IoT endpoints. The authors implement the protocol on a
device based on 32-bit ARM CortexM0 architecture. The experiment compares
the performance of the algorithm configurations. The results from the experiments
indicate that NTRUEncrypt in fact provides a viable option towards securing IoT
endpoints. Another published article from 2017 describes a small number of vul-
nerabilities in the NTRUEncrypt algorithm [14]. Among them where timing and
cache attacks, however the authors also proposed countermeasures against these
7
attacks without significantly decreasing the performance on certain NTRUEncrypt
parameters.
In the recent years, scientific research has been done on quantum computers
that impose the ability to solve mathematical problems that are difficult to handle
with the conventional data processing [15]. The quantum computer optimizes Big-
O complexity asymptotically, meaning that if there is a quantum speedup for the
particular problem, this will be notified as N . The classical computer is using
O(N√ ) compared to the Grovers algorithm that imposes the ability to solve this
O( N ).
The previous work presents surveys and implementations with different light-
weight encryption protocols, showing different type of integrations with IoT. The
landscape indicates that the algorithms have a high potential, but the deficiency
of works in regards to implementations of quantum-safe lightweight protocols for
smart homes makes this research unique. For those companies that provide services
or products that constantly need to develop modern tools for the digitalization, it
becomes useful to show an overview of the discussed lightweight techniques with
their features. The experiment will prove the model in function to facilitate correct
valuable decisions for an implementation in the future.
8
4 Theory
This section presents theory needed for a greater understanding level of the exper-
imental set-up.
4.1 Transport layer Security

Transport layer Security (TLS) is a vital part in all types of communication in
embedded systems, based on client- server approach for a trusted end-to-end-
communication [16]. TLS operates with the network protocol TCP for a reliable
data transmission between different parties. Considering the ensuring of the au-
thentication, information integrity and confidentiality during the communication,
TLS negotiates the terms of the key exchange and the encryption method. One
particular advantage with TLS is the support for a large amount of cipher suites to
determine encryption, authentication and the key exchange. TLS is constructed
in two distinct parts: symmetrical and asymmetrical encryption algorithms. The
symmetric algorithm is used for the payload as the keys are unique for every
connection based on the secret negotiated with the key exchange algorithm. Con-
sequently the negotiation is about which type of the asymmetrical algorithm to
use for the authentication e.g. RSA, DH, RC4 and NTRU. For ensuring the origi-
nality of the message and its authenticity, TLS are using a function called Message
Authentication Code (MAC). It is critical however that the shared secret is secured
from unauthorized access.
4.1.1 Confidentiality
Communication between two computers achieves confidentiality when the data is
protected from unauthorized access. Two distinct kind of cryptographic algorithms
used in digital systems, symmetric and asymmetric encryption to secure the com-
munication. Symmetric key are algorithms that are using a same cryptographic
key for both plaintext encryption and deciphering the ciphertext. In practice, a
secret is shared between two or more parties to maintain a private information ex-
change [2]. Asymmetric cryptography uses two different keys, one for encryption
(public) and one for decryption (private). Cryptographic systems which deploy the
usage of this arithmetic are RSA and elliptical curve [17], along with the NTRU
algorithm used in this thesis implementation. The particular disadvantage for the
asymmetric encryption occurs in such system where the public key is distributed
over the network and visualised by everyone. This requires larger key sizes to make
the cost of brute-force attacks on the private key not feasible but also increases
the computational cost compared to symmetric key algorithms. The asymmetric
9
algorithms is often only used for the key exchange whereas the symmetric algo-
rithm is implemented for the actual payload. The classifications of the encryption
technologies are shown in Figure 1.
Figure 1: Illustration of classifications of symmetric and asymmetric cryptographic al-

gorithms
4.1.2 Authentication and handshake

Confidentiality is making the trans-
mission secure between two parties
in a digital system, but it is equally
significant to ensure the parties are
communicating with in fact who they
claim to be. Certificates are issued by
a Certificate-Authority (CA), with the
role of a common trust for the parties
involved. Certificates use asymmetric
key cryptography to validate the au-
thenticity by using the known trusted
public-key of the CA. TLS communi-
cation uses certificates for the initial
handshake in the following way:
1. The client transmit a communica-
tion request by issuing ClientHello.
2. The server responds with Server-
Hello and transmit a certificate re-
quest message (CertificateRequest*t).
3. The client verifies with (Certifi-
cateVerify*t) and produces the digi- Figure 2: Illustration of the sequence of op-
tal signature with randomly generated erations for TLS communication in a client-
data issued with the handshake pro- server model
10
cess encrypted with its private key for
the data transmission to the server.
4. The server examines if the certificate is valid with the confirmation that the
public key emerges from the private key to issue the digital signature. Finally, the
TLS communication can be established and illustrated more precisely in Figure
2. The symbols *+ are decisions depending on the agreement of cryptographic
standard and certificate to use between the two parties.
4.1.3 Integrity
To validate the integrity of the data transmitted over the channel, TLS uses Mes-
sage Authentication Code (MAC) for checking the messages and the authentica-
tion, ensuring that the integrity of the information has not been modified under
the transmission. As such, the sender and the receiver are in a need of sharing a
symmetric key K. Figure 3 illustrates this process when the sender is computing
the MAC algorithm encapsulated with the symmetric key, transmitted over the
channel to the receiver. Furthermore, the receiver validates the originality of the
message and inverts the computed function. The authenticity of the data can then
be guaranteed and the information to be trusted.
Figure 3: Illustration of how the Message Authentication Code is computed at sender

and verified at receiver
4.1.4 WolfSSL
WolfSSL is an integrated SSL library designated for embedded, RTOS and re-
source constrained systems, transcribed from ANSI C and commonly applied for
its royalty-free pricing and cross platform support. This includes client and server
SSL/TLS libraries, providing efficient solutions from TLS 1.2 to TLS 1.3. The
11
partnership between WolfSSL and Security innovation provides integration with
NTRUEncrypt and WolfSSL, allowing existing cipher suites to be complied to-
gether [18].
4.2 Lightweight encryption

Lightweight encryption represents a subset in cryptography with the focus on low
resource consumption and complexity. These algorithms are focused primarily on
the cost of the implementation for the encryption algorithm in terms of power
consumption and Gate Equivalent (GE). GE is measuring the complexity for im-
plementing the algorithm in terms of the logical gates in the digital electronic cir-
cuits. Concentrating on the cost will make the algorithm lack in performance and
security [19]. Creating a lightweight encryption algorithm demands that there is
balance between the complexity, GE and power consumption. Furthermore, light-
weight encryption algorithms can be categorized into two specific orientations,
hardware- or software-oriented.
Some operations on a hardware-implemented algorithm can be directly ex-
ecuted, but the similar operations on a software-implemented algorithm may be
significantly slower. The software-oriented protocols are generally targeted to envi-
ronments slightly less constrained and are optimized through measuring the ROM
and RAM footprint. The hardware-oriented ones are optimized through the chip
area and complexity i.e. GE mentioned earlier [20].
4.2.1 Symmetric block ciphers

Block ciphers are the encryption algorithms operating on a determined code (blocks).
This implies if the plaintext is shorter than the block-size, it uses the append
padding to complete the block [21]. The cryptographic protocol built upon this
type of algorithm is AES, which is used in this thesis implementation.
4.2.2 Advanced Encryption Standard

Advanced Encryption Standard (AES) was introduced under a project of US Na-
tional Institute of Standard and Technologies (NIST) in January 1997. The cryp-
tographic system was implemented to facilitate a more secure way for electronic
data transmission compared the previous protocols DES and triple DES (3DES)
[22]. The number of iterations on substitution and permutation depends on the
length of the key. Utilizing the ability of using three different key sizes: 128-bit,
192-bit and 256-bit, the algorithm assigns for the 128-bit encryptions 10 rounds,
for 192-bit - 12 rounds and for 256-bit there are 14 rounds of converting the data
12
into a cipher code. Encryption is performed in 128 bit blocks of the type Rijn-
dael block cipher, wherein the 128 bits are structured as 16 bytes in a 4x4 byte
matrix and for each round the block is processed in four different steps [23]. The
initial phase of the algorithm is to SubstituteBytes, using the bytes (Ai,j ) in the
state array and substitute their position regards to (Bi,j ), in a non-linear S-box
shown in Figure 4. The substitution box deploy 8 bit from the S(Bi,j ), with the
multiplicative inverse in Galois field GF (2)[x]/(x8 + x4 + x3 + x + 1), providing
non-linearity in the cipher.
Figure 4: Illustration of how the SubBytes step is formed using the bytes (Ai,j ) and
substitute the position in regards to the matrix B in the non-linear S-box
However, the second step is the ShiftRows which implies that the bytes cycli-
cally shift depending on the offset. The following algorithm determines that the
first row stays however unchanged, the second row shifts one step, the third row
is shifted two steps and the last - three steps. Thus the important keypoint in
this operation is preventing columns to be encrypted independently as illustrated
in Figure 5.
Figure 5: Illustration of Shif tRows is performed with the bytes cyclically shift A de-
pending on the offset
The third step MixColumns defines the operation where the state columns are
combined with invertible linear transformation, using multiplication with a fixed
13
polynomial c(x) = 3x3 + x2 + x + 2 in the matrix under the following conditions
(0 ≤ j ≤ 3). The values in B are in turn left-multiplied, providing the new values
of the column in the state (1).
     
mixed
M0,j 2 3 1 1 M0,j
     
M mixed  1 2 3 1 M 
 1,j     1,j 
 mixed  =  ×  (1)
M  1 1 2 3 M2,j 
 2,j     
mixed
M3,j 3 1 1 2 M3,j
The arguments in the algorithm are obtaining the four bytes as input and four
bytes as output, where the input bytes have an impact of the output bytes using
XOR operations to produce new columns [24]. Facilitating the new value of the
column can be accomplished by converting the element in the matrix (Ai,j ) ⊕
C(X) ⇒ (Bi,j ) as illustrated in Figure 6. Thus algorithm functions ShiftRows and
MixColumns, together make the diffusion in the cipher.
Figure 6: Illustration of how the M ixColumns step is performed using the new value of
the column for converting the element in the matrix
The last and the most vital step of the algorithm is the operation AddRound-
Key. It is constructed so that each of the subkeys is combined with the state. For
each round a subkey is derived from the main key utilizing Rijndael’s key schedule.
Further the subkey is used combined with either byte of the current state with the
subkey byte using bitwise XOR [24]. This algorithmic process can be illustrated
in Figure 7.
14
Figure 7: Illustration of how the AddRoundKey is performed using the round K to each
byte in the state matrix
4.3 NTRU
NTRU (N-Th Degree Truncated Polynomial Ring) is a Ring-based public key
cryptographic system developed by members from Brown University published in
1998 [25]. The cryptographic algorithm designed to offer the innovative secure
way of implementing the public key infrastructure compared to RSA and ellip-
tic curves. Furthermore, NTRUEncrypt is lattice-based cryptographic algorithm
which inhibits for quantum computers breaking the algorithm in polynomial time.
The cryptographic algorithm is one of the seventeen that passed the first round
in the NIST Post-Quantum standardisation competition which serves an indica-
tion that the system is robust against efforts from cryptanalysist to comprise its
security properties. Further in this section, the algorithmic structure and security
considerations will be presented of the NTRUEncrypt.
15
4.3.1 Algorithm
The fundamental definition for the implementation of NTRUEncrypt is specified
in [25, 13] and described as utilizing truncated polynomial over rings as seen in
(2).
Z[X]
R= (2)
XN − 1
NTRU depends on the parameters of three different integers (N, p, q). N is
representing the prime number in the Ring as possessing the degree N -1 (Non-
secret). The parameters p and q need to be relatively prime in the ring R so
gcd(N, q) = 1 and gcd(p, q) = 1. Note that the parameter q has to be selected to
be the larger modulo number with each coefficient reducing. The p is commonly
set to 3 ternary polynomial, and q is an integer number[ of q = 2k for efficiency
reason. These parameters are the most vital part of the Z X] ring as the truncated
polynomial a and b can explicitly be defined in the R by having integer data type
as in (3-4).
a(x) = a0 + a1 x + a2 x2 + ... + aN −1 xN −1 (3)
b(x) = b0 + b1 x + b2 x2 + ... + bN −1 xN −1 (4)

The circular convolution with multiplication polynomial a by ring element
polynomial b to produce ring element c in (5).
Z/qZ[X]
(5)
XN − 1
This can be defined into the ring R with the different polynomial a and b in
(6-7).
a(x) + b(x) = (a0 + b0 ) + . . . + (aN −1 + bN −1 )xN −1 (6)
a(x) ∗ b(x) = c0 + c1 x + c2 x2 + . . . + cN −1 xN −1 (7)

Where (8) ∑
ck = ai b j (8)
i+j≡k mod N
NTRUEncrypt is using the ternary mathematically function for the algorithmic

process, as the ring element b often described by the product form (b1 ∗ b2 ∗ b3),
where element is a random number with the coefficients {−1, 0, 1}.
16
4.3.2 Key generation
The key-generation algorithm is constructed so that the private key f and the
public key h are accomplished in three steps [13]. The first step generates the
random ternary polynomials F (x) and g(x). Suppose we construct f such as f =
1 + pF , where F is a polynomial coefficient in {−1, 0, 1}. This improves efficiency
in those terms that it is invertible and the TTP does not need to perform that
step of key generation. The inverse of polynomial f (x) (mod q) is computed for
fq (x) as the second step. Public key h(x) is then computed as (9).
h(x) ≡ pfq (x) ∗ g(x) (mod q) (9)
4.3.3 Encryption
The encryption is deployed under the Shortest Vector Encryption Scheme, third
revision (SVES-3), to protect against the Chosen Ciphertexts Attacks (CCA) [26].
This is accomplished in four steps [13]. The message m transmitted, is an en-
coded ternary polynomial m(x) used to transform into a cipher message e. Then
generating a small polynomial called random blinding value t based on Blinding
Polynomial Generation Method (BPGM) in order to provide the plaintext aware-
ness [26]. This method is used to obscure the message in a similar way that El
Gamal uses random binding values for encrypting. The mask is computed in re-
gard to the means of Mask Generation Function (MGF) and t(x) ∗ h(x). Using
XOR operators on m(x) with the mask, creates the m´. The cipher text is then
computed in (10).
e(x) ≡ t(x) ∗ h(x) + m′ (x) (mod q) (10)
4.3.4 Decryption
Deciphering the message e, is accomplished using private polynomial f. The m
is retrieved in three steps [13]. Retrieving m´(x) is accomplished by quantifying
the expressions in (11-12). The second step, the received (t(x) ∗ h(x)) in (13)
is quantified. Finally the last step quantifies the mask using Mask Generation
Function (MGF) and r(x) ∗ h(x). Then m(x) can be retrieved in (14).
a(x) = e(x) ∗ f (x) mod q (11)

m′ (x) = a(x) mod p (12)
t(x) ∗ h(x) = e(x) − m′ (x) mod q (13)
m(x) = m′ (x) − MGF(t(x) ∗ h(x)) mod p (14)
17
4.3.5 Security considerations
A security analysis over the recommended parameters within the NTRUEncrypt
has been specified in [27], describing the underlying problem for the cryptography
system as finding the shortest non-zero vector measured as N , in a given lattice
L (shortest vector problem, SVP) [28]. Finding the non-zero vector V so that
N (V ) = λ(L), generates the desirable output from the algorithm used.
Definition 4.1. Let V 1 , . . . , V n ∈ Rm be linearly independent vectors. Linear

combinations of V 1 , . . . , V n with coefficients in Z constitutes the set L.
L can be regarded as an integer lattice with distance ∥v∥2 , being the Euclidean
distance between the point IV and the origin. Then SVP is, for a given lattice L,
to find the shortest non-zero vector in V∗ ∈ L.
According to the Hermite theorem [29] every n-dimensional lattice L contains

a non-zero vector V ∈ L satisfying the inequality in (15). This theorem shows
the shortest nonzero vector in lattice L with respect to its dimension and the
determinant of the L. The new result for the algorithm will show the upper bound
in terms of dim(L) and det(L) for the shortest nonzero vector in L.
√
∥v∥2 ≤ n det(L1/n ) (15)
Micciancio defined a generalization of cyclic lattices as ideal lattices [30]. These
ideal lattices constitute the basis for quantum computer attack resistant cryptog-
raphy based on the Ring Learning with Errors. NTRUEncrypt is provably secure
under the assumption that the SVP is complicated in these lattices. The lattices
correspond the ideal ones in the ring forming Z[x]/⟨f ⟩ for irreducible polynomial
f of degree N . Suppose we let R be denoted as a ring corresponding to additive
group that is isomorphic to the Zn . This information determines that σ is an
additive isomorphic element mapped to lattices σ(R) in the n-dimensional real
vector space Rn . These provides the ideal lattices of the R under embedding σ
and imposes the set of lattices σ(I) under the consideration that the I is an ideal
one in the R.
In today’s publications, there are not many mentioned attack vectors based
on this type of factorization of ideal lattices. The Grovers’ algorithm finds the
unique
√ input to a blackbox function f (x), that produces an output value using
O( N ) evaluations of the function (N - domain function size) [31]. The solution
of this f (x) = 1, will be a general form of iteration finding the password to f .
Given unsorted database with N entries, means the algorithmic structure needs
a N -dimensional state H supplied by n = log2 N q-bits. Considering f (x) as a
function of the entries either 0 or 1, where f (x) = 1 matches the criterion (x = ω),
18
the quantum black box will have access to a subroutine to forming the unitary Uω
operator shown in (16).
{
Uω |x = −|x for x = ω, that is, f (x) = 1,
(16)
Uω |x = |x ̸ ω, that is, f (x) = 0.
for x =
To get more detailed explanation over the steps in the algorithm, let |s⟩ be
expressed as a quantum uniform superposition in (17).
1 ∑
N −1
|s⟩ = √ |x⟩ (17)
N x=0
Grover diffusion operator can then be defined in (18).
Us = 2 |s⟩ ⟨s| − I (18)

The Grover’s iteration is performed
√ r(N ) times, where the function is asymp-
totically optimized in regard to the ( N ). Operators (Uω , Us ) can then be applied
and measured in (Ω) using the quantum mechanics of Uω and Us . It further results
in eigenvalue λω with the probability approach 1 for N ≫ 1. This implies that ω
may be acquired from λω . The subroutine has been discovered with the asymptotic
speedup providing an solution to the shortest vector problem. However, attacks
towards the algebraic structure have not been successful, despite several studies
[32, 33] reported about the attack attempts. The most present attack vector re-
garding to the NTRUencypt is the hybrid attack, replacing the Grovers’ search
[27]. The authors describe: given a NTRU public key (1,h), with the chosen pa-
rameter set, the information is provided by the basis of lattice L of the rank 2N
by the rows of (19).
[ ]
qIN 0
L= (19)
H IN
The block H, is defined in the circulant matrix, corresponding to h, and the
rows are the coefficients in xi ∗ h ∈ [0, N − 1]. Mapping the (1, h) RN,q ⇒ L/qL,
and transmitting the (a,b) ⇒ [b0 , . . . , bN −1 ], [a0 , . . . , aN ], will represent the additive
group of isomorpism, preserving the norm in (19). This can in turn be rewritten
as in (20).
 
[ ] qlr1 0 0
qIN 0  
= ∗ L1 0 
 (20)
H IN
∗ ∗ lr2
19
L1, can therefore be reduced as shown in (21).
 
qlr1 0 0
 
L1 =  ∗ L1 0   (21)
∗ ∗ lr2
A meet-in-the-middle attack can therefore be performed by guessing a vector v
in L2 (22). Guessing correctly leads to that the vector is close to L1. Finding the
vectors in L1, when L1 is well reduced, resulting in discovering the short elements
of the chosen parameter of NTRUEncrypt [27].
[ ]
L2 = ∗ ∗ lr2 (22)
4.4 Internet of Things

The digitalization with Internet of Things, have transformed the way people and
businesses interact with each other. Introduced more frequently in areas such
as fleet management in transportation, health-care and smart-grids in the energy
sector [3]. The demand for organizations and individuals to connect devices and
streamline their current environment provides space for the Internet of Things
(IoT), introduced by Kevin Ashton, to present concepts of future global networks
with connected objects [34].
The focus of this thesis is on smart homes which recently became of interest
in IoT. The name ’Smart home’ refers to the techniques of incorporating various
networks connected to the electronical appliances that exist at home and allowing
sending sensor data, be controlled, accessed and monitored [35]. Smart home
applications can be subdivided into three groups: first group is ’Comfort’ where the
applications main goals are to automate daily tasks and decrease the burden for the
user. Examples of these applications are Roomba, an automated vacuum cleaner,
Automated indoor temperature controls and Voice-controlled virtual assistants
such as Amazon Alexa and Google Home.
The second group is ’Health’ where the application monitores various aspects
of the user’s health parameters. The sensors can measure heart-rate, sleep activity,
body temperature along with many others and be remotely monitored by a health
care responsible.
The third group is ’Security’ where the appliances’ goal is to increase the phys-
ical home security. Devices like surveillance cameras, smart door locks, pressure
sensors on floors, magnetic contact sensors installed in windows, IR sensors and
alarm sirens. The appliances in this category can be monitored, accessed or con-
20
trolled locally and remotely via Internet, which makes them a part of IoT. One
can subdivide the IoT network into three layers.
Physical layer: is the bottom layer in the OSI model, integrated with actuators
sensors and RFID. The devices can be interconnected with each other and exchange
information to improve the capabilities of IoT. This can be done with identifying
electronic devices and recognize different patterns in the network.
Network layer: provides numerous units in a digital system to be able to ex-
change information. The network can be implemented using Quality of Service
(QoS), control and prioritize the traffic on the network. It is significant for the
dynamic network to be able to automatically identify changes and discover nodes.
Networks in smart homes are both wired and wireless, occasionally with several
protocol being used [36]. The most common protocol is 802.3 Ethernet for wired
networks and for wireless there are 802.11 Wi-Fi, Zigbee, Z-Wave, Bluetooth,
RFID and Radio frequencies of 433 and 868 MHz. Table 1 displays a comparison
of the common network protocols used in smart homes.
Application layer: is the top layer in the OSI-model (Open Systems Intercon-
nection) and is wherein the data is presented and generated for the physical device.
The layer is focusing on process-to-process communication in the network and de-
ploy services as: SMTFP, file transfer, web browsing and network data sharing
[37].
Table 1: Table over common network protocols used in smart homes
Protocol 802.11 Wi-Fi Bluetooth 5.0 Low Zigbee Z-wave

Energy
Frequency 2.4 Ghz & 5GHz 2.4 GHz 2.4GHz sub 1GHz
Average range 35-100 meters 10 meters 75-100 meters 10 meters
Data rate up to 433 Mbps 1 Mbps up to 250 kbps up to 100 kbps
Encryption (available) AES-128 AES-128 AES-128 AES-128
21
5 Experiment
In this chapter, the experiments’ implementation with technical details are pre-
sented.
5.1 Experiment set-up

The idea of this experiment is to simulate client to server communication, following
the designed network structure in Figure 8. In this implementation, a scenario is
conducted when a temperature sensor is connected to the network for reading the
current indoor temperature secured through WolfSSL. The designed system will
use asymmetric algorithm NTRUEncrypt for the key exchange and AES for the
actual payload.
Figure 8: Illustration of the design of the network and the cryptographic structure in
the embedded system
5.1.1 Raspberry Pi
In the experiment, two Raspberry Pi (3 Model B+) will act as a client and a server
respectively. The computer is running a Broadcom BCM2837B0 quad-core A53
(ARMv8) @ 1.4GHz with 1GB of RAM. One of the devices is shown in Figure 9.
22
Figure 9: Illustration of the Raspberry Pi used in the experiment
5.1.2 Temperature sensor

A sensor DS18B20 is used to record ambient temperature. The sensor have three
leads (GND, data and 3v3) and uses the 1-wire communication protocol, one wire
to transmit and receive information. The DS18B20 temperature sensor is shown in
the far-left of Figure 10, wired on a breadboard connected to the client Raspberry
Pi with specifications presented in Table 2.
Figure 10: Illustration of the temperature sensor used to record the ambient temperature
connected to the Raspberry Pi
23
Table 2: Table over attributes of the temperature sensor used in the experiment
Universal binary sensor
Supply voltage 3.0-5.5V DC ±0.8%
Input Unique 1-Wire interface requires only one port pin for communication
Output 3 potential-free outputs
Operating temperature -55+125◦ C
Accuracy ±0.5°C accuracy from -10°C to + 85°C
Programmable Thermometer resolution is programmable from 9 to 12 bits
Convert Converts 12-bit temperature to digital word in 750 ms (max.)
Number of servicing 4
temperature sensors
Measurement range -55◦ C-+126◦ C
5.2 Implementation overview

The integrations to the NTRUEncrypt library are categorized in two different parts
as User space and NTRU API Implementation. These parts can be seen in Figure
11.
User space represents the function used by the developer when integrating with
the library. Instantiate is always called prior to any other calls, this setups the
configured parameter sets while also instantiate the hash functions, entropy, the
generation of the polynomials and modulo convolution.
Generate Key (ntru_crypto_ntru_encrypt_keygen) is called to generate a key-
pair using the given parameter set. While Decrypt payload and Encrypt payload is
used for the decryption and encryption in a buffered manner.
The library also provides calls to export and/or load the public keys in x509
format, this proved to be useful when testing the library by itself between different
systems.
NTRU API Implementation represents the APIs used in the algorithmic pro-
cess. The combined input from entropy and nonce are total of 2(sec_strength_bits)
of randomness to provide quantum resistance, as the hash algorithm and seed
length is set based on security length. (M in_bytes_of _entropy) = ((2 ∗ s) ⇒
sec_strength))\8, ensures that the function remains quantum resistant even if the
24
internal state is leaked prior to a reseed. Instantiation of DRBG is done by using
following function (ntru_crypto_drbg_instantiate), with the given parameter set.
To find out how large buffer needed for the public and private keys, the function
(ntru_crypto_ntru_encrypt_keygen) is utilized, allocating the buffer of the (pub-
lic_key_len) to hold the private key, and a buffer of length (private_key_len).
The ntru_crypto_hmac_create_ctx sets the hash algorithm for the key used to
form the the digest key into the HMAC context as the md is the address for the
digest length. The process is more precisely defined in (23-24).
(( ) ( ))
HMAC(md) = H K ′ ⊕ ipad ∥ data H (K ′ ⊕ opad) ∥ md (23)
{
H (K) K is larger than block size
K′ = (24)
K otherwise
Figure 11: Diagram of the used methods within the NTRUEncrypt library
To generate the key-pair, the public-key length need to be set to the size of the
buffer given the public and private key, by calling the function ntru_crypto_encrypt
_keygen(). To find out how large the buffer for holding the DER-encoding of the
public key, the function is executed
ntru_crypto_ntru_encrypt_publicKey2SubjectP ublicKeyInf o
Sample application purpose is to DER-encode the public inclusion in a certifi-

cate, to create the SubjectKeyInfo field from a public key and to be used to parse
25
the X.509 cerficate. This will be encoded to retrieve the public key for encryption.
However, if the decoded SubjectPublicKeyInfo is succesfull, it will point to the
SubjectPublicKeyInfo field, otherwise NULL if the buffer gets exhausted. When
retrieving the public key from the certificate, it will be used to encrypt AES-128.
This is performed by the previous call ntru_crypto_ntru_encrypt(). The next
step is to uninstantiate the DRBG, to receive the ciphertext to encrypt it. The
same procedure needs to be performed with the encryption and decryption part for
the instantiating process. Presently, when the public-key is created from the cer-
tificate, it will be used to encrypt with AES-128 and to obtain the buffer needed to
store the ciphertext. To uninstantiate the DRBG, the following function is called
rc= ntru_crypto_drbg_uninstantiate(drbg).
NTRUEncrypt for WolfSSL is enabled during compilation of the WolfSSL

library. Using the configure flags –with-ntru –enable-qsh, will enable the usage of
the NTRU cipher suites with the Quantum Safe Handshake.
In order to accomplish this client-
server model, WolfSSL has integration
with NTRUEncrypt for the commu-
nication. In Figure 12 the Quantum
safe handshake algorithm by William
Whyte and Zhenfei Zhang [38] are
shown. The ClientHello message in-
cludes the available cipher suites that
the client can negotiate with the
server. The SerPkReq is used for re-
questing the servers public keys, in-
dicating the number of server public
keys the client wishes to receive. QSH-
SchemeList shows a list of the Qsh-
SchemeIDS for the client, where the
ID specifies a Quantum safe encryp-
tion scheme/parameter set supported
by the client. CliPkList a list of clients
public keys (CPKI) | (CPK2) corre-
sponding to the QSHscheme in QSH- Figure 12: Illustration of the sequence of op-
Scheme | DList. This type of hand- erations for TLS communication with the
shake algorithm provides quantum se- extension of quantum-safe cryptography in
curity and quantum forward secrecy a client-server model
for either part of the negotiation.
26
The client and server application is built with Python3 using TCP connections
and a WolfSSL wrapper for Python. The wrapper uses C Foreign Function Inter-
face (CFFI) to directly call C functions in WolfSSL from Python. Using Python
provided a faster and easier workflow when testing and building the Python appli-
cations. Figure 13, shows the important features used in this implementation as
protocol, algorithm, programming language, platform, architecture and microar-
chitecture.
Figure 13: Overview of the security domain for the application
Further in Figure 14 the implementation overview of the relations of NTRU-

Encrypt, WolfSSL and the TCP socket are illustrated. In this method Application
specific implementation is built upon the SSL client, which is in turn handles the
TCP socket and the TLS implementation using WolfSSL.
27
Figure 14: Illustration of the application implementation with different smart sensors
integrated
5.3 Attack vectors towards the design

Figure 15, shows the assumed trust in the design of the network topology. The
blue frames indicates the trusted domain and the red ones shows the not trusted
domain, thus the implementation assumes that the devices are itself trusted and
only the network is considered not trusted. As specified in [38], the quantum
attacker can discover the classic handshake information, assuming given input of
x. The leftover hash lemma [LHL], ensures if the attacker extract y bits uniformly
distributed, in this case y is asymptotic to the min-entropy of x. Attacker who
acquires the knowledge about the variable x, is having trouble to understand the
variable y. However, this algorithm provides the guarantee that the attack will not
find out the pre-master secret if the server and client both have enough entropy
to preserve the secret.
Figure 15: The implementation assumes that the devices itself are trusted and only the
network communication is considered not trusted.
28
Another attack vector that is easily overlooked is hardware security: it might be
possible to capture the information before the encryption occurs. Figure 16 shows
the actual DS18B20 temperature sensor reading, captured by a logic analyzer
connected to the 1-wire bus between the client RPI1 and the temperature sensor
chip.
Figure 16: Analog and digital capture of 1-Wire communication between the IoT-Device
and temperature sensor
29
6 Results
The performance evaluation of modified algorithms that use NTRUEncrypt is
shown in this section with a Raspberry Pi. The evaluation presents the time for
key generation, encryption and decryption parameter list for the NTRUEncrypt
library measured in microseconds. To indicate stability under equal conditions,
the tests are performed 10,000 times for each algorithm setting to find the true
distribution.
6.1 Key generation

Figure 17, demonstrates the average key generation time for the Raspberry Pi
using open-source metrics dashboard Grafana, where the x-axis shows the times-
tamp for generating key in regards to the parameter sets on NTRUEncrypt. A
representation of averages relative to a server timestamp is given in Figure 19.
Illustrating how long it takes for the Raspberry Pi for generating the keys for
different strength settings (bits), where the parameter ees401ep2 has the shortest
time and ees1499ep1 the longest time. When comparing key generation samples
with regards to their security bits as in Figure 18, starting with 112 bits of se-
curity, ees401ep2 is the fastest and ees659ep1 is the slowest one. Parameter sets
ees439ep1 and ees443ep1 are both similar and has the fastest times of 128 bits
security. Ees761ep1 is approximately three times slower than the fastest param-
eters of 128 bit security. Looking into 192 bit security, ees593ep1 and ees587ep1
parameters have both key generation times of 6917 and 6702 µs, while ees1087ep1
is more than three times slower with 25901 µs. For the strongest security param-
eters 256 bit, ees743ep1 is the fastest one with 10510 µs and the slowest overall
ees1499ep1 with 46735 µs.
30
Figure 17: Histogram of key generation time series of tested NTRUEncrypt parameters
31
Time [µs]
0
0.5
1
1.5
2
2.5
3
3.5
4
4.5
5
ee
s4
0
·104
ee 1ep
s4 1
0
ee 1ep
s5 2
4
ee 1ep
RPI
s6 1
Server
5
ee 9ep
s4 1
3
ee 9ep
s4 1
4
ee 3ep
s4 1
4
ee 9ep
s6 1
1
ee 3ep
s7 1
6
32
ee 1ep
s5 1
8
ee 7ep
s5 1
9
ee 3ep
s6 1
7
ee 7ep
s8 1
ee 87e
s1 p1
08
NTRUEncrypt parameters
parameters for NTRUEncrypt relative to the server timestamp

ee 7ep
s7 1
ee 43e
s1 p1
0
ee 87e
s1 p2
1
ee 71e
s1 p1
49
9e
p1
Figure 18: Trend diagram over key generation time in microseconds using different
·104
5
4.5
112 bit 128 bit 192 bit 256 bit

3.5
3
Time [µs]
2.5
1.5
0.5
0
1
1
2
s6 1
s6 1
s5 1
1
s1 p1
1
s1 p1
s1 p2
s1 p1
p1
ee 9ep
ee 3ep
ee 3ep
ee 1ep
ee 1ep
ee 1ep
ee 9ep
ee 3ep
ee 9ep
ee 1ep
ee 7ep
ee 7ep
ee 7ep
ee 87e
ee 43e
ee 87e
ee 71e
9e
5
9
0
08
49
s4
s4
s5
s4
s4
s4
s7
s5
s6
s8
s7
1
ee
Figure 19: Key generation with time in microseconds for all the NTRUEncrypt param-
eters sorted from 112 to 256 bit security level
6.2 Encryption
Figure 20, shows the average encryption time for the Raspberry Pi, using open-
source metrics dashboard Grafana, where the x-axis shows the timestamp for en-
cryption in regards to the parameter sets on NTRUEncrypt. A representation
of averages can be shown in Figure 21, relative to the server timestamp. This
shows how long it takes for the Raspberry Pi to encrypt in regards to different
strength settings (bits), where the ees401ep2 parameter had the shortest time and
ees1499ep1 the longest time. When comparing the encryption samples to the se-
curity bits again in Figure 22, the fastest parameters of the key generation are in
33
addition the fastest when it comes to encryption. Interestingly, 112 bits ees401ep1
parameter is the slowest when encrypting but it were second fastest when generat-
ing keys. Ees449ep1 parameter were the second fastest when generating keys out
of the parameters with 128 bit but is the slowest when it comes to encryption. The
similar trend is observed for ees677ep1 and ees1087ep2 parameters which are both
the second fastest in the key generation but slowest when it came to decryption
for 128 bit and 192 bit, respectively.
Figure 20: Histogram of encryption time series of tested NTRUEncrypt parameters
34
1,600
RPI
Server
1,400
1,200
1,000
Time [µs]
800
600
400
200
0
1
1
1
s6 1
s6 1
s5 1
1
s1 p1
1
s1 p1
s1 p2
s1 p1
p1
ee 9ep
ee 3ep
ee 3ep
ee 1ep
ee 1ep
ee 1ep
ee 9ep
ee 3ep
ee 9ep
ee 1ep
ee 7ep
ee 7ep
ee 7ep
ee 87e
ee 43e
ee 87e
ee 71e
9e
5
9
0
08
49
s4
s4
s5
s4
s4
s4
s7
s5
s6
s8
s7
1
ee
Figure 21: Trend diagram over encryption time in microseconds using different param-
eters for NTRUEncrypt relative to the server timestamp
35
1,600
1,400
1,200
1,000 112 bit 128 bit 192 bit 256 bit

Time [µs]
800
600
400
200
0
1
1
2
s6 1
s6 1
s5 1
1
s1 p1
1
s1 p1
s1 p2
s1 p1
p1
ee 9ep
ee 3ep
ee 3ep
ee 1ep
ee 1ep
ee 1ep
ee 9ep
ee 3ep
ee 9ep
ee 1ep
ee 7ep
ee 7ep
ee 7ep
ee 87e
ee 43e
ee 87e
ee 71e
9e
5
9
0
08
49
s4
s4
s5
s4
s4
s4
s7
s5
s6
s8
s7
1
ee
Figure 22: Encryption time in microseconds for all the NTRUEncrypt parameters sorted
from 112 to 256 bit security level
6.3 Decryption
Figure 23, shows the average decryption time for the device Raspberry Pi using
open-source metrics Grafana. The x-axis shows the timestamp for decryption in
regards to the parameter sets on NTRUEncrypt. A representation of averages can
be seen in Figure 24, relative to the server timestamp. This shows how long it
takes for the Raspberry Pi to decrypt in regards to different strength settings (bits),
where the parameter ees401ep2 had the shortest time and ees1499ep1 the longest
time. When comparing decryption samples based on security bits in Figure 25,
it is possible to observe the similarities between encryption and decryption times.
However, the times are overall slower for decryption compared to encryption.
36
Figure 23: Histogram of decryption time series of tested NTRUEncrypt parameters
37
RPI
2,500 Server
2,000
Time [µs]
1,500
1,000
500
0
1
1
1
s6 1
s6 1
s5 1
1
s1 p1
1
s1 p1
s1 p2
s1 p1
p1
ee 9ep
ee 3ep
ee 3ep
ee 1ep
ee 1ep
ee 1ep
ee 9ep
ee 3ep
ee 9ep
ee 1ep
ee 7ep
ee 7ep
ee 7ep
ee 87e
ee 43e
ee 87e
ee 71e
9e
5
9
0
08
49
s4
s4
s5
s4
s4
s4
s7
s5
s6
s8
s7
1
ee
Figure 24: Trend diagram over decryption time in microseconds using different param-
eters for NTRUEncrypt relative to the server timestamp
Comparing at the three parts: key generation, encryption and decryption com-
bined, there is for each level of security, a clear best performer. For 112 bit, the best
performer is ees401ep2, which is the quickest in all three parts. At 128 bit there
are two that perform similarly ees439ep1 and ees443ep1. The 192 bit parameters
ees593ep1 and ees587ep1 performed best in the same security bit strength. For
256 bit, the best performer is ees743ep1. The conclusion from the test is that the
NTRUEncrypt performed well with high speed overall under the key generation,
encryption and decryption phases.
38
2,500
2,000
112 bit 128 bit 192 bit 256 bit

Time [µs]
1,500
1,000
500
0
1
1
2
s6 1
s6 1
s5 1
1
s1 p1
1
s1 p1
s1 p2
s1 p1
p1
ee 9ep
ee 3ep
ee 3ep
ee 1ep
ee 1ep
ee 1ep
ee 9ep
ee 3ep
ee 9ep
ee 1ep
ee 7ep
ee 7ep
ee 7ep
ee 87e
ee 43e
ee 87e
ee 71e
9e
5
9
40
08
49
s4
s5
s4
s4
s4
s7
s5
s6
s8
s7
1
s
ee
Figure 25: Decryption time in microseconds for all the NTRUEncrypt parameters sorted
by security level 112 to 256 bit security level
6.4 Practical implementation

From the performance evaluation it has been shown that ees743ep1 parameter is
the fastest algorithm for the key generation process and provides adequate security,
thus used in the practical implementation. The software TCPdump was used to
capture the traffic between the client and server, measuring the average timings
of the entire TLS handshake on 1000 iterations. The time of the quantum safe
handshakes could be measured and compared with other cipher suite standards
seen in Figure 26, where the dark blue indicates with QSH enabled. The parameter
set NTRU743ep1-AES128-SHA-256, had the best time, as the handshake took
0,139 seconds to perform between the client and the server on average. Comparing
39
without QSH, the difference was not significant as the overhead of the extension
introduced only 4 milliseconds to the regular TLS handshake. The result shows
that the handshake with NTRUEncrypt is under 0.5 seconds and gives indicators
that it can be used in real environments for embedded devices.
136.56
A 138.92
284.5
B 286.59
Cipher suites
285.32
C 287.65
284.86
D 287.32
284.44
E 286.91
0 50 100 150 200 250 300

Averagetime [ms]
#A NTRU743ep1-AES128-SHA-256
#B ECDHE-RSA-CHACHA20-POLY1305
#C ECDHE-RSA-AES256-SHA-384
#D ECDHE-RSA-AES256-GCM-SHA-384
#E ECDHE-RSA-AES128-GCM-SHA-256
Figure 26: Comparison in average time for TLS handshake in milliseconds with different
cipher suites, where dark blue is with QSH enabled
The statistical test with N = 1000 handshake iterations for each cipher suite,
gives more accurate prediction of the samples in the observations. Table 3 presents
the standard deviation, max value, min value, average and standard error (stdp)
of the tested cipher suites with QSH enabled. The standard error test from the
1000 iterations, is proven to be relatively low and provides the knowledge that the
data is less spread in the sampling distribution.
40
Table 3: Statistical representation over standard deviation, max value, min value, aver-
age and standard error of the tested TLS handshakes on cipher suites with QSH enabled
NTRU743ep1-AES128 ECDHE-RSA-CHACHA20 ECDHE-RSA-AES256 ECDHE-RSA-AES256 ECDHE-RSA-AES128

Cipher suites
-SHA-256 -POLY1305 -SHA-384 -GCM-SHA-384 -GCM-SHA-256
Stdev 4.437595429 3.547883199 3.400296921 3.282896897 3.077426057
Max 155.72 340.265 301.975 301.55 301.429
Min 133.02 275.786 278.984 278.419 276.182
Avg 138.921805 286.58901 287.653314 287.321713 286.905863
Stdp 0.1403290889 0.1121939178 0.1075268299 0.1038143152 0.09731675669
The estimated parameter of the standard

√deviation and its sampling distribu-
tion used to determine the Standard Error V (x).
41
7 Discussion
In this chapter, a discussion and analysis are presented based on reported literature
and results.
7.1 Lightweight encryption for IoT

The current public-key infrastructure used in today’s system such as RSA and
Diffie-Hellman are doomed when the era of quantum computers begins. Looking
into the growing number of attacks against the cryptographic system, RSA, indi-
cates that there is a need for moving away from its monarchy [39, 40, 41]. Moving
to ECC entirely, is not the optimal choice, since it is commonly known that a quan-
tum computer have the possibility to solve the discrete logarithm problem. The
question of what to do next, is to find a combination of a future proof algorithm
for the key exchange and run another fast algorithm in parallel.
The problem occurring with the quantum computers in relation to cryptog-
raphy is the asymptotic computational complexity with Grover’s search, solving
of equation system and prime factorize. This problem requires a solution when
quantum computers are getting more developed and only a few years from becom-
ing a global phenomenon. The parameter that limits the quantum computer is
the amount of q-bits the quantum computer can keep entangled long enough for
performing the calculations.
Necessity for more robust and secure systems to handle this development has
already been announced. The National Institute of Standards and Technology, has
subsequently put forward recommendations for the size of keys and even the basic
algorithms. However, the algorithm implemented in this thesis is a competitive
candidate in NIST’s project of Post Quantum Cryptography Standardization. The
algorithm is standardised under the IEEE (1363.1-2008) and X9 standard (X9.98)
for securing communications in financial service systems. Releasing the algorithm
in the open-source format, resulted in that the algorithm not only has been tested
by the community and is during the time of writing became an active candidate in
the second round of the NIST competition. The standard is anticipated to be set
between 2022 and 2024 which reveals more research has to be done in that area of
cryptography with testing and evaluating.
NTRUEncrypt small code size with 4500 lines of compiled machine code, pro-
vides small public key and cipher texts compared to other lattice models such as
New hope and CRYSTALS [42, 43]. The differentiation between NTRUEncrypt
and the other candidates is the Maximum Transmission Unit. The handshake pay-
load in often one single Maximum Transmission Unit (1.5kB), preventing packet
42
loss. NTRUEncrypt is the only model that fits this requirements under 1kB to
reduce network delay, as the 0.5kB is used for the hello message.
The application areas as manufacturing, healthcare, Internet of Things, Near
field communication (NFC) and Vehicle Communications (V2V) could have ben-
eficial advantage of NTRUEncrypt. The algorithms used in today’s landscape are
slow as RSA, especially with key generations for acceptable security standard. If
the key size expands in regards to the factor N, RSA decreases of the size N 3,
where NTRUEncrypt has the ability to decrease at N 2. RSA labs chief scientist
Ari Juels, stated 2011 that NTRU is considerably faster than RSA [44]. The result
has been shown in [45], with a comparison of advantages and disadvantages in re-
gards to NTRUEncrypt and RSA in the practical use. The time for key generation
was 200x faster and the time for encryption, decryption 3x and 30x times faster
respectively. The latest succesfull attempt for factorization of RSA (768 bits keys)
was made in 2009 [46]. One of the most sufficient keys recommendations given by
NIST occurred to be 2048 which even should be valid until 2030 [47]. Compared to
NTRUEncrypt where all the arithmetic is done in small numbers and low memory
usage, the high speed provides big advantage compared to the ordinary encryption
systems.
Looking at the industry’s product life-cycle, devices stop receiving support af-
ter only 3-5 years after release, including security related updates. This potentially
implies a large threat in the future by keeping significant amounts of vulnerable
devices active and connected to the internet. For business models, implementing
security features on IoT devices there is a challenge in several ways. The leading
factor is the initial cost with the development of the products, regarding the con-
straints of processing power and memory for the device [48]. To overcome these
constraints and maximise the profit, manufacturers may not choose to invest in
implementing security features. This work is addressing this problem, showing a
new application area of implementing a cryptographic algorithm that has a future
in the long term, when the quantum computers are more developed for solving
complex mathematical problems. The chosen protocol NTRUEncrypt, is safe as
long as the shortest vector problem has not been solved.
7.2 Method
The literature review was based on the work that dealt with quantum-safe light-
weight encryption for smart home in particular, which provides the knowledge of
the techniques for the smart-home context. This approach of the work remains a
good choice as the paper focuses on an implementation, rather than just research
about how the technology works theoretically. Furthermore, it is possible to obtain
relevant theoretical information about lightweight encryption with help of a survey
43
regarding throughput, transparency and other properties. With an experiment, it
gives a more practical understanding about the cryptographic algorithm with its
advantages and disadvantages. Documentation for the implementation has been
received from the official NTRUEncrypt and WolfSSL and together with an ap-
plication domain the experiment could be proved to be practicable. The strength
and weakness of the chosen method in relation to the purpose are shown on the
example of the smart home and IoT concept, illustrating how the NTRUEncrypt,
WolfSSL operate simultaneously and providing stability of the algorithm under
controlled equal conditions. The weakness is the scope of the cryptography land-
scape, there are many variables to take into considerations when implementing an
algorithm for critical applications. If there should be more time available, this
thesis would also more particularly investigate the algorithm settings on NTRU-
Encrypt in a greater scale and normalise the result. However, this work shows an
application area in the context of smart homes, how to potentially implement the
algorithm for securing the application layer in embedded systems.
7.3 Result
The experiment shows the performance evaluation of the NTRUEncrypt: key gen-
eration, encryption and decryption with various parameters of the algorithm ob-
tained with the RP3. The data analysis of the parameters using open source met-
rics dashboard Grafana presents how consistent the algorithm was during these
tests. One of the conclusions that rises from the tests is that there is a possibility
for the developer to chose different variants for implementation to make the en-
cryption suitable with different products in a network. This leads to the decision
on which parameter to recommend in a embedded system. Starting with 128-
bits security the ees443ep1 parameter is the most promising one, the ees443ep1
parameter is using the hash function SHA-256 compared to ees433ep1 parameter
which is using SHA-1. For 192-bits, the ees587ep1 parameter, and the ees743ep1
parameter can be used with high confidence with 256-bits security. The reasoning
behind this argument is the security as good as its speed and providing enough
entropy and minimize the risk of decryption failure.
Comparing the evaluation result for the different parameters with [13], the
result from the NTRUEncrypt library is similar. However, there are some key
differences: the authors perform their tests on an ARM Cortex M0 microprocessor
while this work focuses on ARM Cortex v8. The device is more constrained but
not as commonly used in smart homes as ARMv8.
The implementation presents a quantum-safe lightweight encryption algorithm
for securing the application layer in smart homes. This implementation, provides
less computation time and another level of security for transmitting the data. With
44
the developments of an application domain, this client and server model with ci-
pher suite NTRU743ep1-AES128-SHA-256 provides a faster handshake compared
to the other algorithms tested. The given implementation increased the level of se-
curity for the handshake process using quantum-safe forward secrecy and security.
The solution presented in this thesis, gives good guidelines on how to use NTRU-
Encrypt with WolfSSL in the future, securing information in small embedded
systems. The use-case scenarios for this model are water quality reader, temper-
ature sensor, humidity sensor and IP-camera, regular products that are used for
home automation. Moreover, critical sensors as measuring heart-rate, sleep activ-
ity and body temperature should also benefit from this technology, both in terms
of security and performance. The increasing health care possibilities that elderly
and disabled people can be monitored by numerous of devices, makes it critical to
maintain the integrity and confidentiality of information to ensuring the patient
health. It is important that the information sent between the patient and health
care company is not blocked, stolen or to say the least manipulated. In smart
homes, there is a general problem because the encryption algorithm available is
computationally intensive and likely not used. The problem has been around for a
long time and it is necessary to think of smart homes in a larger perspective. The
abstract interpretation which this method implements, using the client-to-server
model, provides the ability to secure fast information exchange between the smart
homes and intuitions in the future.
It is harder to compare the result with our tested cipher suite NTRU743ep1-
AES128-SHA-256, since it have not been tested before. Comparing with [49], it
shows however that NTRUEncrypt is significantly faster compared to the authors
result since it took 4.5-20 seconds for the initial handshaking process. Even though
the authors performed the tests on Raspberry Pi 2, it is still possible to draw
the conclusions however that NTRUEncrypt perform better than the standards
available in terms of the handshake.
Speed records with NTRUEncrypt [50], shows that AES is approximately 20
times faster than a NTRUEncrypt implementation. The result has demonstrated
it in regards to the encryption and decryption time of this experiment. This means
that replacing RSA with NTRUEncrypt completely is not the optimal solution.
Using only one algorithm for the whole system is not either the solution, in the
case that it can introduce potential attack windows using the same arithmetic for
the entire cryptographic system. Using two fast encryption algorithms combined,
could be the solution as in the case of NTRUEncrypt.
Compared to different cryptographic systems, NTRUEncrypt is characterized
by a flexibility imposing requirements on the coefficients f, g, t, m and release the
requirements q > p(6N + 1), and reduce q considerably. With this tradeoff on the
value q, it is important to discuss the opportunities with larger value of q, where
45
there is a higher chance for successfully encrypting the ciphertext. With decreasing
the value on q, there is a higher chance for a decryption failure. An attacker can
in this particular case, learn these decryption failures and discover information.
The possibility of choosing q is important for a security level of N bits, achieving
a decryption failure of (2−N ). The findings in [27], show however that the Hybrid
attack needs 2(272) operations to the NTRU743 parameter set. Motivations behind
the certain choices of parameter settings and handshaking steps is the fact that it
provides protection against a certain type of vulnerability that otherwise could be
exploited.
The various algorithmic settings of the NTRUEncrypt rely on many variables
such as hash function and key sizes to be properly assigned for quantum-search
based speedups. The parameter set of ees401ep2, ees439ep1 utilizes the hash
algorithm SHA-1 and provides opportunities for an attack via Grover’s algorithm.
This could be replaced with a higher security as SHA-256. However, this will
decrease the speed of the particular algorithm. The NTRUEncrypt parameter that
has the best characteristics in this thesis is the NTRU743ep1 for the Raspberry
Pi. The parameter kept consistent good performance in the conducted tests and
became the optimal choice for the implementation.
46
8 Conclusion
The cryptodesign implemented in this thesis represents the client-to-server com-
munication, where the NTRUEncrypt is used as the key exchange algorithm. The
actual payload from the various of sensors could then be encrypted by using AES,
because the known fact that AES has been proven 20 times faster data encryption
time than NTRUEncrypt. The result shows that it is possible to implement a
quantum-safe lightweight encryption algorithm for securing the application layer
for smart homes, where in this case the handshake information between the client
and server could not be eavesdropped by a malicious actor. The additional exten-
sion QSH, provides quantum security and quantum forward secrecy with minimal
overhead. With the developments of an application domain, the client and server
communication is built upon Python3 using TCP connections and a WolfSSL
wrapper for Python. The result from the suggested model provides a faster way
comparing to the ordinary encryption options that the market is referred to, and
at the same time provides increased security for the embedded systems with the
help of a quantum safe algorithm for the digital information exchange. The un-
derlying architecture of the design, gives the information however the components
do not give any form of obstacle, but provides a possibility to scale up and use
more smart interactions.
Together with the performance evaluation of different algorithmic settings on
NTRUEncrypt regarding key generation, encryption and decryption, the method
shows durability for the device to produce the operations on a consistent level and
gives a visual representation of the suitability for the algorithm for the embedded
devices. Finally, it is shown that post-quantum lightweight encryption can be
viewed as a new approach to secure the information transfer in a smart home in
the future.
It is suggested for future work and research to test the practical model in more
constrained environments, with more diverse measurements and develop general
methods for managing Internet of Things. It is also of interest to test the model
in other application areas as NFC, V2V and Manufacturing.
48
References
[1] S. Pincock, Codebreaker: The History of Codes and Ciphers. Walker, 1 ed.,
2016. isbn: 978-0802715470.
[2] D. S. A. Elminaam, H. M. Abdual-Kader, and M. M. Hadhoud, “Evaluating

the performance of symmetric encryption algorithms.,” IJ Network Security,
vol. 10, no. 3, pp. 216–222, 2010.
[3] R. Mahmoud, T. Yousuf, F. Aloul, and I. Zualkernan, “Internet of things

(iot) security: Current status, challenges and prospective measures,” in 2015
10th International Conference for Internet Technology and Secured
Transactions (ICITST), pp. 336–341, IEEE, 2015.
[4] B. Stiller, T. Bocek, F. Hecht, G. Machado, P. Racz, and M. Waldburger,

“Gartner Says 8.4 Billion Connected ”Things” Will Be in Use in 2017, Up 31
Percent From 2016,” tech. rep., Gartner, 02 2017.
[5] J. Backman, Rapporter och uppsatser. Studentlitteratur AB, 3 ed., 2016.

isbn: 9789144097329.
[6] Y. Backman, T. Gardelli, V. Gardelli, and A. Persson, Vetenskapliga

tankeverktyg: till grund för akademiska studier. Studentlitteratur AB, 1 ed.,
2012. isbn: 9789144074702.
[7] B. S. Bloom and D. R. Krathwohl, Taxonomy of educational objectives. D.

McKay, New York, 1956.
[8] R. L. Ackoff, “From data to wisdom,” Journal of Applied Systems Analysis,

vol. 16, pp. 3–9, 1989.
[9] E. R. Naru, H. Saini, and M. Sharma, “A recent review on lightweight

cryptography in iot,” in I-SMAC (IoT in Social, Mobile, Analytics and
Cloud)(I-SMAC), 2017 International Conference on, pp. 887–890, IEEE,
2017.
[10] K. Muhammad, R. Hamza, J. Ahmad, J. Lloret, H. H. G. Wang, and S. W.

Baik, “Secure surveillance framework for iot systems using probabilistic
image encryption,” IEEE Transactions on Industrial Informatics, 2018.
[11] X. Yao, Z. Chen, and Y. Tian, “A lightweight attribute-based encryption

scheme for the internet of things,” Future Generation Computer Systems,
vol. 49, pp. 104–112, 2015.
49
[12] R. Chen and D. Peng, “A novel ntru-based handover authentication scheme
for wireless networks,” IEEE Communications Letters, vol. 22, no. 3,
pp. 586–589, 2018.
[13] O. M. Guillen, T. Pöppelmann, J. M. B. Mera, E. F. Bongenaar, G. Sigl,
and J. Sepulveda, “Towards post-quantum security for iot endpoints with
ntru,” in Proceedings of the Conference on Design, Automation & Test in
Europe, DATE ’17, (3001 Leuven, Belgium, Belgium), pp. 698–703,
European Design and Automation Association, 2017.
[14] J. Sepulveda, A. Zankl, and O. Mischke, “Cache attacks and
countermeasures for ntruencrypt on mpsocs: Post-quantum resistance for
the iot,” in 2017 30th IEEE International System-on-Chip Conference
(SOCC), pp. 120–125, Sep. 2017.
[15] L. Chen, S. Jordan, Y.-K. Liu, D. Moody, R. Peralta, R. Perlner, and
D. Smith-Tone, “Report on post-quantum cryptography,” tech. rep., US
Department of Commerce, National Institute of Standards and Technology,
2016.
[16] T. Dierks and E. Rescorla, “The transport layer security (tls) protocol
version 1.2,” tech. rep., 2008.
[17] M. G. Zapata, “Secure ad hoc on-demand distance vector routing,” ACM
SIGMOBILE Mobile Computing and Communications Review, vol. 6, no. 3,
pp. 106–107, 2002.
[18] wolfSSL Inc, “wolfssl.” https://github.com/wolfSSL/wolfssl, 2019.
[19] T. Eisenbarth, S. Kumar, C. Paar, A. Poschmann, and L. Uhsadel, “A
survey of lightweight-cryptography implementations,” IEEE Design Test of
Computers, vol. 24, no. 6, pp. 522–533, 2007.
[20] G. Hatzivasilis, K. Fysarakis, I. Papaefstathiou, and C. Manifavas, “A
review of lightweight block ciphers,” Journal of Cryptographic Engineering,
vol. 8, no. 2, pp. 141–184, 2018.
[21] J. Hoffstein, J. C. Pipher, J. H. Silverman, and J. H. Silverman, An
introduction to mathematical cryptography, vol. 1. Springer, 2008.
[22] J. Daemen and V. Rijmen, The design of Rijndael: AES-the advanced
encryption standard. 2013.
[23] A. M. Abdullah, “Advanced encryption standard (aes) algorithm to encrypt
and decrypt data,” Cryptography and Network Security, 2017.
50
[24] C. Paar and J. Pelzl, Understanding cryptography: a textbook for students
and practitioners. Springer Science & Business Media, 2009.
[25] J. Hoffstein, J. Pipher, and J. H. Silverman, “International algorithmic
number theory symposium,” pp. 267–288, Springer, 1998.
[26] W. Whyte, “Implementation aspects of ntruencrypt version 3.1”, consortium
for efficient embedded security,” tech. rep., Securityinnovation, 2015.
[27] J. Hoffstein, J. Pipher, J. M. Schanck, J. H. Silverman, W. Whyte, and
Z. Zhang, “Choosing parameters for ntruencrypt,” in Cryptographers’ Track
at the RSA Conference, pp. 3–18, Springer, 2017.
[28] O. Regev, “Lattice-based cryptography,” in Annual International Cryptology
Conference, pp. 131–141, Springer, 2006.
[29] D. J. Bernstein, C. Chuengsatiansup, T. Lange, and C. van Vredendaal,
“Ntru prime: reducing attack surface at low cost,” in International
Conference on Selected Areas in Cryptography, pp. 235–260, Springer, 2017.
[30] D. Micciancio, “Lattice-based cryptography,” Encyclopedia of Cryptography
and Security, pp. 713–715, 2011.
[31] P. Kwiat, J. Mitchell, P. Schwindt, and A. White, “Grover’s search
algorithm: an optical approach,” Journal of Modern Optics, vol. 47, no. 2-3,
pp. 257–266, 2000.
[32] S. R. Fluhrer, “Quantum cryptanalysis of ntru.,” IACR Cryptology ePrint
Archive, vol. 2015, p. 676, 2015.
[33] H. Wang, Z. Ma, and C. Ma, “An efficient quantum meet-in-the-middle
attack against ntru-2005,” Chinese Science Bulletin, vol. 58, no. 28-29,
pp. 3514–3518, 2013.
[34] K. Ashton et al., “That ‘internet of things’ thing,” RFID journal, vol. 22,
no. 7, pp. 97–114, 2009.
[35] M. R. Alam, M. B. I. Reaz, and M. A. M. Ali, “A review of smart
homes—past, present, and future,” IEEE Transactions on Systems, Man,
and Cybernetics, Part C (Applications and Reviews), vol. 42, pp. 1190–1203,
Nov 2012.
[36] M. Kuzlu, M. Pipattanasomporn, and S. Rahman, “Review of
communication technologies for smart homes/building applications,” in 2015
IEEE Innovative Smart Grid Technologies - Asia (ISGT ASIA), pp. 1–6,
Nov 2015.
51
[37] V. Karagiannis, P. Chatzimisios, F. Vazquez-Gallego, and J. Alonso-Zarate,
“A survey on application layer protocols for the internet of things,”
Transaction on IoT and Cloud computing, vol. 3, no. 1, pp. 11–17, 2015.
[38] W. Whyte and Z. Zhang, “Quantum cryptanalysis, quantum-safe algorithms

based on hard problems over lattices, and how we get there from here,”
Quantum-Safe-Security-Innovation, 2016.
[39] A. C. Aldaya, C. P. García, L. M. A. Tapia, and B. B. Brumley,

“Cache-timing attacks on rsa key generation.,” IACR Cryptology ePrint
Archive, vol. 2018, p. 367, 2018.
[40] M. Zheng, N. Kunihiro, and H. Hu, “Cryptanalysis of rsa variants with

modified euler quotient,” in International Conference on Cryptology in
Africa, pp. 266–281, Springer, 2018.
[41] C. Luo, Y. Fei, and D. Kaeli, “Gpu acceleration of rsa is vulnerable to

side-channel timing attacks,” in Proceedings of the International Conference
on Computer-Aided Design, p. 113, ACM, 2018.
[42] E. Alkim, L. Ducas, T. Pöppelmann, and P. Schwabe, “Post-quantum key

exchange—a new hope,” in 25th {USENIX} Security Symposium
({USENIX} Security 16), pp. 327–343, 2016.
[43] J. Bos, L. Ducas, E. Kiltz, T. Lepoint, V. Lyubashevsky, J. M. Schanck,

P. Schwabe, G. Seiler, and D. Stehlé, “Crystals-kyber: a cca-secure
module-lattice-based kem,” in 2018 IEEE European Symposium on Security
and Privacy (EuroS&P), pp. 353–367, IEEE, 2018.
[44] E. Messmer, “Meet the fastest public-key algorithm few have even heard of,”
tech. rep., Networkworld, 2018.
[45] X. Shen, Z. Du, and R. Chen, “Research on ntru algorithm for mobile java
security,” in 2009 International Conference on Scalable Computing and
Communications; Eighth International Conference on Embedded Computing,
pp. 366–369, IEEE, 2009.
[46] T. Kleinjung, K. Aoki, J. Franke, A. K. Lenstra, E. Thomé, J. W. Bos,

P. Gaudry, A. Kruppa, P. L. Montgomery, D. A. Osvik, et al.,
“Factorization of a 768-bit rsa modulus,” in Annual Cryptology Conference,
pp. 333–350, Springer, 2010.
[47] E. Barker and Q. Dang, “Nist special publication 800-57 part 3 revision,”
NIST, Tech. Rep, 2015.
52
[48] D. Pishva*, “Iot: Their conveniences, security challenges and possible
solutions,” Advances in Science, Technology and Engineering Systems
Journal, vol. 2, no. 3, pp. 1211–1217, 2017.
[49] T. Strahl and R. Johansson, “Post-quantum secure communication on a low

performance iot platform,” 2016.
[50] J. Hermans, F. Vercauteren, and B. Preneel, “Speed records for ntru,” in

Cryptographers’ Track at the RSA Conference, pp. 73–88, Springer, 2010.
53
Olof Magnusson received his BSc
degree from The Institute of
Computer Science and Engineering at
Halmstad University in 2018. His
research interests include:
Cryptography, Blockchain and
Embedded systems.
Mats Hurtig received his BSc degree

from The Institute of Technology at
Linköping University in 2015. His
research interests include: Network
Forensics, Digital Law and
Cryptography.
PO Box 823, SE-301 18 Halmstad

Phone: +35 46 16 71 00
E-mail: registrator@hh.se
www.hh.se

FULLTEXT03

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

FULLTEXT03

Caricato da

Copyright:

Formati disponibili

Master Thesis

Master’s in Network Forensics, 60hp

Post-Quantum Public Key Cryptography for

Digital Forensics, 15 credits

Olof Magnusson and Mats Hurtig

This dissertation is submitted for the degree of Masters

Department of Computer Science and Engineering

Supervisor: Eric Järpe

August 26, 2019

Olof Magnusson and Mats Hurtig

Recent progress in the field of quantum computers provide radically

Keywords: Cryptography, Post-quantum lightweight encryption, NTRU-

DES Data Encryption Standard

• Implementation of technology: Implement a quantum-safe lightweight

• Analysis of suitability: Reasoning for the suitability of implemented tech-

4.1 Transport layer Security

Figure 1: Illustration of classifications of symmetric and asymmetric cryptographic al-

4.1.2 Authentication and handshake

Figure 3: Illustration of how the Message Authentication Code is computed at sender

4.2 Lightweight encryption

4.2.1 Symmetric block ciphers

4.2.2 Advanced Encryption Standard

a(x) = a0 + a1 x + a2 x2 + ... + aN −1 xN −1 (3)

b(x) = b0 + b1 x + b2 x2 + ... + bN −1 xN −1 (4)

a(x) ∗ b(x) = c0 + c1 x + c2 x2 + . . . + cN −1 xN −1 (7)

NTRUEncrypt is using the ternary mathematically function for the algorithmic

h(x) ≡ pfq (x) ∗ g(x) (mod q) (9)

e(x) ≡ t(x) ∗ h(x) + m′ (x) (mod q) (10)

a(x) = e(x) ∗ f (x) mod q (11)

Definition 4.1. Let V 1 , . . . , V n ∈ Rm be linearly independent vectors. Linear

According to the Hermite theorem [29] every n-dimensional lattice L contains

Us = 2 |s⟩ ⟨s| − I (18)

4.4 Internet of Things

Table 1: Table over common network protocols used in smart homes

Protocol 802.11 Wi-Fi Bluetooth 5.0 Low Zigbee Z-wave

Average range 35-100 meters 10 meters 75-100 meters 10 meters

Data rate up to 433 Mbps 1 Mbps up to 250 kbps up to 100 kbps

Encryption (available) AES-128 AES-128 AES-128 AES-128

5.1 Experiment set-up

5.1.2 Temperature sensor

Universal binary sensor

Supply voltage 3.0-5.5V DC ±0.8%

Output 3 potential-free outputs

Operating temperature -55+125◦ C

Accuracy ±0.5°C accuracy from -10°C to + 85°C

Programmable Thermometer resolution is programmable from 9 to 12 bits

Convert Converts 12-bit temperature to digital word in 750 ms (max.)

Measurement range -55◦ C-+126◦ C

5.2 Implementation overview

Sample application purpose is to DER-encode the public inclusion in a certifi-

NTRUEncrypt for WolfSSL is enabled during compilation of the WolfSSL

Figure 13: Overview of the security domain for the application

Further in Figure 14 the implementation overview of the relations of NTRU-

5.3 Attack vectors towards the design

6.1 Key generation

parameters for NTRUEncrypt relative to the server timestamp

112 bit 128 bit 192 bit 256 bit

Figure 20: Histogram of encryption time series of tested NTRUEncrypt parameters

1,000 112 bit 128 bit 192 bit 256 bit

112 bit 128 bit 192 bit 256 bit

6.4 Practical implementation

0 50 100 150 200 250 300

NTRU743ep1-AES128 ECDHE-RSA-CHACHA20 ECDHE-RSA-AES256 ECDHE-RSA-AES256 ECDHE-RSA-AES128

Stdev 4.437595429 3.547883199 3.400296921 3.282896897 3.077426057