MASARYK
U N I V E R S I T Y
FACULTY O F INFORMATICS
Implementation of quantum-safe
VPN
Master's Thesis
KEVAL KRISHAN
Brno, Spring 2024
MASARYK
U N I V E R S I T Y
FACULTY O F INFORMATICS
Implementation of quantum-safe
VPN
Master's Thesis
KEVAL KRISHAN
Advisor: Prof. RNDr. Václav Matyáš, M . S c , Ph.D
Centre for Research on Cryptography and Security
Brno, Spring 2024
Declaration
Hereby I declare that this thesis is my original authorial work, which
I have worked out on my own. A l l sources, references, and literature
used or excerpted during elaboration of this work are properly cited
and listed in complete reference to the due source.
Keval Krishan
Advisor: Prof. RNDr. Václav Matyáš, M.Sc, Ph.D
iii
Acknowledgements
I thank my organization for allowing me to study at Masaryk University.
I thank all the teachers and colleagues at the University. Many
thanks go to my thesis consultant Mgr. Milan Patnaik for his kind
guidance.
I am also grateful to my supervisor Prof. Vaclav Matyas for giving
valuable comments on my work.
Finally, I thank my friends, my parents, and my wife Anjali for their
patience and support during my studies.
iv
Abstract
The rise of quantum computing presents a significant threat to many
conventional cryptographic algorithms, prompting the urgent development
of quantum-resistant alternatives. This thesis explores the implementation
and performance analysis of a quantum-safe Virtual Private
Network (VPN) using post-quantum cryptographic algorithms. The
study focuses on addressing the vulnerabilities of current VPNs to
quantum attacks by integrating post-quantum digital signature and
key exchange mechanisms.
The implementation involves deploying a V P N framework with
algorithms specifically designed to withstand attacks from quantum
computers. A comparative analysis is conducted between traditional
V P N setups and the quantum-safe V P N , highlighting the effectiveness
of post-quantum algorithms in providing secure communication
channels. Various metrics are used to evaluate the performance, including
encryption/decryption speeds, key establishment latency, and
computational overhead.
This research contributes to the growing field of quantum-safe
cryptography by demonstrating a practical solution for securing VPNs
against future quantum threats. The findings showcase the feasibility
and efficiency of integrating post-quantum algorithms within existing
V P N infrastructures, paving the way for enhanced cyber security in
the quantum era.
Keywords
Post-Quantum Cryptography, Virtual Private Network, Performance
Analysis
v
Contents
1 Introduction 1
1.1 Problem Statement 2
1.2 Contribution 3
1.3 Organization 4
2 Post-Quantum Cryptography 6
2.1 Quantum Computing and Its Implications 6
2.2 Post-Quantum Cryptographic Approaches 7
2.2.1 Lattice-Based Cryptography 9
2.2.2 HASH-Based Cryptography 13
2.2.3 Isogeny-Based Cryptography 14
2.2.4 Code-Based Cryptography 14
2.2.5 Multivariate Quadratic Cryptosystems 15
2.3 Challenges in PQC 16
2.3.1 Side Channel Attacks on PQC 16
3 Overview of VPN 18
3.1 IPsec V P N (Layer 3) 18
3.1.1 Characteristics 18
3.2 SSL V P N (Layer 4) 19
3.2.1 OpenVPN 20
3.3 Comparison: IPsec V P N vs. SSL-based OpenVPN . . . 21
3.4 IPsec or SSL-based V P N : Which Should We Choose? . . 22
3.5 Components of OpenVPN 22
4 Quantum Safe VPN 24
4.1 Overview of liboqs 24
4.1.1 Supported Algorithms 24
4.2 Integration of PQC Algorithms with OpenVPN 26
4.2.1 Technical Integration 26
4.2.2 Testing and Validation 28
4.2.3 Workflow 29
5 Performance Analysis of QS-VPN 30
5.1 Experiment Setup 30
5.2 Performance Testing Using iPerf3 31
vi
5.2.1 OpenVPN Performance 31
5.2.2 QS-VPN Performance 33
5.2.3 Comparative Analysis of iPerf Reports 34
5.3 Session Establishment in TLS 1.3 35
5.3.1 s_server Log 35
5.3.2 s_client Log for RSA Signature Algorithm . . . . 37
5.3.3 sjclient Log for Dilithium3 Signature Algorithm 38
5.3.4 Analysis of Session Establishment 40
6 Performance Benchmarking of PQC Algorithms 41
6.1 CRYSTALS Kyber Variants 42
6.2 CRYSTALS Dilithium Variants 43
6.3 F A L C O N Variants 44
6.4 SPHINCS+ Variants 45
6.5 Comparison of A l l P Q Digital Signature Schemes at
NIST Security Level L I , L3, L5 46
6.6 Analysis 48
7 Conclusion and Future Work 50
7.1 Thesis Contribution 50
7.2 Future Work 50
Bibliography 52
A APPENDIX 58
B APPENDIX 62
vii
List of Tables
2.1 CRYSTALS Kyber Variants 12
2.2 CRYSTALS Dilithium Variants 13
2.3 F A L C O N Variants 13
2.4 SPHINCS+Variants 14
3.1 IPsec V P N vs. SSL-based OpenVPN 21
4.1 Modified Protocols of V P N 28
5.1 iPerf Dual Testing of OpenVPN 32
5.2 iPerf Dual Testing of QSVPN 33
6.1 CRYSTALS Kyber Algorithm Performance with Respect
to Number of C P U Cycles 42
6.2 Dilithium Algorithm Performance with Respect to Number
of C P U Cycles 43
6.3 F A L C O N Algorithm Performance with Respect to Number
of C P U Cycles 44
6.4 SPHINCS+ Algorithm Performance with Respect to Number
of C P U Cycles 45
viii
List of Figures
2.1 The Venn Diagram Describes The Fields of PQC Research. 7
2.2 Lattice Formed by Two Two-Dimensional Vectors 10
3.1 IPsecVPN 19
3.2 SSL V P N 20
4.1 Conceptual Components View of OpenSSL 26
6.1 Performance Graph of Kyber Variants with Respect to Key
Pair Generation, Encapsulation & Decapsulation 42
6.2 Performance Graph of Dilithium Variants with Respect to
Key Pair Generation, Signing, and Verification 43
6.3 Performance Graph of FALCON Variants with Respect to
Key Pair Generation, Signing, and Verification 44
6.4 Performance Graph of SPHINCS+ Variants with Respect
to Key Pair Generation, Signing, and Verification 45
6.5 Comparison of All PQ Digital Signature Schemes at NIST
Security Level L I 46
6.6 Comparison of All PQ Digital Signature Schemes at NIST
Security Level L3 47
6.7 Comparison of All PQ Digital Signature Schemes at NIST
Security Level L5 47
B.l C A Certificate Details 62
B.2 Home page of The QS-VPN Client Application 63
B.3 Checking C A Certificate 64
B.4 Checking Client Certificate 64
B.5 Connecting with QS-VPN Server 65
ix
1 Introduction
In the rapidly evolving landscape of information technology and cybersecurity,
the advent of quantum computing poses an unprecedented
threat to conventional cryptographic systems. As quantum computers
promise to exponentially increase computational power, they also
bring the potential to break widely used cryptographic algorithms,
compromising the security of sensitive data transmitted over networks.
Recognizing the impending challenges posed by quantum adversaries,
the field of Post-Quantum Cryptography (PQC) has emerged to develop
encryption algorithms resilient against quantum attacks.
This thesis delves into the imperative need for implementing quantumsafe
Virtual Private Networks (VPNs) as a robust defense mechanism
against the impending threat of quantum computers. The traditional
cryptographic algorithms employed in current V P N infrastructures,
such as Rivest, Shamir, Adleman (RSA) [51], Diffie-Hellman [16] and
Elliptic Curve Cryptography (ECC) [31], are susceptible to being broken
by quantum algorithms, thereby necessitating the exploration and
integration of PQC algorithms to ensure the long-term confidentiality
and integrity of sensitive communications.
The primary objective of this research is to present an implementation
of a quantum-safe V P N , combining the strength of PQC algorithms,
specifically different versions of CRYSTALS Kyber [8] for Key Encapsulation
Mechanism (KEM) and Dilithium [20], F A L C O N [46]
and SPHINCS+ [3] for digital signature, with the widely adopted
OpenV P N system. These algorithms have been chosen for their demonstrated
resilience against quantum attacks, ensuring the security of
key establishment and data verification in the quantum era.
This introduction lays the groundwork for the subsequent chapters
by providing an overview of the current state of quantum computing,
the vulnerabilities posed to traditional cryptographic systems, and the
urgency to transition towards quantum-safe alternatives. Additionally,
it introduces the chosen PQC algorithms, CRYSTALS Kyber and
Dilithium, FALCON and SPHINCS+. The incorporation of OpenVPN
as the base system further establishes a pragmatic and widely utilized
foundation for the proposed quantum-safe V P N .
The subsequent sections will delve into the theoretical underpinnings
1
i. INTRODUCTION
of CRYSTALS Kyber [7] and Dilithium [17], FALCON and SPHINCS+,
their integration into OpenVPN, the design and implementation of the
quantum-safe V P N architecture, and a comprehensive evaluation of its
performance and security aspects. Thereafter the benchmarking and
comparative analysis of different variants of CRYSTALS Kyber and all
three signature algorithms Dilithium, FALCON, and SPHINCS+ has
been done. Through this research, we aim to contribute to the evolving
field of quantum-safe cryptography and fortify the foundation of
secure communication networks in the face of impending quantum
advancements.
1.1 Problem Statement
The vulnerability of certain cryptographic systems to quantum attacks
poses a critical problem for Virtual Private Networks (VPNs), which
play a pivotal role in ensuring secure and private communication
across the Internet. VPNs rely on cryptographic algorithms for key
exchange, data encryption, and digital signatures, some of which are
susceptible to quantum computers' compromise. As organizations and
individuals increasingly depend on VPNs to safeguard their digital
communications, it becomes imperative to address the quantum threat
and implement robust quantum-safe alternatives.
The problem at hand is twofold. Firstly, there is an urgent need
to transition from traditional cryptographic algorithms to PQC algorithms
that can resist attacks from quantum computers. Secondly, the
integration of these PQC algorithms into widely used V P N systems,
such as OpenV P N , must be accomplished to ensure the continued
security of data transmissions in the quantum era.
Our research aims to address the identified problem by exploring
and implementing a quantum-safe V P N solution, leveraging the capabilities
of CRYSTALS Kyber for key exchange and Dilithium, FALCON,
and SPHINCS+ for digital signatures within the OpenV P N framework.
The challenges include an efficient integration of these PQC
algorithms into the existing V P N infrastructure, ensuring compatibility
and performance without sacrificing the key security objectives.
2
i. INTRODUCTION
1.2 Contribution
1. Literature survey of existing work in National Institute of Standards
and Technology (NIST) standardized PQC algorithms and
OpenV P N : Conducting a literature survey involves reviewing
the landscape of NIST PQC standardization and understanding
their impact on the TLS [50] protocol. The objective of the survey
is to determine an effective method for integrating post-quantum
K E M and digital signatures with TLS, enabling their utilization
within OpenVPN.
2. Explore a way to modify OpenSSL to include PQC algorithms
for key exchange and digital signature: The exploration phase
involves investigating methods to integrate PQC algorithms into
the OpenSSL library, a fundamental component of many cryptographic
systems including OpenVPN. This exploration seeks
to identify feasible approaches for incorporating PQC-based
key exchange and digital signature schemes within OpenSSL to
enable quantum-safe V P N capabilities.
3. Integrate the modified OpenSSL with OpenVPN: Once suitable
modifications to OpenSSL have been identified and implemented,
the next step is to integrate the modified OpenSSL
library with OpenVPN. This integration process involves adapting
existing protocols and mechanisms of OpenVPN to leverage
the newly integrated PQC algorithms for key exchange and digital
signatures, ensuring compatibility and functionality.
4. Testing and validation of modified V P N (quantum-safe V P N )
in client-server architecture: Following integration, rigorous testing
and validation of the V P N solution are essential. This phase
involves deploying the modified V P N in a client-server architecture
and conducting comprehensive testing to assess security,
performance, and interoperability aspects. Validation ensures
that the V P N solution meets its objectives without compromising
usability.
5. Performance benchmarking and comparative analysis of quantumsafe
V P N vs. classical V P N : Finally, the performance of the
3
i. INTRODUCTION
Quantum-Safe V P N is benchmarked and compared against traditional
V P N solutions. Key metrics such as latency, throughput,
and resource utilization are evaluated under various conditions
to gauge the efficacy of the quantum-safe enhancements. The
comparative analysis aims to highlight the advantages and tradeoffs
of adopting a quantum-safe approach in V P N technologies.
1.3 Organization
This thesis is organized into the following chapters:
• Chapter 1 (Introduction) provides an overview of the research
problem, motivation, objectives, and the structure of the thesis.
• Chapter 2 (Post-Quantum Cryptography) provides a comprehensive
overview of PQC, including fundamental concepts, algorithms,
and their relevance in modern security contexts.
• Chapter 3 ( V P N Architecture) discusses two prominent types
of V P N architectures: IPsec V P N and SSL-based OpenVPN. It
details the selection process that led to choosing OpenVPN for
modification towards quantum-safe functionality.
• Chapter 4 (Quantum Safe V P N ) describes the process of modifying
OpenVPN to achieve quantum-safe characteristics. This
includes integrating liboqs with OpenSSL using third-party
provider concepts and utilizing the modified OpenSSL to develop
the quantum-safe V P N (QSVPN).
• Chapter 5 (Performance Analysis of QSVPN) presents a detailed
analysis of the performance metrics of the quantum-safe
V P N , comparing it with traditional V P N solutions. This chapter
provides insights into the advantages and limitations of the
quantum-safe enhancements.
• Chapter 6 (Performance Benchmarking of PQC Algorithms)
provides the benchmarking and performance testing for various
PQC algorithms.
4
i. INTRODUCTION
• Chapter 7 (Conclusion and Future Scope) summarizes the findings
of the research and discusses potential future directions
and extensions of the work.
Each chapter contributes to addressing the research objectives and
provides essential insights into the development and evaluation of the
quantum-safe V P N solution.
5
2 Post-Quantum Cryptography
In this Chapter, we first discuss Quantum computing and its implications
and then delve into the Post-Quantum Cryptography (PQC),
various PQC algorithms, and their significance in contemporary security
environments.
2.1 Quantum Computing and Its Implications
Quantum computing represents a paradigm shift in computational capabilities
by harnessing the principles of quantum mechanics. Unlike
classical computers that use bits to represent either a 0 or a 1, quantum
computers use qubits, which can exist in multiple states simultaneously
due to a phenomenon known as superposition. This enables quantum
computers to process information in parallel, potentially solving certain
problems exponentially faster than classical computers.
One of the seminal discoveries in quantum computing is Shor's
algorithm [53], named after mathematician Peter Shor. Shor's algorithm
is particularly significant in the realm of cryptography because it efficiently
factors large numbers and solves the discrete logarithm [43]
problem—two computational tasks that form the basis of widely used
public-key cryptographic systems.
Traditional encryption algorithms, such as RSA [51] and ECC, rely
on the difficulty of factoring large numbers and solving discrete logarithms
to provide security. Shor's algorithm, when implemented on
a sufficiently powerful quantum computer, threatens to unravel the
security of these cryptographic systems. The implications are profound,
as it implies that the encrypted communications widely used
today may become susceptible to rapid decryption, compromising the
confidentiality of sensitive information.
One of the leading approaches in P Q C is lattice-based cryptography.
Lattices are mathematical structures that exhibit unique computational
properties, forming the basis for cryptographic primitives
that resist quantum attacks. The inherent difficulty of certain lattice
6
2. POST-QUANTUM CRYPTOGRAPHY
problems, such as the SVP [40] and L W E [49, 9], form the crux of the
security in lattice-based cryptography
2.2 Post-Quantum Cryptographic Approaches
The advent of quantum computing has ushered in a new era of technological
possibilities, but it also poses a significant threat to the existing
cryptographic foundations that underpin the security of our digital
world. As quantum computers inch closer to reality, the cryptographic
algorithms widely employed today, such as RSA and E C C , face the
risk of being broken with unprecedented efficiency. Recognizing this
vulnerability, the field of P Q C has emerged as a proactive response
to the impending threat, aiming to develop cryptographic primitives
resistant to quantum attacks.
Research on P Q C has been increasing in quantity and quality in
recent years. Studies focus on candidate algorithms that have been
selected through the stages. The Venn diagram in 2.1 briefly describes
the current state of research on P Q C , in which the circles with blue
words are the basis of encryption, the red words are the names of the
algorithms that are candidates
Figure 2.1: The Venn diagram describes the fields of P Q C research.
Source: https://rb.gy/uy9sao.
7
2. POST-QUANTUM CRYPTOGRAPHY
Here is a list of some of the popular theoretical bases of PQC:
1. Lattice-based cryptography: Introduced by Ajtai in his groundbreaking
paper "Generating Hard Instances of Lattice Problems"
[2]-
2. Hash-based cryptography: Pioneered by Merkle through "A Certified
Digital Signature" [38].
3. Isogeny-based cryptography: First proposed by Couveignes and
Rostovtsev-Stolbunov, with the foundational paper "Hard Homogeneous
Spaces" [52].
4. Code-based cryptography: Originated from the McEliece cryptosystem,
as presented in " A Public-Key Cryptosystem Based
On Algebraic Coding Theory" [37].
5. Multivariate quadratic equations: Introduced in "MPKC (Multivariable
Public Key Cryptosystems)" [34].
Lattice-based cryptography, underpinned by complex problems
like Learning With Errors (LWE) and the Shortest Vector Problem
(SVP), stands out for its resistance to quantum attacks, a resilience
rooted in the exponential complexity that quantum algorithms would
encounter when addressing these problems [48]. Isogeny-based cryptography,
an emerging field, offers promising solutions through smaller
key sizes and the intricate task of computing isogenies between elliptic
curves, a problem not efficiently solvable by current quantum algorithms
[15]. Code-based cryptography, deriving from the McEliece
cryptosystem, leverages the intractability of decoding random linear
codes, a problem for which quantum computers do not yet have a
significant advantage [5]. Hash-based cryptography hinges on the
security properties of hash functions, such as collision resistance and
preimage resistance, which remain robust against quantum computing
threats due to the one-way nature of these functions [4]. Multivariate
quadratic equations employ the complexity of solving such equations
over finite fields, a challenge that is currently not efficiently addressable
by quantum algorithms [ 19 ]. Together, these methodologies showcase
a spectrum of strategies to safeguard cryptographic systems in the
8
2. POST-QUANTUM CRYPTOGRAPHY
quantum era, each tapping into distinctive mathematical challenges
that remain elusive to the capabilities of quantum computing.
The evolution of PQC is characterized by a rich array of techniques,
each contributing to a comprehensive defense strategy against the
anticipated advancements of quantum computing. The continuous
exploration and improvement of these methods are imperative to
maintain the integrity and confidentiality of digital communication in
the forthcoming quantum age [42].
2.2.1 Lattice-Based Cryptography
Lattice-based cryptographic [58] techniques are highly promising for
PQC due to their robust security proofs based on worst-case hardness,
efficient implementations, and inherent simplicity. Furthermore,
lattice-based cryptography is deemed secure against quantum computing
threats.
Lattices [41]: A lattice is defined as the set of all integer combina-
tions
of m linearly independent vectors b\,... ,bm in R w
(see Figure 2.2).
The set of vectors b i , . . . , b m is called a basis for the lattice. A basis
can be represented by the matrix B = \b\,..., b m ] G Rnxm
having the
basis vectors as columns. Using matrix notation, the lattice generated
by a matrix B G ]Rw x m
c a n be defined as
where Bx represents the usual matrix-vector multiplication. We denote
m as the rank and n as the dimension of the lattice. When m = n, the
lattice is referred to as a full-rank lattice.
Consider m = n = 2, i.e. consider a 2-dimensional full-rank lattice
C having basis vectors B = {bi,b2}.
£(B) = {Bx : x G Z m
} ,
9
2. POST-QUANTUM CRYPTOGRAPHY
Observe that the basis underlying a lattice C is not unique. For
instance, the lattice generated by the vectors
is Z 2
, and all the points of Z 2
can also be generated by the vectors
As j b ^ b ^ j is linearly independent and b 2 = b^ — h'2 and b i
—b'x + 2h'2, implies j b ^ b ^ j is also a basis of £.
However,
'1
C l = l 0 , C 2 :
is not a basis of C. C = {ci, C2} is linearly independent but C can not
generate C.
. 1
•
•
*
u: •:• • .
•
•
•
Figure 2.2: Lattice Formed by Two Two-Dimensional Vectors.
Hard problems: There are a couple of long-standing hard problems
when dealing with lattices. Essentially, if you can solve one of them,
then that provides a solution to others as well.
10
2. POST-QUANTUM CRYPTOGRAPHY
• Shortest vector problem [1]: Given a basis of a vector space V and
a norm N (often L 2
norm) defined on V, consider a lattice L in
V. The goal is to find the shortest non-zero vector v £ L with
respect to the norm N . In other words, the algorithm should
output a non-zero vector v such that
= A(L),
where A(L) denotes the length of the shortest non-zero vector
in L according to the norm N.
^-approximation version SVP (S VP7 ): In the (S V P 7 ) , the objective
is to find a non-zero lattice vector v G L such that its length does
not exceed 7 • A(L), where 7 > 1 is a given parameter.
In mathematical terms, the goal is to find a vector v G L satisfy-
ing
IMIN < 7-A(L),
where A(L) is the length of the shortest non-zero vector in L
according to the norm N.
• Closest Vector Problem (CVP) [39]: Given a lattice basis B with
a norm N and a target vector y (not necessarily in the lattice),
the objective is to find a lattice vector xB (x E Z w
) such that
\\xB — y\\N is minimized.
Decisional Version of CVP: In the decisional version of CVP, one
is also given a real number A, and the task is to decide whether
there exists an integer vector x such that \\xB — y||jv < A.
• Shortest Independent Vectors Problem (SIVP) [6]: Given a lattice
L. For a lattice L of dimension n, the algorithm must output n
linearly independent vectors V\,vj_,... ,vn such that
max ||i7v|| < max ||b,-||.11 m - B 11 in/
where the right-hand side considers all bases B = {b\,... ,bn}
of the lattice.
In the 7-approximate version: Given a lattice L with dimension
n, one must find n linearly independent vectors V\,Vj_,... ,vn of
length max ||i7,-|| < 7An (L), where A„(L) is the nth successive
minimum of L.
11
2. POST-QUANTUM CRYPTOGRAPHY
These three problems have been rigorously proven to be equivalent
(solving any one of them solves the others). While there have been
proposed cryptographic systems that use these problems directly
most proposals use other problems and try to show that these other
problems are equivalent to one of these three problems.
CRYSTALS Kyber: A Lattice-Based Key Exchange Algorithm
Kyber is an IND-CCA2-secure K E M , whose security is based on the
hardness of solving the LWE problem over module lattices. Kyber is
one of the finalists in the NIST PQC project1
. The Kyber suite consists
of three different parameter sets aimed at different security levels.
Specifically Kyber-512 aims at security roughly equivalent to AES-128,
Kyber-768 aims at security roughly equivalent to AES-192, and Kyber-
1024 aims at security roughly equivalent to AES-256.
Table 2.1: CRYSTALS Kyber Variants.
Name of the
algorithm
Security model
Public key size
(bytes)
Secret key size
(bytes)
Ciphertext size
(bytes)
Kyber512 IND-CPA 800 1632 768
Kyber768 IND-CPA 1184 2400 1088
Kyberl024 IND-CPA 1568 3168 1568
CRYSTALS Dilithium: A Lattice-Based Digital Signature
Algorithm
Dilithium is a digital signature scheme that achieves strong security
against chosen message attacks, relying on the hardness of lattice
problems over module lattices. This security property implies that an
adversary with access to a signing oracle cannot forge a signature for a
message they have not previously observed, nor can they generate a different
signature for a message that has already been signed. Dilithium
is among the candidate algorithms submitted to the NIST PQC project.
1. https://csrc.nist.gov/Proj ects/Post-Quantum-Cryptography
12
2. POST-QUANTUM CRYPTOGRAPHY
Dilithium comes in three flavors, with the following parameters:
Table 2.2: CRYSTALS Dilithium Variants.
Name of the
algorithm
Security model
Public key size
(bytes)
Secret key size
(bytes)
Signature size
(bytes)
Dilithium2 EUF-CMA 1312 2528 2420
Dilithium3 EUF-CMA 1952 4000 3283
Dilithium5 EUF-CMA 2592 4864 4595
FALCON: A Lattice-Based Digital Signature Algorithm
F A L C O N is a signature scheme grounded i n lattice cryptography,
specifically designed for efficient and compact execution over NTRU
[13] lattices, as indicated by its full name, "Fast-Fourier lattice-based
compact signatures over NTRU."
Table 2.3: F A L C O N Variants.
Name of the
algorithm
Security model
Public key size
(bytes)
Secret key size
(bytes)
Signature size
(bytes)
FALCON-512 EUF-CMA 897 1281 752
FALCON-1024 EUF-CMA 1793 2305 1462
2.2.2 HASH-Based Cryptography
The basic concept behind hash-based signatures [10, 56] is quite
straightforward. First, values are chosen in advance for signing purposes,
each assigned a lengthy random string. These strings undergo
hashing and are then made public as keys. When an object is signed,
the associated random value is disclosed, serving as the signature. To
verify the signature, a verifier hashes it and compares it against the
corresponding entry in the public key.
SPHINCS+: A Hash-Based Digital Signature Algorithm
SPHINCS+ is an advanced digital signature algorithm designed to
resist attacks from quantum computing. It is based on hash-based
13
2. POST-QUANTUM CRYPTOGRAPHY
cryptography, making its security evaluation simple and dependent
only on the properties of the hash function being used.
Table 2.4: SPHINCS+ Variants.
Name of the algorithm
Security
model
Public key
size (bytes)
Secret key
size (bytes)
Signature
size (bytes)
SPHINCS+-SHA2-128f-simple EUF-CMA 32 64 17088
SPHINCS+-SHA2-128s-simple EUF-CMA 32 64 7856
SPHINCS+-SHA2-192f-simple EUF-CMA 48 96 35664
SPHINCS+-SHAKE-128f-
simple
EUF-CMA 32 64 17088
2.2.3 Isogeny-Based Cryptography
Isogeny-based cryptography [24] is a post-quantum cryptographic approach
that leverages the complexity of computing isogenies between
elliptic curves over finite fields. This method relies on the difficulty of
certain computational problems related to isogenies, such as finding
the isogeny mapping between elliptic curves [54]. The security of isogenybased
protocols, like the Supersingular Isogeny Diffie-Hellman (SIDH)
[14] key exchange, Supersingular Isogeny Key Encapsulation (SIKE) are
based on the presumed challenge of solving these isogeny problems,
which are believed to withstand attacks from both classical and quantum
computers. SIKE is an isogeny-based key encapsulation suite
based on pseudo-random walks in supersingular isogeny graphs, that
was submitted to the NIST standardization process on PQC. It was
selected for the third round and there are some studies on this scheme
[22]. However, this P K E / K E M was attacked [12] and removed from
the list of fourth-round candidate algorithms.
2.2.4 Code-Based Cryptography
Code-based cryptography [44] uses error-correcting codes as the foundation
for secure cryptographic schemes. Unlike traditional systems
based on number theory, code-based cryptography relies on the complexity
of decoding structured linear codes [32] to resist attacks, includ-
14
2. POST-QUANTUM CRYPTOGRAPHY
ing those from quantum computers. The security of these schemes
is grounded in the difficulty of distinguishing between random and
valid codewords, which forms the basis for cryptographic operations.
The McEliece cryptosystem [36], introduced in 1978, is a prominent
example of code-based cryptography that remains secure against quantum
adversaries. Code-based cryptography offers resilience against
quantum attacks and presents a viable approach for securing digital
communications in a post-quantum world. It provides a mathematically
sound and practical method for achieving cryptographic security
based on error-correcting codes. The cryptosystem has not, however,
escaped the attention of attack and, over the last four decades, a variety
of algorithms have been proposed with the intention of exploiting it
to recover the plaintext like Stern's algorithm [57], Lee and Brickell's
Algorithm [33] etc.
2.2.5 Multivariate Quadratic Cryptosystems
Multivariate Quadratic Cryptosystem (MQC) [18] is a type of public
key cryptography that relies on the hardness of solving systems of
multivariate quadratic equations over finite fields. In M Q C , the public
key consists of multivariate quadratic polynomials, and the private
key is derived from the structure of these polynomials.
Multivariate Public Key Cryptosystems (MPKC) [55] encompass a
variety of cryptographic schemes based on the difficulty of solving
systems of multivariate polynomial equations. M P K C schemes can be
classified based on the types of polynomials used, such as multivariate
quadratic, multivariate cubic, or higher-degree polynomials.
The security of M P K C schemes typically relies on the inherent
difficulty of solving systems of multivariate polynomial equations, which
is believed to resist attacks from classical and quantum computers.
M P K C schemes are studied for their potential resistance to quantum
attacks, making them candidates for PQC.
15
2. POST-QUANTUM CRYPTOGRAPHY
2.3 Challenges in PQC
PQC introduces a set of challenges, some of which are mentioned
below.
1. Algorithmic diversity: PQC involves exploring and developing
new cryptographic algorithms that can withstand attacks from
quantum computers. This requires a diverse range of algorithms,
each with its own security guarantees and performance charac-
teristics.
2. Security assurance: Ensuring the security of post-quantum algorithms
against both classical and quantum attacks is crucial.
Many proposed PQC schemes are based on mathematical problems
that are believed to be hard for classical computers but may
have different vulnerabilities against quantum adversaries.
3. Performance trade-offs: Post-quantum algorithms often exhibit
different performance characteristics compared to traditional
cryptographic algorithms. This includes considerations such as
key size, computational efficiency, and memory usage.
4. Standardization and adoption: Standardizing post-quantum algorithms
involves a rigorous evaluation process to ensure their
security, efficiency, and practicality. Once standardized, widespread
adoption of these algorithms across various systems and applications
presents additional challenges.
5. Transition period: Transitioning from classical to PQC requires
careful planning and consideration. Systems and protocols need
to be updated to support both classical and post-quantum algorithms
during the transition period.
6. Interoperability: Post-quantum algorithms must be compatible
with existing cryptographic standards and protocols to ensure
interoperability across different systems and platforms.
2.3.1 Side Channel Attacks on PQC
Side channel attacks (SCAs) exploit various unintended channels of
information leakage, such as power consumption, electromagnetic
16
2. POST-QUANTUM CRYPTOGRAPHY
radiation, or timing information, to infer sensitive data like cryptographic
keys or algorithm details. Despite the promise of PQC algorithms
in resisting quantum attacks, they remain vulnerable to
sophisticated side-channel attacks, including power-based [28] and
machine learning-based [47] techniques.
Power-Based and Machine Learning-based SCA: Power-based
side-channel attacks exploit fluctuations in power consumption to
extract information about the cryptographic operations being performed.
By monitoring power consumption during encryption or decryption
processes, attackers can deduce secret keys or other sensitive
information. Traditional countermeasures against such attacks, such
as masking or shuffling techniques, may not be sufficient to protect
against advanced power analysis methods. Machine learning-based
side channel attacks represent another significant threat to PQC systems.
These attacks leverage machine learning algorithms to analyze
side-channel information and detect patterns that could reveal secret
keys or expose vulnerabilities in cryptographic algorithms. By
exploiting statistical and pattern recognition capabilities, attackers
can enhance the efficiency and success rate of side-channel attacks on
PQC.
17
3 Overview of VPN
Implementing a quantum-safe V P N requires a thoughtful selection of
an appropriate V P N solution. It is essential to consider the variety of
V P N protocols available, especially those that operate with different
protocols based on the OSI (Open Systems Interconnection) layers. Two
prominent V P N types to evaluate are IPsec VPN and SSL V P N , each
offering distinct advantages and suitable use cases.
3.1 IPsec VPN (Layer 3)
IPsec, short for Internet Protocol Security [26], is a framework of
interconnected protocols designed to ensure data confidentiality by
encrypting packets before transmission over a network. It also provides
data integrity, ensuring that transmitted packets remain unchanged
and unaffected during transmission. IPsec provides authentication
at the IP layer and supports the protection of multiple data flows
simultaneously. Additionally, IPsec includes an anti-replay feature
that detects and rejects replayed packets to enhance security.
IPsec is most commonly used for site-to-site connectivity, enabling
secure communication between multiple offices within the same orga-
nization.
3.1.1 Characteristics
IPsec is a suite of secure network protocols developed by the Internet
Engineering Task Force (IETF) since 1992. It consists of three main
protocols:
• Authentication Header (AH): Provides data integrity and data
origin authentication but does not offer confidentiality, leading
to limited usage today. [29]
• Encapsulating Security Payload (ESP): Offers confidentiality,
data integrity, and data origin authentication. [30]
18
3. OVERVIEW OF V P N
• Internet Security Association and Key Management Protocol
(ISAKMP): Establishes a framework for authentication and key
exchange. [35]
Typically ISAKMP is used in conjunction with ESP ISAKMP utilizes
the U D P [45] protocol on port 500, while ESP operates with its
own IP protocol using the number 50. In scenarios where network address
translation (NAT) is present, ESP is encapsulated within UDP and
utilizes port 4500. Therefore, under normal circumstances without
NAT, ISAKMP uses UDP/500, and ESP uses IP protocol 50. With NAT,
ISAKMP uses UDP/500, and ESP encapsulation employs UDP/4500.
RUT 1 RUT 2
IPsec instace 1
Public IP: 1SS.G9.194.44
LAN IP: 132.168.1.1
IPsec instance 2
Public IP: 183.G9.194.45
LAN IP: 192.168.2.1
IPsec Tunnel
Figure 3.1: IPsec V P N . Source: https://images.app.goo.gl/
qx72rNiJcL4ry4wG7.
3.2 SSL VPN (Layer 4)
TLS (Transport Layer Security) and SSL (Secure Sockets Layer) VPNs
operate at the transport layer (Layer 4) of the OSI model. These VPNs
emerged as alternatives to the IPsec framework, primarily due to the
challenges in supporting diverse end-users and platforms.
19
3- OVERVIEW OF V P N
SSL VPNs provide secure remote access to corporate networks and
applications through a web-based portal and establish an SSL-secured
tunnel between the client device and the corporate network.
3.2.1 Open V P N
OpenVPN, introduced in 2001, is a popular SSL V P N solution. It can
operate over TCP [21] or HDP protocols using various ports, including
the ability to work via an HTTP [25] proxy.
Characteristics of OpenVPN
Flexibility: OpenVPN can operate over TCP or UDP, making it adaptable
to various network environments and bypassing restrictive fire-
walls.
Encryption and security: OpenVPN utilizes strong encryption algorithms
(e.g., AES ) to secure data transmitted over the V P N tunnel.
Authentication mechanisms: Supports multiple authentication methods,
including username/password, certificates, and token-based au-
thentication.
SSL VPN tunnel
Server
SSL VPN
Clear tcxr commiiniratfrjr S5LVPN communication
Figure 3.2: SSL V P N . Source: https://images.app.goo.gl/
KgpJY6MAR2rNY6H16.
20
3- OVERVIEW OF V P N
How does Open VPN Work:
1. Tunnel establishment: OpenV P N initiates a secure tunnel (VPN
connection) between the client device and the V P N server.
2. Entity authentication: The client and server authenticate each
other using pre-shared keys, certificates, or other authentication
methods.
3. Data encryption: A l l data transmitted through the tunnel is
encrypted to ensure confidentiality.
4. Routing: OpenV P N manages the routing of data packets between
the client and the corporate network, ensuring secure
communication.
3.3 Comparison: IPsec VPN vs. SSL-based Open VPN
Table 3.1: IPsec V P N vs. SSL-based OpenVPN.
Features IPsec VPN SSL VPN
Protocols IKE [11] and ESP. HTTP over SSL.
Entity
authenticaIKEv2
[23] for
authentication
between V P N peers.
SSL certificates for client
authentication.
tion
Network
layers
Layer 3. Layer 4.
Connects remote
Connects clients to specific
applications and services.
Connectivity hosts to entire
networks.
Connects clients to specific
applications and services.
Applications
Support all IP-based
applications.
Supports email, file sharing, and
browser-based applications.
Gateway
location
Gateway are usually
implemented on the
firewall.
Gateway typically deployed
behind the firewall.
Endpoints
Requires host-based
clients.
Browser-based, with an optional
thin client.
21
3. OVERVIEW OF V P N
3.4 IPsec or SSL-based VPN: Which Should We
Choose?
When deciding between IPsec and SSL-based V P N (specifically, OpenV
P N ) for implementing a quantum-safe V P N solution, Open V P N
emerges as a compelling choice for several reasons.
OpenV P N utilizes the OpenSSL library for encryption providing
significant flexibility. This compatibility enables the integration of postquantum
cryptographic algorithms through third-party providers,
leveraging the extensive capabilities of Open VPN.
Additionally, OpenV P N protocol can operate over both TCP and
UDP, offering versatility in deployment across various network environments
and overcoming potential port restrictions or firewall limi-
tations.
The SSL-based protocol of OpenV P N ensures robust security measures,
including strong encryption, authentication, and key exchange
mechanisms. Its straightforward configuration and management make
it accessible even for less experienced administrators, reducing the
complexity associated with deploying a secure V P N solution.
3.5 Components of OpenVPN
OpenV P N is designed to run in the client-server model. The components
of OpenV P N are described below.
1. OpenV P N protocol: OpenV P N uses a custom protocol based on
SSL/TLS to create secure connections. The protocol has a high
level of tunability and configuration capabilities.
2. Tunneling protocols: OpenV P N utilizes virtual network interfaces
( T U N or TAP) to route data packets through the V P N
tunnel.
T U N : Suitable for Layer 3 (network layer) traffic, where entire
IP packets are encapsulated for secure transmission.
TAP: Operates at Layer 2 (data link layer), allowing for more
granular control over network traffic types.
22
3. OVERVIEW OF V P N
3. Pre-shared keys or certificates: OpenV P N supports various authentication
methods to verify client identity before establishing
the tunnel. This often involves pre-shared keys or digital certifi-
cates.
4. Control channel: A separate, temporary channel established
during connection setup. It handles tasks like key exchange,
authentication, and negotiation of encryption parameters. This
channel is typically secured with strong ciphers like SSL.
5. Data channel: The primary encrypted tunnel where user data
traffic flows after successful authentication. A l l data exchanged
between client and server gets encapsulated within this secure
channel.
6. Configuration files: Both client and server require configuration
files specifying parameters like server address, encryption
settings, certificates, tunnel, and other options.
In the upcoming chapter, we will provide a detailed explanation
of how to integrate post-quantum algorithms with OpenVPN. Specifically,
we will explore the integration of post-quantum key exchange
and digital signature algorithms into OpenSSL using a third-party
provider. Subsequently, we will demonstrate how OpenSSL, enriched
with these post-quantum capabilities, can be utilized within the OpenV
P N framework.
23
4 Quantum Safe VPN
4.1 Overview of liboqs
liboqs is an open-source C library designed for quantum-safe cryptographic
algorithms, distributed under the MIT License. The list of
supported algorithms are described at Section 4.1.1 in details. It also
offers the following key features:
• Collection of quantum-safe algorithms: liboqs provides opensource
implementations of quantum-safe key encapsulation mechanisms
(KEM) and digital signature algorithms.
• Common API: The library utilizes a uniform API for post-quantum
key encapsulation and signature algorithms, facilitating seamless
algorithm switching. This API is modeled after the NIST /
SUPERCOP API, enhanced with additional wrappers and data
structures.
• Multi-platform support: liboqs supports multiple platforms including
Linux, macOS, and Windows, with compatibility for
x86_64 and A R M architectures (excluding Windows on ARM64).
Cross-compilation toolchains are available for porting to other
platforms.
4.1.1 Supported Algorithms
Below is a comprehensive list of algorithms currently supported by liboqs,
encompassing experimental algorithms while excluding variants
pruned during the NIST competition, such as Kyber-90s or Dilithium-
AES.
Key encapsulation mechanisms (KEM)
• BIKE: BIKE-LI, BIKE-L3, BIKE-L5.
• Classic McEliece: Classic-McEliece-348864t, Classic-McEliece-
348864ft, Classic-McEliece-460896t, Classic-McEliece-460896ft,
24
4. Q U A N T U M SAFE V P N
Classic-McEliece-6688128t, Classic-McEliece-6688128ft, Classic-
McEliece-6960119t,Classic-McEliece-6960119ft,Classic-McEliece-
8192128t, Classic-McEliece-8192128ft.
• FrodoKEM: FrodoKEM-640-AES, FrodoKEM-640-SHAKE, FrodoKEM-
976-AES, FrodoKEM-976-SHAKE, FrodoKEM-1344-AES, FrodoKEM-
1344-SHAKE.
• H Q C : HQC-128, HQC-192, HQC-256.
• Kyber: Kyber512, Kyber768, Kyberl024.
• M L - K E M : ML-KEM-512-ipd (alias: ML-KEM-512), M L - K E M -
768-ipd (alias: ML-KEM-768), ML-KEM-1024-ipd (alias: M L -
KEM-1024).
• NTRU-Prime: sntrup761.
Signature schemes
• CRYSTALS-Dilithium: Dilithium2, Dilithium3, Dilithium5.
• FALCON: FALCON-512, FALCON-1024, FALCON-padded-512,
FALCON-padded-1024.
• ML-DSA: ML-DSA-44-ipd (alias: ML-DSA-44), ML-DSA-65-ipd
(alias: ML-DSA-65), ML-DSA-87-ipd (alias: ML-DSA-87).
• SPHINCS+-SHA2: SPHINCS+-SHA2-128f-simple, SPHINCS+SHA2-128s-simple,
SPHINCS+-SHA2-192f-simple, SPHINCS+SHA2-192s-simple,
SPHINCS+-SHA2-256f-simple, SPHINCS+-
SHA2-256s-simple.
• SPHINCS+-SFIAKE: SPHINCS+-SHAKE-128f-simple,SPHINCS+SHAKE-128s-simple,
SPHINCS+-SHAKE-192f-simple, SPHINCS+SHAKE-192s-simple,
SPHINCS+-SHAKE-256f-simple, SPHINCS+-
SHAKE-256s-simple.
25
4. Q U A N T U M SAFE V P N
4.2 Integration of PQC Algorithms with OpenVPN
4.2.1 Technical Integration
The technical integration of liboqs with OpenV P N involves systematically
replacing existing cryptographic components within the OpenV
P N codebase with their post-quantum counterparts. This integration
primarily focuses on incorporating the K E M Kyber for secure key
establishment and the Dilithium, FALCON, and Sphincs digital signature
algorithms. Understanding the structure of OpenSSL is crucial for
this process, as it serves as the foundation for secure communication
via the TLS protocol.
The integration of liboqs with OpenSSL is made through the oqsprovider,
a crucial component enabling the incorporation of postquantum
cryptographic algorithms into OpenSSL framework. The
oqs-provider operates with non-post-quantum algorithms as well,
ensuring the continued utilization of established standards and algorithms
like X.509, PKCS, or CMS implemented within OpenSSL, thus
maintaining interoperability and compatibility with existing cryptographic
practices.
Applications
- ciphers j cms dgsl dhparam |
d 5ö 1 dsapararn | « 1
engine | errstr | gendsa | genpbey | genrsa | kdf |
.... i
Common
Services
Protocols
TLS Protocol* fflher Protocols
TIS DTLS stalemj record j
CMS OCSP PACKET
SSL BIO j Trace
T5
WPACKETJ
Legacy APIs
AE5 RSA DM
ENGINE ...
Default Null
Provider Provider
AE5 R5A
Base
Provider
FIPS Legacy
Provider Provider
FiPS
Algonthmi • • '.lui Linns
AES RSA
FiPSSuppot
POSTJLow Level
Impl
3rd Party
Provider
OOS
PROVIDER
Figure 4.1: Conceptual Components View of OpenSSL. Source: https:
//www.openssi.org/docs/OpenSSLStrategicArchitecture.html
26
4. Q U A N T U M SAFE V P N
Configuration and Compatibility
The integration process also involves configuring the OpenV P N server
and clients to utilize the post-quantum algorithms provided by liboqs.
Build liboqs by configuring with CMake and using Ninja as the
build system. Install the resulting binaries to the specified directory,
INSTALL directory.
Build OpenSSL, linking against liboqs. Version 3 or above is required,
since the concept of provider in OpenSSL was not available in
lower versions. Install the resulting binaries and libraries, then set the
PATH environment variable to include the OpenSSL binary executable.
Build the oqs-provider library, linking against OpenSSL. Copy
the resulting library to INSTALL/lib64/ossl-modules. Modify the
OpenSSL configuration file, openssl.cnf to activate and configure the
OQS Provider.
After building liboqs and OpenSSL, continue with the build of
OpenVPN:
- Set environment variables: Set OpenSSL directory to the INSTALL
directory to inform OpenVPN about the location of the
custom OpenSSL installation.
- Configure and build OpenVPN: Use the provided libtoolize,
aclocal, autoheader, automake, and autoconf commands to generate
build files. Configure OpenVPN with specific flags including
the path to OpenSSL headers and libraries. The CFLAGS
environment variable is set to include the OpenSSL directory
for the build. The resulting OpenVPN binary is installed in the
INSTALL directory.
Copy additional files: Copy additional files related to OpenVPN,
such as serverstart.sh, clientstart.sh, openvpn-openssl.cnf, server.config,
client.config, and createcerts_and_config.sh to INSTALL and OpenV
P N directory.
27
4. Q U A N T U M SAFE V P N
Pseudocode with Explanations
The detailed process of integrating liboqs with OpenSSL using the oqsprovider,
as well as the subsequent steps for building OpenV P N using
the modified OpenSSL, are explained in Appendix A , accompanied
by pseudocode.
Achievements
The successful integration of PQC algorithms into OpenSSL and OpenV
P N marks a significant milestone. OpenSSL has been integrated with
liboqs, enabling the utilization of PQC algorithms.
Table 4.1: Modified Protocols of V P N .
Algorithm type Existing classical Modified PQ
Key Exchange D H / E C D H (KEX) CRYSTALS Kyber
Digital Signature RSA CRYSTALS Dilithium
4.2.2 Testing and Validation
The integration process includes testing to validate the efficacy and
security of the modified OpenV P N implementation. Various test scenarios,
including interoperability testing with non-quantum-safe configurations,
performance testing, and security analysis, are conducted
to ensure the reliability and robustness of the quantum-safe V P N solution.
During testing, we employed a video conferencing (VC) solution
called Safe Link, hosted on a private network behind the Quantum-Safe
V P N (QS-VPN) server. The testing procedure followed these steps:
1. Deployment of QS-VPN server: Initially, the Quantum-Safe V P N
server was deployed with two network interface cards (NICs).
One NIC facilitated connections with Quantum Safe V P N clients,
while the other was connected to the Safe Link server.
2. Configuration of QS-VPN clients: Similarly, clients of the QSV
P N were configured in a manner consistent with the server
setup.
28
4. Q U A N T U M SAFE V P N
3. Generation and distribution of client credentials: The QS-VPN
server-generated key, certificate, and configuration files for clients,
which were then securely shared.
4. Establishment of QS-VPN connections: Clients utilized the provided
credentials to establish connections with the QS-VPN
server.
5. Management of client requests: The QS-VPN server efficiently
managed incoming requests from connected clients, including
requests to establish connections with the Safe Link VC server.
The configured QS-VPN operated similarly to OpenV P N , providing
all standard features while utilizing post-quantum algorithms from
liboqs.
4.2.3 Workflow
The detailed workflow, including the QS-VPN server setup, connection
to the Safe Link server, the establishment of V P N connections from
QS-VPN clients, and hosting of video conferences through the V P N
tunnel, is described in Appendix B.
29
5 Performance Analysis of QS-VPN
After the successful integration of the PQC algorithms with Open VPN,
we carried out performance analysis. The QS-VPN and OpenV P N were
compared for performance in terms of bandwidth, jitter, bit-rate, and
lost/total datagram. The study was conducted using iPerf3 [27] which
is an open-source network performance and speed test measurement
tool. This section includes an overview of how we evaluated the impact
of PQC on our experimental configuration and a discussion of the
results.
5.1 Experiment Setup
A client-server setup was done for the experiment, where both entities
were directly connected via L A N cables. One PC functioned as the
V P N server, serving both OpenV P N and QS-VPN, while the other
acted as the V P N client. In both scenarios, we utilized T U N (network
TUNnel) to establish the V P N connection between the server and the
client. T U N operates at layer 3 of the OSI model, simulating a network
layer device. Data encryption was implemented using the AES-256G
C M cipher, while SHA-256 was employed for authentication.
Details of both the server and client are specified below.
1. Server was installed in a system having configurations:
• Platform: Ubuntu 22.04.3 LTS.
• Kernel: Linux-6.5.0-26-generic.
• Architecture: x86_64.
• Compiler: gcc/g++(11.4.0).
• C P U :
- Model name: Intel Xenon Silver 4214R C P U @ 2.40GHz.
- Number of cores: 8.
30
5. PERFORMANCE ANALYSIS OF Q S - V P N
2. Client was installed in a system having configurations:
• Platform: Ubuntu 20.04.6 LTS.
• Kernel: Linux-5.15.0-101-generic.
• Architecture: x86_64.
• Compiler: gcc/g++(9.4.0).
• C P U :
- Model name: Intel(R) Core(TM) 13-6100 CPU @ 3.70GHz.
- Number of cores: 4.
5.2 Performance Testing Using iPerf3
5.2.1 OpenVPN Performance
Initially, the V P N connection is established, followed by the exchange
of ICMP echo requests through the tunnel to assess connectivity. All
certificates and keys are generated using easy-RSA, and E C D H serves
as the key exchange algorithm in TLS 1.3.
We conducted a dual-test measurement utilizing iPerf3, spanning
a duration of 10 seconds with 1-second intervals. This test employed
the U D P protocol, with the iPerf3 server and client both operating on
the virtual IP of OpenVPN.
The results obtained in the case of OpenVPN are described in Table
5.1.
31
5- PERFORMANCE ANALYSIS OF Q S - V P N
Table 5.1: iPerf Dual Testing of OpenVPN.
Role
Interval Transfer Bitrate Jitter Lost/Total
Role
(sec) (KB) (Mb/sec) (msec) Datagrams
TX 0.00 -1.00 134 1.09 23
RX 0.00 -1.00 134 1.09 0.785 0/23 (0%)
TX 1.00 - 2.00 128 1.05 22
RX 1.00 - 2.00 128 1.05 0.326 0/22 (0%)
TX 2.00 - 3.00 128 1.05 22
RX 2.00 - 3.00 128 1.05 0.318 0/22 (0%)
TX 3.00 - 4.00 128 1.05 22
RX 3.00 - 4.00 134 1.09 0.202 0/23 (0%)
TX 4.00 - 5.00 128 1.05 22
RX 4.00 - 5.00 128 1.05 0.166 0/22 (0%)
TX 5.00 - 6.00 128 1.05 22
RX 5.00 - 6.00 128 1.05 0.209 0/22 (0%)
TX 6.00 - 7.00 128 1.05 22
RX 6.00 - 7.00 128 1.05 0.204 0/22 (0%)
TX 7.00 - 8.00 128 1.05 22
RX 7.00 - 8.00 128 1.05 0.270 0/22 (0%)
TX 8.00 - 9.00 128 1.05 22
RX 8.00 - 9.00 128 1.05 0.856 0/22 (0%)
TX 9.00-10.00 128 1.05 22
RX 9.00-10.00 128 1.05 0.369 0/22 (0%)
• Results:
- Transfer: 1.25 MBytes in 10 seconds.
- Bitrate: 1.05 Mbits/sec.
- Jitter: Maximum jitter observed was 0.856 ms.
- Datagrams lost/total: No datagrams lost during the test.
• CPU Utilization:
- Local sender (TX): 3.2% (0.2% user, 2.9% system).
- Remote receiver (RX): 29.7% (6.0% user, 23.7% system).
- Reverse C P U utilization figures were also observed.
32
5. PERFORMANCE ANALYSIS OF Q S - V P N
Overall, the test achieved a bitrate of 1.05 Mbits/sec over U D P with a
maximum jitter value of 0.856 ms and no packet loss. CPU utilization
on the remote receiver side was notably higher compared to the local
sender side during the test.
5.2.2 QS-VPN Performance
In the configuration for QS-VPN, the same setup as OpenV P N is utilized.
However, unlike easy-RSA, the OpenSSL x509 command is employed
to generate post-quantum certificates. Additionally, CRYSTALS
Kyber is selected as the key exchange algorithm in TLS 1.3. The results
obtained in the case of QS-VPN are as follows.
Table 5.2: iPerf Dual Testing of QSVPN.
Role
Interval Transfer Bitrate Jitter Lost/Total
Role
(sec) (KB) (Mb/sec) (msec) Datagrams
TX 0.00 -1.00 134 1.09 23
RX 0.00 -1.00 134 1.09 0.785 0/23 (0%)
TX 1.00 - 2.00 128 1.05 22
RX 1.00 - 2.00 128 1.05 0.657 0/22 (0%)
TX 2.00 - 3.00 128 1.05 22
RX 2.00 - 3.00 128 1.05 0.316 0/22 (0%)
TX 3.00 - 4.00 128 1.05 22
RX 3.00 - 4.00 128 1.05 0.242 0/22 (0%)
TX 4.00 - 5.00 128 1.05 22
RX 4.00 - 5.00 134 1.09 0.394 0/23 (0%)
TX 5.00 - 6.00 128 1.05 22
RX 5.00 - 6.00 122 1.00 2.037 0/21 (0%)
TX 6.00 - 7.02 128 1.03 22
RX 6.00 - 7.02 122 0.98 11.817 0/21 (0%)
TX 7.02 - 8.00 128 1.06 22
RX 7.02 - 8.00 139 1.16 5.250 0/24 (0%)
TX 8.00 - 9.00 128 1.05 22
RX 8.00 - 9.00 128 1.05 1.384 0/22 (0%)
TX 9.00-10.00 128 1.05 22
RX 9.00-10.00 128 1.05 0.501 0/22 (0%)
33
5. PERFORMANCE ANALYSIS OF Q S - V P N
Results:
- Transfer: 1.25 MBytes in 10 seconds.
- Bitrate: 1.05 Mbits/sec.
- Jitter: Maximum jitter observed was 11.817 ms.
- Datagrams lost/total: No datagrams lost during the test.
CPU Utilization:
- Local sender (TX): 4.7% (0.5% user, 4.2% system).
- Remote receiver (RX): 30.2% (6.1% user, 24.1% system)..
- Reverse C P U utilization figures were also observed.
Overall, the test achieved a bitrate of 1.05 Mbits/sec over UDP with a
maximum jitter value of 11.817 ms and no packet loss. CPU utilization
on the remote receiver side was notably higher compared to the local
sender side during the test.
5.2.3 Comparative Analysis of iPerf Reports
In the conducted iPerf3 test, both OpenVPN and QS-VPN exhibited
comparable performance metrics. OpenVPN achieved a bitrate of 1.05
Mbits/sec with a maximum jitter of 0.856 ms and no packet loss, while
QS-VPN achieved a similar bitrate of 1.05 Mbits/sec with maximum
jitter of 11.817 ms and also no packet loss. Also, the transfer size
remained consistent between both tests at 1.25 MBytes.
Examining C P U utilization, in OpenVPN, the local sender exhibited
a C P U utilization of 3.2% (0.2% user, 2.9% system), whereas the
remote receiver displayed a substantially higher C P U utilization of
29.7% (6.0% user, 23.7% system). Comparatively, in QS-VPN, the local
sender demonstrated a slightly increased C P U utilization of 4.7%
(0.5% user, 4.2% system), and the remote receiver showcased a similar
C P U utilization of 30.2% (6.1% user, 24.1% system).
OpenVPN and QS-VPN exhibited nearly identical performance in
terms of bitrate, achieving 1.05 Mbits/sec with no packet loss in both
cases. This suggests that both V P N protocols are capable of handling
data transfer rates effectively under the test conditions. However, there
34
5. PERFORMANCE ANALYSIS OF Q S - V P N
were noticeable differences in jitter, which measures the variability in
packet arrival times. OpenV P N recorded a maximum jitter of 0.856
ms, while QS-VPN exhibited a higher maximum jitter of 11.817 ms.
The difference in jitter indicates that QS-VPN may introduce more
variability in packet delivery times, which could be detrimental for
real-time applications such as VoIP or online gaming that require
consistent packet timing.
Examining C P U utilization provides deeper insights into the efficiency
and resource demands of each V P N protocol. For OpenVPN, the
local sender's CPU utilization was relatively low, at 3.2% overall (0.2%
user and 2.9% system). However, the remote receiver experienced a
substantially higher C P U load, with total utilization reaching 29.7%
(6.0% user and 23.7% system). This high CPU demand on the receiver
side suggests that OpenVPN's encryption and decryption processes
are particularly resource-intensive, which could impact performance
on devices with limited processing power.
In comparison, QS-VPN showed a slightly higher C P U utilization
on the local sender at 4.7% overall (0.5% user and 4.2% system), indicating
that it imposes a marginally greater computational burden
on the sender side than OpenV P N . O n the receiver side, QS-VPN's
CPU utilization was quite similar to that of OpenVPN, at 30.2% overall
(6.1% user and 24.1% system). This suggests that both V P N protocols
demand a comparable level of processing power from the receiver.
The results highlight that while both OpenVPN and QS-VPN can
handle similar bitrates without packet loss, the higher jitter observed
with QS-VPN could be problematic for applications sensitive to timing
variability. The choice between OpenVPN and QS-VPN will depend
on specific use cases and security requirements.
5.3 Session Establishment in TLS 1.3
For session establishment and observing the time taken for the key
exchange mechanism in TLS 1.3, the similar server-client architecture
described in Section 5.1 was followed. In this case, we utilize OpenSSL
s_server and s_client tools on the respective endpoints.
5.3.1 s_server Log
35
5. PERFORMANCE ANALYSIS OF Q S - V P N
Starting OpenSSL s_server on port 4433...
ACCEPT
BEGIN SSL SESSION PARAMETERS
MIGDAgEBAglDBAQCEwIEIMsJkBge01gEIZaZc8NqA/l
HPqT9xlX37G31hF6ITYs3
BDAzUQ2RL4aSoFDNak41Za9avuoICkXUs6RLTqctP/
uLVlNlDyIofQsAL2oyVLD3w
4+ihBgIEZj8ThKIEAgIcIKQGBAQBAAAArgYCBEUPmb6zBAICAjw=
END SSL SESSION PARAMETERS
Shared ciphers:TLS_AES_256_GCM_SHA384
Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:ECDSA+
SHA512:Ed25519:Ed448:ECDSA+SHA256:ECDSA+SHA384:ECDSA+
SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA
-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:
RSA+SHA384:RSA+SHA512:dilithium2:p256_dilithium2:
rsa3072_dilithium2:dilithium3:p384_dilithium3:
dilithium5:p521_dilithium5:falcon512:p256_falcon512:
rsa3072_falcon512:falconl024:p521_falconl024:
sphincssha2128fsimple:p256_sphincssha2128fsimple:
rsa3072_sphincssha2128fsimple:sphincssha2128ssimple:
p256_sphincssha2128ssimple:
rsa3072_sphincssha2128ssimple:sphincssha2192fsimple:
p384_sphincssha2192fsimple:sphincsshakel28fsimple:
p256_sphincsshakel28fsimple:
rsa3072_sphincsshakel28fsimple
Shared Signature Algorithms: ECDSA+SHA256:ECDSA+SHA384:
ECDSA+SHA512:Ed25519:Ed448:ECDSA+SHA256:ECDSA+SHA384:
ECDSA+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+
SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA
+SHA256:RSA+SHA384:RSA+SHA512:dilithium2:
p256_dilithium2:rsa3072_dilithium2:dilithium3:
p384_dilithium3:dilithium5:p521_dilithium5:falcon512:
p256_falcon512:rsa3072_falcon512:falconl024:
p521_falconl024:sphincssha2128fsimple:
p256_sphincssha2128fsimple:
rsa3072_sphincssha2128fsimple:sphincssha2128ssimple:
p256_sphincssha2128ssimple:
36
5- PERFORMANCE ANALYSIS OF Q S - V P N
rsa3072_sphincssha2128ssimple:sphincssha2192fsimple:
p384_sphincssha2192fsimple:sphincsshakel28fsimple:
p256_sphincsshakel28fsimple:
rsa3072_sphincsshakel28fsimple
Supported groups: kyber768:p384_kyber768
Shared groups: kyber768:p384_kyber768
CIPHER is TLS_AES_256_GCM_SHA384
Listing 5.1: s_server Log.
5.3.2 s_client Log for RSA Signature Algorithm
Connecting to 192.168.0.57 # ip address of s_server
Can't use SSL_get_servername
depth=l CN = opstest CA
verify return:1
depth=0 CN = opsserver
verify return:1
CONNECTED(00000003)
Certificate chain
0 s:CN = opsserver
i:CN = opstest CA
a:PKEY: rsaEncryption,
v:NotBefore: Nov 16 05
05:14:46 2024 GMT
1 s:CN = opstest CA
i:CN = opstest CA
a:PKEY: rsaEncryption,
v:NotBefore: Nov 16 05
05:14:46 2024 GMT
Server certificate
BEGIN CERTIFICATE—
MIIDbDCCAlSgAwIBAgIRAIEKIx07u/+eN0t0r08G
aU15yyArYx5TizQ09xdXHg==
END CERTIFICATE
2048 (bit); sigalg: RSA-SHA256
:14:46 2023 GMT; NotAfter: Nov 9
2048 (bit); sigalg: RSA-SHA256
:14:46 2023 GMT; NotAfter: Nov 9
37
5- PERFORMANCE ANALYSIS OF Q S - V P N
subject=CN = opsserver
issuer=CN = opstest CA
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
SSL handshake has read 2285 bytes and written 305 bytes
Verification: OK
New, TLSvl.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
DONE
Session Establishment Time: 31.283376000 ms
Listing 5.2: s_client Log: For RSA Signature Algorithm.
5.3.3 s_client Log for Dilithium3 Signature Algorithm
Connecting to 192.168.0.57 # ip address of s_server
Can't use SSL_get_servername
depth=l CN=qsvpn CA
verify return:1
depth=0 CN=qsvpnserver
verify return:1
CONNECTED(00000003)
Certificate chain
0 s:CN=qsvpnserver
i:CN=qsvpn CA
38
5- PERFORMANCE ANALYSIS OF Q S - V P N
a:PKEY: UNDEF, 192 (bit);
v:NotBefore: Nov 15 07:42
07:42:17 2024 GMT
1 s:CN=qsvpn CA
i:CN=qsvpn CA
a:PKEY: UNDEF, 192 (bit);
v:NotBefore: Nov 15 07:42
07:42:17 2024 GMT
Server certificate
BEGIN CERTIFICATE
MIIVqTCCCLSgAwIBAgIUS0pQEKXC6A/D2PJE0TAYhv ...
END CERTIFICATE—
subj ect=CN=qsvpnserver
issuer=CN=qsvpn CA
No client certificate CA names sent
Peer signature type: dilithium3
SSL handshake has read 15724 bytes and written 1483 bytes
Verification: OK
New, TLSvl.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 192 bit
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
DONE
Session Establishment Time: 16.943345000 ms
Listing 5.3: s_client Log: For Dilithium3 Signature Algorithm.
sigalg: dilithium3
•11 2023 GMT; NotAfter: Nov 9
sigalg: dilithium3
.11 2023 GMT; NotAfter: Nov 9
39
5. PERFORMANCE ANALYSIS OF Q S - V P N
5.3.4 Analysis of Session Establishment
Regarding peer signing digest and signature type, s_client log for
RSA-2048 specifies SHA256 as the peer signing digest and RSA-PSS as
the signature type. While s_client log for Dilithium3 specifies SHA256
as the peer signing digest and Dilithium3 as the signature type.
In terms of server public key and cipher, RSA-2048 utilizes a longer
2048-bit server public key with the TLS_AES_256_GCM_SHA384 cipher,
while Dilithium3 employs a shorter 192-bit server public key
with the same cipher.
Dilithium3 demonstrates a shorter session establishment time of
16.94 ms as compared to RSA-2048, which took 31.28 ms.
40
6 Performance Benchmarking of PQC Algo-
rithms
NIST has shortlisted CRYSTALS Kyber for K E M and CRYSTALS Dilithium,
F A L C O N and SPHINCS+ for the digital signature. For the comparative
analysis of these algorithms, they were implemented separately
on QS-VPN. Thereafter, a comprehensive performance measurement
with respect to key/certificate generation, signing, and verification
was carried out. The key sizes of all the variants are also compared
and finally, the possible use cases and applications for each variant
are discussed.
L A N environment was used for throughput tests. Both TCP and UDP
protocols were used. The setup was as follows.
• QS-VPN Server is installed in a system having configurations:
1. Platform: Ubuntu 22.04.3 LTS.
2. Kernel: Linux-6.5.0-26-generic.
3. Architecture: x86_64.
4. Compiler: gcc/g++(11.4.0).
5. CPU Model name: Intel Xenon Silver 4214R CPU @ 2.40GHz
with 8 cores.
• QS-VPN Client is installed in a system having configurations :
1. Platform: Ubuntu 20.04.6 LTS.
2. Kernel: Linux-5.15.0-101-generic.
3. Architecture: x86_64.
4. Compiler: gcc/g++(9.4.0).
5. CPU Model name: Intel Core i3-6100 CPU @ 3.70GHz with
4 cores.
41
6. PERFORMANCE BENCHMARKING OF P Q C ALGORITHMS
6.1 CRYSTALS Kyber Variants
Speed test for various time intervals was undertaken using oqsspeed
test and OpenSSL speed test for Kyber512, Kyber 768, and Kyber 1024.
The time taken for key generation, encapsulation, and decapsulation
were measured. The C P U cycles for each process were also measured.
A bar graph for comparative analysis is created and appended below.
Table 6.1: CRYSTALS Kyber Algorithm Performance with Respect to
Number of C P U Cycles.
Algorithm Key Gen Encaps Decaps
CRYSTALS Kyber512 45488 46592 28984
CRYSTALS Kyber768 64498 67204 46155
CRYSTALS Kyberl024 81000 87970 64567
Decapsulations/sec -
Encapsulations/s
Keypair generations/s -
56,778.2
82,194.9
i r
1.31 • 105
43,972.6
61,536.1
94,760.2
43,496.4
50,331.4
83,629.1
• Kyber 512
• Kyber 768
• Kyber 1024
20K 40K 60K 80K 100K 120K 140K 160K
Figure 6.1: Performance Graph of Kyber Variants with Respect to Key
Pair Generation, Encapsulation & Decapsulation.
42
6. PERFORMANCE BENCHMARKING OF P Q C ALGORITHMS
6.2 CRYSTALS Dilithium Variants
Speed test for various time intervals was undertaken using oqsspeed
test and OpenSSL Speed test for Dilithium2, Dilithium3, and Dilithium5.
Time taken for keypair generation, signing, and verification were measured.
The C P U cycles for each process were also measured. A bar
graph for comparative analysis is appended below.
Table 6.2: Dilithium Algorithm Performance with Respect to Number
of C P U Cycles.
Algorithm Keypair Gen Sign Verify
Dilithium2 104577 260743 93466
Dilithium3 173498 415501 155689
Dilithium5 266847 510580 246772
Verifications/s -
Signatures/s
Keypair generations/s -
14,701.4
22,977.9
39,495.1
6,963.7
8,992.5
14,609.4
13,118.3
20,614.8
• Dilithium 2
• Dilithium 3
• Dilithium 5
32,895.5
10K 15K 20K 25K 30K 35K 40K
Figure 6.2: Performance Graph of Dilithium Variants with Respect to
Key Pair Generation, Signing, and Verification.
43
6. PERFORMANCE BENCHMARKING OF P Q C ALGORITHMS
Analysis: The speed is much faster, and the size is much smaller
when compared to hash-based methods like the SPHINCS+ scheme.
It is easier to implement because it does not need Gaussian sampling.
6.3 FALCON Variants
Speed test for various time intervals was undertaken using oqsspeed
test and OpenSSL Speed test for F A L C O N 512, and F A L C O N 1024.
The time taken for keypair generation, signing, and verification were
measured. The C P U cycles for each process were also measured. A
bar graph for comparative analysis is created and provided below.
Table 6.3: FALCON Algorithm Performance with Respect to Number
of C P U Cycles.
Algorithm Keypair Gen Sign Verify
FALCON-512 25757907 961767 157175
FALCON-1024 79509676 1862294 320076
Verifications/s
Signatures/s
Keypair generations/s
11,441.7
23,576.9
1,963.3
3,991
• FALCON 512
44.7
• FALCON 1024
141.9
5K 10K 15K 20K 25K
Figure 6.3: Performance Graph of F A L C O N Variants with Respect to
Key Pair Generation, Signing, and Verification.
44
6. PERFORMANCE BENCHMARKING OF P Q C ALGORITHMS
F A L C O N provides a fast and efficient signing and verification
process, especially on modern hardware, due to its optimized latticebased
techniques.
6.4 SPHINCS+Variants
Speed test for various time intervals was undertaken using the oqsspeed
test and OpenSSL speed test for SPHINCS+-SHA2-128f-simple, SPHINCS+SHA2-128s-simple,
SPHINCS+-SHA2-192f-simple, SPHINCS+-SH AKE-
128f- simple. Time taken for keypair generation, signing, and verification
were measured. The C P U cycles for each process were also
measured.
Table 6.4: SPHINCS+ Algorithm Performance with Respect to Number
of C P U Cycles.
Algorithm Keypair Gen Sign Verify
SPHINCS+-SHA2-128f-simple 1176418 27876574 2360601
SPHINCS+-SHA2-128s-simple 76038796 568502277 894295
SPHINCS+-SHA2-192f-simple 1775315 47856734 3385654
SPHINCS+-SHAKE-128f-simple 2297009 53822094 3669628
Verifications/s
1,014.4
3,409.2
1,432
Signatures/s
P 62.9
] 77.6
6.6
• 131.7
• SPHINCS+-SHA2-128f-simple
• SPHINCS+-SHA2-128s-simple
• SPHINCS+-SHA2-192f-simple
I SPHINCS+-SHAKE-128f-simple
1,512.5
Keypair generations/s
H I 2,067.7
] 49.9
J 3,013.3
i i i i i i i
500 I K 1.5K 2K 2.5K 3K 3.5K
Figure 6.4: Performance Graph of SPHINCS+ Variants with Respect
to Key Pair Generation, Signing, and Verification.
45
6. PERFORMANCE BENCHMARKING OF PQC ALGORITHMS
SPHINCS+ does not prioritize being the fastest or the smallest in
computational speed or size but strikes a balance between these aspects,
providing flexibility to cater to diverse application requirements.
Notably, it offers compact public keys, advantageous for scenarios involving
frequent public key transmission. Moreover, its compatibility
with the extended Merkle signature scheme (XMSS) enables seamless
integration, particularly beneficial for applications like VPNs.
The scheme also benefits from speed enhancements in its underlying
hash functions, directly translating to performance improvements in
SPHINCS+.
6.5 Comparison of All PQ Digital Signature Schemes
at NIST Security Level LI, L3, L5
Verifications/s Keypair
generations/s |
909.9
I
• 3,409.2
• 1,432
1 23,576.9
62.9
6.6
| 131.7
[] FALCON-512• 3,991 [] FALCON-512
[] SPHINCS+-SHA2-128f-simple
• 1,512.5 [] SPHINCS+-SHA2-128s-simple
49.9 | SPHINCS+-SHAKE-128f-simple
| 3,013.3
141.9
1 1
0 5K 10K 15K 20K
Figure 6.5: Comparison of A l l PQ Digital Signature Schemes at NIST
Security Level LI.
46
6. PERFORMANCE BENCHMARKING OF P Q C ALGORITHMS
Verifications/s ]
1,014.4
Signatures/s
Keypair generations/s
22,977.9
77.6
8,992.5
7] Dilithium 3
[] SPHINCS+-SHA2-192f-simple
2,067.7
20,614.8
J L
5K 10K 15K 20K 25K
Figure 6.6: Comparison of A l l P Q Digital Signature Schemes at NIST
Security Level L3.
Verifications/s -
Signatures/s
Keypair generations/s
11,441.7
14,701.4
1,963.3
6,963.7
7J Dilithium 5
[] FALCON-1024
44.7
13,118.3
5K 10K 15K
Figure 6.7: Comparison of A l l P Q Digital Signature Schemes at NIST
Security Level L5.
47
6. PERFORMANCE BENCHMARKING OF P Q C ALGORITHMS
6.6 Analysis
Key sizes: The public keys of the two lattice-based algorithms (CRYSTALSDilithium
and FALCON) have comparable sizes (as mentioned in
table 2.2 and 2.3), whereas SPHINCS+ stands out with a significantly
shorter public key length (as mentioned in table 2.4). However, it is
worth noting that SPHINCS+ also has the largest signature length.
Security level: SPHINCS+ offers the smallest public key size which is
advantageous for devices with limited storage capacity.
Performance speed: Dilithium excels in key generation and signing
speed, while F A L C O N is optimal for fast signature verification.
Computational efficiency: Dilithium consistently demonstrated superior
computational efficiency, positioning it as an excellent choice for
systems with limited processing power. In contrast, FALCON excelled
in signature verification speed, although it demands more computational
resources for key generation. SPHINCS+, while the most computationally
demanding algorithm, provides the flexibility to adjust
between computational efficiency and security parameters. Certain
hardware-accelerated hashing solutions could bring further optimiza-
tion.
Applicability on constrained platforms: Dilithium and F A L C O N are
better suited for devices like IoT sensors, whereas SPHINCS+ may
face challenges due to its larger computational requirements.
Dilithium demonstrates remarkable versatility and computational
efficiency, making it suitable for embedded systems and IoT devices.
Its low energy consumption and computational demands enhance its
usage. O n the other hand, F A L C O N , while experiencing somewhat
cumbersome key generation, stands out as an excellent choice for environments
prioritizing high throughput and low latency. Its rapid
signature verification capability makes it especially suitable for IoT
platforms with R A M constraints. However, its higher computational
costs make it less desirable for smart card deployments. In contrast,
SPHINCS+ offers a high level of security customization but at the
48
6. PERFORMANCE BENCHMARKING OF P Q C ALGORITHMS
expense of computational speed and energy efficiency This trade-off
makes it a viable option for specific IoT configurations but limits its
utility in smart cards due to less efficient performance and larger signature
size. The computational load imposed by hashing operations
in these algorithms, notably in SPHINCS+, suggests the potential for
optimization through hardware-accelerated hashing solutions. These
considerations underscore the importance of context-specific evaluations
when selecting algorithms, considering the trade-offs between
computational efficiency and security.
49
7 Conclusion and Future Work
In this chapter, we will provide a summary of our thesis contribution,
focusing on the implementation and benchmarking of the quantumsafe
VPN. Additionally, we will explore potential future research work
in this field.
7.1 Thesis Contribution
In conclusion, our research journey encompassed the study of PQC,
adhering to NIST PQC standardization guidelines. We explored the
practical application of these cryptographic algorithms in real-world
scenarios, leading us to their potential integration with the TLS 1.3 protocol,
particularly within the context of VPNs. We compared between
IPSec and SSL-based VPNs and selected OpenV P N as our platform
of choice. Recognizing the reliance of OpenV P N on OpenSSL for TLS
1.3 establishment, we integrated PQC algorithms into OpenSSL using
liboqs and the oqs-provider. Subsequent testing and performance evaluation
of our modified V P N compared to existing implementations of
OpenV P N using conventional cryptographic algorithms like E C D H
and RSA. Overall, our work represents a significant step forward in
strengthening the security of V P N infrastructure against emerging
quantum threats.
7.2 Future Work
The integration of PQC algorithms into TLS1.3 in OpenSSL opens up
many possibilities for future development and deployment. Here are
some potential avenues for future exploration:
• Quantum-safe server implementation: Building upon the modified
TLS1.3 implementation, there is an opportunity to create
dedicated quantum-safe servers that support post-quantum key
exchange mechanisms (KEMs) during session establishment
with clients. These servers would use P Q C algorithms for enhanced
security against quantum adversaries.
50
7. CONCLUSION A N D FUTURE W O R K
• Hybrid session establishment: Hybrid cryptographic mechanisms
can be employed to establish sessions between clients and
quantum-safe servers. By combining classical and post-quantum
cryptographic algorithms, hybrid protocols offer a transitional
approach to quantum-resistant security. Future research can
focus on optimizing and standardizing hybrid session establishment
protocols for widespread adoption.
51
Bibliography
[1] Miklos Ajtai. "The shortest vector problem in L2 is NP-hard for
randomized reductions". In: Proceedings of the thirtieth annual
ACM symposium on Theory of computing. 1998, pp. 10-19.
[2] Miklos Ajtai. "Generating hard instances of lattice problems".
In: Complexity 4.1 (1996), pp. 31-39.
[3] Jean-Philippe Aumasson et al. "SPHINCS+ : Submission to
the NIST post-quantum project, v.3.1". In: (2022). URL: https :
//sphincs.org/data/sphincs+-r3.l-specification.pdf.
[4] Daniel J Bernstein, Johannes Buchmann, and Erik Dahmen. "Introduction
to post-quantum cryptography". In: Post-Quantum
Cryptography (2009), pp. 1-14.
[5] Daniel J. Bernstein, Tanja Lange, and Christiane Peters. "Attacking
and Defending the McEliece Cryptosystem". In: PostQuantum
Cryptography. Ed. by Johannes Buchmann and Jintai
Ding. Berlin, Heidelberg: Springer Berlin Heidelberg, 2008,
pp. 31-46. ISBN: 978-3-540-88403-3.
[6] Johannes Blomer and Jean-Pierre Seifert. " O n the Complexity
of Computing Short Linearly Independent Vectors Problem
(SIVP)". In: ACM Digital Library (1999). URL: https://dl.acm.
org/doi/pdf.
[7] Joppe Bos et al. "CRYSTALS - Kyber: A CCA-secure modulelattice-based
K E M " . In: (2017). URL: https : / / e p r i n t . iacr .
org/2017/634.pdf.
[8] Joppe W. Bos et al. "Kyber: A CCA-Secure Module-Lattice-Based
K E M " . In: IEEE European Symposium on Security and Privacy
(EuroS&P) (2017).
[9] Zvika Brakerski et al. "Classical Hardness of Learning with
Errors". In: Proceedings of the forty-fifth annual ACM symposium
on Theory of Computing (STOC '13). June 2013, pp. 575-584. DOI:
10.1145/2488608.2488680.
[10] Johannes Buchmann, Erik Dahmen, and Michael Szydlo. "Hashbased
Digital Signature Schemes". In: Post-Quantum Cryptography.
Ed. by Daniel J. Bernstein, Johannes Buchmann, and Erik
Dahmen. Berlin, Heidelberg: Springer Berlin Heidelberg, 2009,
52
BIBLIOGRAPHY
pp. 35-93. URL: https://doi.org/10.1007/978-3-540-88702-
7_3.
[11] David Carrel and Dan Harkins. The Internet Key Exchange (IKE).
RFC 2409. Nov. 1998. DOI: 10 . 17487/RFC2409. URL: https : / /
www.rf c-editor.org/inf o/rfc2409.
[12] Wouter Castryck and Thomas Decru. An efficient key recovery
attack on SIDH. Cryptology ePrint Archive, Paper 2022/975.2022.
URL: https://eprint.iacr.org/2022/975.
[13] Cong Chen et al. NTRU Algorithm Specifications And Supporting
Documentation. Mar. 2019. URL: https : / / n t r u . org/f / n t r u -
20190330.pdf.
[14] Craig Costello, Patrick Longa, and Michael Naehrig. "Efficient
Algorithms for Supersingular Isogeny Diffie-Hellman". In: Advances
in Cryptology-CRYPTO 2016. Vol. 9814. 2016. ISBN: 978-3-
662-53017-7.
[15] Luca De Feo and Steven D Galbraith. 'Tsogeny-based quantumresistant
undetectable backdoors in cryptographic constructions".
In: IACR Cryptology ePrint Archive 2018 (2018), p. 625.
[16] Hellman Diffie. "New Directions in Cryptography". In: Institute
of Electrical and Electronics Engineers, 1976. URL: https: //ee.
Stanford.edu/~hellman/publications/24.pdf.
[17] Dilithium: Cryptographic Suitefor Algebraic Lattices, https: / / p q crystals.org/dilithium/index.shtml.
2021.
[18] Jintai Ding, Albrecht Petzoldt, and Dieter S. Schmidt. Multivariate
Public Key Cryptosystems. 2nd ed. Advances in Information
Security. Springer New York, NY, 2020, pp. XXV, 253. ISBN: 978-
1-0716-0985-9. URL: https : / / d o i . org/10 .1007/978-1-0716-
0987-3.
[19] Jintai Ding and Dieter Schmidt. "Multivariate public key cryptography".
In: Post-Quantum Cryptography. Springer. 2005, pp. 193-
241.
[20] Leo Ducas et al. "CRYSTALS - Dilithium: Digital Signatures
from Module Lattices". In: (2017). URL: https : / / e p r i n t . iacr.
org/2017/633.
[21] Wesley Eddy. Transmission Control Protocol (TCP). RFC 9293.
Aug. 2022. DOI: 10 . 17487/RFC9293. URL: https : / /www . rf c-
editor.org/info/rfc9293.
53
BIBLIOGRAPHY
[22] Rami Elkhatib et al. "Accelerated RISC-V for Post-Quantum
SIKE". In: IEEE Transactions on Circuits and Systems I: Regular
Papers 69.6 (2022), pp. 2490-2501. DOI: 10 . 1109/TCSI. 2022 .
3162626.
[23] Pasi Eronen et al. Internet Key Exchange Protocol Version 2 (IKEv2).
RFC 5996. Sept. 2010. DOI: 10 .17487/RFC5996. URL: https : / /
www.rf c-editor.org/inf o/rf c5996.
[24] Luca De Feo. A review ofisogeny based cryptography. AfricaCrypt,
Dakar. 2017. URL: https : //def eo . lu/docet/assets/slides/
2017-05-25-africacrypt.pdf.
[25] Roy T. Fielding and Julian Reschke. Hypertext Transfer Protocol
(HTTP/1.1): Semantics and Content. RFC 7231. June 2014. DOI:
10.17487/RFC7231. URL: https://www.rfc-editor.org/info/
rf c7231.
[26] S. Frankel and S. Krishnan. IP Security (IPsec) and Internet Key
Exchange (IKE) Document Roadmap. RFC 6071. Obsoletes RFC
2411. Internet Engineering Task Force (IETF), Feb. 2011. DOI:
10.17487/RFC6071. URL: https://www.rfc-editor.org/rfc/
pdfrfc/rfc6071.txt.pdf.
[27] iPerß. URL: https://iperf.fr/iperf-download.php.
[28] Tendayi Kamucheka et al. "Power-based Side Channel Attack
Analysis on PQC Algorithms". In: (2021). URL: https : / / e p r i n t .
iacr.org/2021/1021.pdf.
[29] S. Kent. IP Authentication Header. RFC 4302. Obsoletes RFC 2402.
Network Working Group, Dec. 2005. URL: https : / /www. i e t f .
org/rfc/rfc4302.txt.
[30] S. Kent. IP Encapsulating Security Payload (ESP). RFC 4303. Obsoletes
RFC 2406. Network Working Group, Dec. 2005. URL: https:
//datatracker.ietf.org/doc/html/rfc4303.
[31] Neal Koblitz. "Elliptic curve cryptosystems". In: Mathematics of
Computation 48.177 (1987), pp. 203-209.
[32] Svetlana Korabelshchikova et al. "Linear codes and some their
applications". In: Journal of Physics: Conference Series 1096 (Dec.
2018), p. 012174. DOI: 10.1088/1742-6596/1096/1/012174.
[33] P. J. Lee and E. F. Brickell. " A n Observation on the Security of
McEliece's Public-Key Cryptosystem". In: Advances in Cryptology
— EUROCRYPT '88. Ed. by D. Barstow et al. Berlin, Heidelberg:
54
BIBLIOGRAPHY
Springer Berlin Heidelberg, 1988, pp. 275-280. ISBN: 978-3-540-
45961-3.
[34] Tsutomu Matsumoto and Hideki Imai. "Public key cryptosystems
using the modular group". In: IEICE TRANSACTIONS
(1976-1990) 71.7 (1988), pp. 740-747.
[35] D. Maughan et al. Internet Security Association and Key Management
Protocol (ISAKMP). RFC 2408. Network Working Group,
Nov. 1998. URL: h t t p s : / / w w w . r f c - e d i t o r . o r g / r f c / p d f r f c /
rfc2408.txt.pdf.
[36] Robert McElice. McElice Cryptosystem. 1978. URL: https : / / e n .
wikipedia.org/wiki/McEliece_cryptosystem.
[37] Robert J McEliece. " A public-key cryptosystem based on algebraic
coding theory". In: DSN progress report 44.114 (1978),
pp. 114-116.
[38] Ralph C Merkle. " A certified digital signature". In: Conference
on the Theory and Application of Cryptography. Springer. 1979,
pp. 218-238.
[39] Daniele Micciancio and Shafi Goldwasser. "Closest Vector Problem".
In: Complexity of Lattice Problems: A Cryptographic Perspective.
Boston, MA: Springer US, 2002, pp. 45-68. ISBN: 978-1-4615-
0897-7. URL: https : / / d o i . org/10 . 1007/978-1-4615-0897-
7_3.
[40] Daniele Micciancio and Shafi Goldwasser. "Shortest Vector Problem".
In: Complexity of Lattice Problems: A Cryptographic Perspective.
Boston, MA: Springer US, 2002, pp. 69-90. ISBN: 978-1-4615-
0897-7. URL: https : / / d o i . org/10 . 1007/978-1-4615-0897-
7_4.
[41] Daniele Micciancio and Oded Regev. Lattice-based Cryptography.
URL: https://cims.nyu.edu/~regev/papers/pqc.pdf.
[42] Michele Mosca. Quantum-safe cryptography and security. Springer,
2018.
[43] A. M . Odlyzko. "Discrete logarithms in finite fields and their
cryptographic significance". In: Advances in Cryptology. Ed. by
Thomas Beth, Norbert Cot, and Ingemar Ingemarsson. Berlin,
Heidelberg: Springer Berlin Heidelberg, 1985, pp. 224-314. ISBN:
978-3-540-39757-1.
55
BIBLIOGRAPHY
[44] Raphael Overbeck and Nicolas Sendrier. "Code-based cryptography".
In: Post-Quantum Cryptography. Ed. by Daniel J. Bernstein,
Johannes Buchmann, and Erik Dahmen. Berlin, Heidelberg:
Springer Berlin Heidelberg, 2009, pp. 95-145. ISBN: 978-
3-540-88702-7. URL: https : / / d o i . org/10 . 1007/978-3-540-
88702-7_4.
[45] J. Postel. User Datagram Protocol. RFC 768. ISI, Aug. 1980. URL:
https://www.ietf.org/rfc/rfc768.txt.
[46] T. Prest et al. Falcon. Tech. rep. Post-Quantum Cryptography
Project of NIST, 2022.
[47] Prasanna Ravi et al. "Machine Learning based Blind Side-Channel
Attacks on PQC-based KEMs - A Case Study of Kyber K E M " .
In: (2024). URL: https://eprint.iacr.org/2024/169.pdf.
[48] Oded Regev. "Lattices in Computer Science". In: Lecture Notes
(2009). URL: https : //www . cs . tau. ac . il/~odedr/teaching/
l a t t i c e s jfall_2004/index.html.
[49] Oded Regev. "The Learning with Errors Problem (Invited Survey)".
In: June 2010, pp. 191-204. DOI: 10.1109/CCC.2010.26.
[50] Eric Rescorla. The Transport Layer Security (TLS) Protocol Version
1.3. RFC 8446. Aug. 2018. URL: https://www.rfc-editor.org/
info/rfc8446.
[51] Ronald L. Rivest, A d i Shamir, and Leonard M . Adleman. " A
Method for Obtaining Digital Signatures and Public-Key Cryptosystems".
In: Communications of the ACM 21.2 (1978), pp. 120-
126.
[52] Alexei Rostovtsev and Anton Stolbunov. "Hard homogeneous
spaces". In: (2006).
[53] Peter W. Shor. "Polynomial-Time Algorithms for Prime Factorization
and Discrete Logarithms on a Quantum Computer". In:
SIAM Journal on Computing 26.5 (1997), pp. 1484-1509.
[54] Daniel Shumow. "Isogenies of Elliptic Curves: A Computational
Approach". In: (Oct. 2009).
[55] D. Smith-Tone. " O n the Differential Security of Multivariate
Public Key Cryptosystems". In: PQCrypto 2011: The 4th International
Conference on Post-Quantum Cryptography. Accessed April
24, 2024. Taipei, 2011. URL: https : / / d o i . org/10 .1007/978-3-
642-25405-5 9.
56
BIBLIOGRAPHY
[56] Vikas Srivastava, Anubhab Baksi, and Sumit Kumar Debnath.
An Overview of Hash Based Signatures. Cryptology ePrint Archive,
Paper 2023/411. 2023. URL: https : / / e p r i n t . iacr . org/2023/
411.
[57] Jacques Stern. " A method for finding codewords of small weight".
In: Coding Theory and Applications. Ed. by Gerard Cohen and
Jacques Wolfmann. Berlin, Heidelberg: Springer Berlin Heidelberg,
1989, pp. 106-113. ISBN: 978-3-540-46726-7.
[58] Xu G. & Yu Y Wang X. Lattice-Based Cryptography: A Survey. 2023,
pp. 945-960. URL: https : / / d o i . org/10 . 1007/sll401-023-
0053-6.
57
A APPENDIX
Pseudo code:
• Install essential build tools and libraries for building compo-
nents:
# install required libraries or dependencies •
sudo apt install -y \
1 ibtool automake autoconf cmake ninja-build \
make \
openssl libssl-dev pkg-config libcap-ng-dev \
procps vim net-tools iputils-ping \
1 iblzo2-dev liblzo2-2 libpamOg-dev python3-docutils \
libnl-3-dev libnl-genl-3-dev libnl-3-200 libnl-genl-3-200
• Clone the required git repositories:
git clone -depth 1 -branch main https://github.com/open-qLiantum-safe/liboqs
git clone -depth 1 -branch master https://github.com/openssl/openssl,git
git clone -depth 1 -branch main
https://github.com/open-quantum-s afe/oqs-p rovider.git
git clone https://github.com/OpenVPN/openvpn.git
• Build liboqs:
# build uttsisjs
cd liboqs
mkdir build
cd build
cmake -G"Ninja" .. -DOQS_DIST_BUILD=ON -DCMAKE_INSTALL_PREFIX=INSTALLDIR
ninja install
check_error"liboqs build'cs
58
A. APPENDIX
• Build OpenSSL:
# build OpenSSL3
cd openssl
LDFLAGS-'-WI,-rpath -WI,INSTALLDIR/lib64" ./config shared --prefix=INSTALLDIR
make -j 4
make install_sw install_ssldirs
check_error "OpenSSL3 build"
# set path to use new openssl. Dyn libs have been properly linked in to match
export PATH="INSTALLDIR/bin: $PAT H"
• Build & install oqs-provider:
# build & install provider and activate by default
cd oqs-provider
In -s ../openssl.
cmake -DOPENSSL_ROOT_DIR=INSTALLDIR -DCMAKE_BUILD_TYPE=Release
-DCMA K E_P RE FIX_PATH = INSTALLDIR -S . -B _build
cjmaKe --build _build
cp _build/lib/oqsprovider.so INSTALLDIR/Iib64/ossl-modules
check_error "oqs-provider build"
• Activate the oqs-provider:
# Activate the provider
sed -i "s/default = default_sect/default = default_sect\noqsprovider =
oqsprovider_sect/g"INSTALLDIR/s si/openssl.cnf
sed -i "sA[default_sectt]A[default_sect\]\nactivate = 1\n\[oqsprovider_sect\]\nactivate =
1\n/g" INSTALLDIR/ssl/openssLcnf
sed -i "s/providers = provider_sect/providers = provider_sect\nssl_conf =
ss l_sect\n\n\[s s l_sect\]\nsystem_d efauIt =
system_defau lt_secttn\n\[system_default_sect\]\nG roups =
kyber768:p334_kyber768\n/g" INSTALLDIR/ssl/openssl.cnf
check error "Provider activation"
59
A. APPENDIX
• Build & install OpenVPN:
# build & install OpenVPN
cd openvpn
JJMSBJiZB -force && aclocal && auto header && automake —force-missing -add-missing
&& autoconf
CFLAGS="-I INSTALLDIR'include -WI.-rpath=INSTALLDIR/lib64 -L INSTALLDIR,'lib64"
./configure —prefix=INSTALLDIR -disable-lz4
make -j 4
make check
make install
check_error "OpenVPN build"
# Set path to use new openvpn configured with oqs-enabled openssl
export PATH="INSTALLDIR/sbin:$PATH"
Once the configurations are complete, OpenSSL can generate keys
and certificates using Dilithium digital signatures and the configured
OpenVPN can recognize PQC algorithms along with Kyber K E M .
Keys and certificates generation: The generation process will specifically
leverage the OpenSSL implementation that is configured to
support PQC capabilities. Below is the procedure to generate all the
keys and certificates:
1. OPENSSL gjenpJsgy -algorithm dilithium3 -out serverkey. key
2. OPENSSL gejiRkej -algorithm dilithium3 -out client_fcey.key
3. OPENSSL gjeripJsey -algorithm dilithium3-outca_key.key
4. OPENSSL req -key ca_key.key -x509 -subj 7CN=testvpn CA" -config openvpn-openssl.cnf
-out cacert.crt
5. OPENSSL req -new -key client_key.key -subj 7CN=vpn client" -config openvpn-openssl.cnf
-out clientcert.csr
6. OPENSSL x509 -req -in client_cert.csr -CA ca_cert.crt -CAkey ca_key.key -out
clientcert.crt -extensions usrcert -extfile openvpn-openssl.cnf
7. OPENSSL req -new -key serverkey. key -subj 7CN=vpn server" -config
openvpn-openssl.cnf-outservercert. csr
8. OPENSSL x509 -req -in servercert.csr -CA cacert.crt -CAkey cakey.key -CAcreateserial
-out servercert.crt -extensions usrcert -extfile openvpn-openssl.cnf
After completing the necessary setup steps, PQC-enabled OpenVPN
is ready for use. Below are sample configuration files.
60
A. APPENDIX
• server.config:
server 10.0.1.0 255.255.255.0
verb 5
key server_key.key
ca cacert.crt
cert server_cert.crt
dh none
keepalive 10 30
persist-key
persist-tun
proto udp
port 1194
dev tunO
status /tmp/openvpn-status.log
user nobody
group nogroup
comp-lzo no
### Route Configurations Below
route 10.0.1.0 255.255.255.0
### Push Configurations Below
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"
push "comp-lzo no"
• client.config:
client
verb 5
dev tun
remote-cert-tls server
remote lipusmsj; 1194 ydp
key clientkey.key
cert clientcert.crt
ca ca cert.crt
# strictly necessary
#redirect-gateway defl
status /tmp/openvpn-status.log
61
B APPENDIX
Workflow: In the last section, the successful integration of the LibOQS,
with SSL of OpenV P N was explained stepwise. After the integration,
a VC Server "Safe Link" server was placed behind the V P N server and
accessed using the QS-VPN client application. The following steps
were followed during the testing.
• QS-VPN client application is installed on an Ubuntu machine.
The client and C A certificates are bundled in the application
itself.
irtnjntu£10«wn8iibiintuSSe4Swi:~/i S SOPENSSL XS69 -In ea_etrt.crt -text
Certificate:
I) a: :
Version; i (6x2)
Serial Number:
35:23;41i2e^i63;19:79:e5:ae:«:d6:93:«c:aa:Ze:3b;7c;«:4a
StgnaturE Algorithm: dilithluni
Issuer: £H=oqscperwantest CA
Validity
«et Before: Hsr S OS:16:13 JB2ä CHT
Sot After : Mar i OSMorli iCJi GMT
subject: CH=o(isöpen^pnte5t {.A
subject Public Key Info;
Public KEy Algorithm; dlUthluraS
dlltttilumi ttubUc k*y:
PQ key material:
6?:7c:il):8c:c4:53:Sf :e9:dS:39: Id :Fb: 94:21:69:
ef:3b:d7:fll:eB:SS:J8:49:a7:Sa:6d:ol:dS:ef:b4:
e*:e3:4S:75:«B:SS:19:«3:4f:33:TS:4d:be:4«:H:
79:df:d9:57:sc:5l:
:aa:4e:e7:e9:9Z:«c:3&:3d:2a:
4f :ac: « : d i : e c : f e : * T : 7B:4i :47:fe:6d:a£:ae:69:
3S:3e:SS:2b;S3:S::49:ttS:lc:ld:76:lb:7»:4b:91:
4S:ee;e5:5b:89:S5:8f:lc:2e:e3:19:cJ:4c:ee:6f:
t>f:aq:äl:cb:Sq: ä5:5c: äS:«l:S7:5a:b4:97:JJ:liJ:
re:*9:al:Ta:il:cf:e9:45:76:S9:9e:SI:71:fc:34:
d9r4e:2#:SS;5t>:<Ja:46:e9:abrd4:4<i:fd:4d::al:f,
7:
4«:Be:4f :ee:be::9:e3:9a:2i:6(l:M:fa:fS:ae:fl:
7f:eb:aB:Eb:e2:ab:S5:7b:c?:33:a7:e4:i3:a2:S5:
64:99:e2:9d:3B:45:i3:fa:e3:7b:a9:dd:cS:ed:zl:
4*idf :W !3»:zdrcS!ec:b6!Sei:7l;ca!ia:BS!33:B7!
fe;3a:B6:ei:55:f5:si:sc:ei:i():ad:5d:4(t:e5:5f;
Jfii2S:7a:ce:e4:S3:cS:t)a:26:b6.:99:S3:94:d2id8:
57:3b:S»:cb;a9:93:9J;6B:3«;i2:f9:2S;*b:Ca:dd:
M:2c:9f: 96:49:57 :eb:sb:42:i:e:eB:2t:sd:af:2Z:
flfl: M :-l^:!!7 :f i:rs:flf :ti:si>:c<!: in: Biüüf: ] r: 17 :
9E:l3:S6:fa:Ek:92:64:7f:46:6d:a6:cF:4a:e<S:74:
Figure B.l: C A Certificate Details.
• QS-VPN server, which is hosted on a V M on-premise physical
server is started.
• VC server, which is also hosted on a V M and placed behind the
QS-VPN server is started.
62
B. APPENDIX
• Without starting the QS-VPN client, a request for connection
with the VC server was sent, and as expected the connection was
unsuccessful.
• Connection request from the QS-VPN client application was
sent to the QS-VPN server and after the certificate exchange and
verification, the connection was successfully created.
• Request for connection with the VC server was sent again and
as expected the connection was successful this time.
Workflow Screenshots follow.
Q u a n t urn Safe V P N - •
Q u a n t u m Safe V P N
Server's IP f p o m a i n N a m e
Quantum Safe VPN
A Quantum Safe
Solution
Status
Check C A Check Clieni
Certificate certificate
| ^ Connect
Figure B.2: Home page of The QS-VPN Client Application.
63
B. APPENDIX
Figure B.3: Checking C A Certificate.
Q u a n t u m Safe V P N
Quantum Safe VP
A Quantum Saf
Solution
Quantum Safe VPN
Server's IP / Domain Name
qsvpnserver
Status
Client's Key & Cert Found !
Client certificate Found I
Figure B.4: Checking Client Certificate.
64
B. APPENDIX
Q u a n t u m £aFa V P N
- •
Q u a n t u m Safe V P N
Server's I P / O o m a i n N a m e
qsvpn server|
status
Successfully Connected
Quantum Safe VPN
A Quantum Safe
Solution
Server's I P / O o m a i n N a m e
qsvpn server|
status
Successfully Connected
C h e c k C A c h e c k client
c.,;:,'.„:.ii,- Certificate
Figure B.5: Connecting with QS-VPN Server.
65