See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/358628285

Implementing Post-quantum Cryptography for Developers

Conference Paper · January 2022

DOI: 10.5220/0010786200003120

CITATIONS READS

3 362

3 authors:

Julius Hekkala Kimmo Halunen

5 PUBLICATIONS 8 CITATIONS
University of Oulu
52 PUBLICATIONS 238 CITATIONS
SEE PROFILE
SEE PROFILE

Visa Vallivaara
VTT Technical Research Centre of Finland
20 PUBLICATIONS 98 CITATIONS

SEE PROFILE

All content following this page was uploaded by Visa Vallivaara on 07 April 2022.

The user has requested enhancement of the downloaded file.

 Implementing Post-quantum Cryptography for Developers

Julius Hekkala1 a
, Kimmo Halunen2,3 b
and Visa Vallivaara1 c
1 VTT
Technical Research Centre of Finland, Kaitoväylä 1, Oulu, Finland
2 University of Oulu, Faculty of Information Technology and Electrical Engineering, Oulu, Finland
3 National Defence University, Department of Military Technology, Helsinki, Finland

Keywords: Post-quantum Cryptography, Lattice Cryptography, C++, Programming Library.

Abstract: The possibility of a quantum computer threatens modern public key cryptography. Post-quantum
cryptographic algorithms are designed to protect sensitive data and communications also against an attacker
equipped with a quantum computer. National Institute of Standards and Technology is standardizing post-
quantum algorithms that could replace currently used public key cryptographic algorithms in key exchange and
digital signatures. Lattice-based cryptography is one of the post-quantum algorithm groups with the biggest
potential. Cryptography libraries are used by developers in all kinds of different solutions, but currently the
availability of post-quantum algorithms in open-source libraries is very limited. Implementing post-quantum
algorithms into a software library involves a multitude of challenges. We integrated three lattice-based post-
quantum algorithms into a fork of Crypto++, a C++ cryptography library. We analyzed challenges in the
implementation process and the performance and security of the fork. Especially the complex mathematical
ideas behind the algorithms make implementation difficult. The performance of the algorithms was satisfactory
but analyzing the security of the implementation in more detail is needed.

1 INTRODUCTION Quantum computers, on the other hand, can solve

these problems much quicker. Shor’s algorithm
In the modern information society, the security of can be used to solve factoring (Shor, 1997) and
communications and data is essential. The people discrete logarithm problems (Proos and Zalka, 2003)
need to be able to trust that their sensitive data in polynomial time.
remains secure in the future. Cryptography is used to If a powerful enough quantum computer is
prevent adversaries from accessing this information. built, the communications and data secured by
Public key cryptography is commonly used to create conventional means are no longer secure. Because
secure connections, e.g. in TLS (Rescorla, 2018), and it is possible that in the future the attackers will
to digitally sign documents. have quantum computers, it is important to prepare
Public key cryptographic algorithms are often well in advance. For this purpose, post-quantum
based on mathematical problems that are thought to cryptographic algorithms are designed. They
be hard to solve. The most notable example of a use mathematical problems that are difficult for
public key cryptographic algorithm is RSA (Rivest classical as well as quantum computers. Different
et al., 1978), which is based on factoring large standardization authorities have started standardizing
numbers produced by two prime numbers. Another post-quantum algorithms, e.g. NIST has an ongoing
very commonly used group of algorithms, elliptic process standardizing post-quantum algorithms for
curve cryptography (ECC) (Hankerson et al., 2006), key encapsulation methods (KEM) (Shoup, 2001) and
draws their security from discrete logarithms. digital signatures.1
Both of these problems are difficult for modern Implementing cryptography correctly is difficult.
computers, and it is easy to answer the increase There are many possible mistakes that can be made
of computer performance by increasing key sizes. when designing and implementing cryptosystems,
a
which can then lead to the security of the
https://orcid.org/0000-0002-7558-9687
b https://orcid.org/0000-0003-1169-5920 1 https://csrc.nist.gov/projects/post-quantum-
c https://orcid.org/0000-0002-9638-244X cryptography

73
Hekkala, J., Halunen, K. and Vallivaara, V.
Implementing Post-quantum Cryptography for Developers.
DOI: 10.5220/0010786200003120
In Proceedings of the 8th International Conference on Information Systems Security and Privacy (ICISSP 2022), pages 73-83
ISBN: 978-989-758-553-1; ISSN: 2184-4356
Copyright c 2022 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved
ICISSP 2022 - 8th International Conference on Information Systems Security and Privacy

whole program faltering. That is why most threatened by the quantum algorithms.
programs use specific cryptographic libraries that Most public key algorithms are based on
were implemented by experts instead of programming mathematical problems that are deemed hard to solve
the cryptographic functionality from scratch every with a classical computer. These hard problems
time. include factoring and discrete logarithms. While
These libraries include interfaces that make there are no known algorithms for classical computers
it easier to incorporate cryptography in different that would solve them efficiently, there are quantum
programs, and ideally prevent the misuse of the algorithms that solve them in polynomial time, most
cryptographic primitives. A clear drawback is that notably Shor’s algorithm (Shor, 1997).
the algorithms available for use are the ones that Currently there is no quantum computer powerful
are implemented in the library. At this time, many enough that it would break the modern cryptographic
of the most prominent open-source cryptographic algorithms. Breaking 1024 bit RSA would require
libraries do not offer any post-quantum algorithms. about 2000 qubits, while breaking 160 bit ECC would
On the other hand, developers are accustomed to require about 1000 qubits (Proos and Zalka, 2003).
using certain libraries. Thus it is not very easy Google reported to have built a 53 qubit quantum
for developers to use post-quantum algorithms in computer in 2019 (Arute et al., 2019). Very recently
their programs. For example, the current version IBM announced that they have developed a 127 qubit
of OpenSSL2 does not include any post-quantum quantum processor (Chow et al., 2021). Breaking the
algorithms that are part of the NIST standardization algorithms is still quite far away, but if somebody is
process. able to develop a quantum computer with the required
In this paper we present experiences and findings amount of qubits, the currently common public key
on implementing post-quantum cryptographic cryptographic algorithms like RSA and ECC will be
primitives in a programming language library. We vulnerable. Then adversaries will be able to decrypt
also evaluate the performance of the implemented any new and also some old encryptions of data.
primitives. The paper is organized as follows. When the first quantum computer is available for
The second chapter shines light on post-quantum malicious adversaries, any data or communication
cryptography and different post-quantum algorithms. also sent before that might become vulnerable, as
Then we detail the background of implementing perfect forward secrecy is not present everywhere,
post-quantum algorithms in cryptographic libraries. e.g. older versions of TLS support ciphers without
In fourth chapter, we present our work. Fifth forward secrecy. That is why it is important to prepare
chapter showcases the results and analysis. In the for that possibility already.
sixth chapter we discuss the results as well as any
observations made during the integration process. 2.1 Post-quantum Cryptography and
Finally, seventh chapter concludes this paper. Standardization
Post-quantum cryptography contains algorithms that
2 BACKGROUND run on classical computers but are specifically
designed in a way that makes them resistant against
Public key cryptography is an essential enabling attacks with both classical and quantum computers.
component in the modern information society. There is a multitude of different types of post-
It allows parties to exchange keys to securely quantum algorithms that are based on different
communicate using encrypted traffic in protocols mathematical problems. Some of the algorithms are
like TLS, and allows others to verify that a digital based on coding theory, multivariate polynomials and
signature is valid and no changes have been made to hashing. In this paper, we concentrate on lattice-based
the signed document afterwards. post-quantum algorithms.
Quantum computers are able to compute some During the last years, different standardization
tasks more efficiently than the classical computers. authorities have started making official standards for
Grover’s algorithm (Grover, 1996) makes the brute- post-quantum algorithms. NIST (National Institute of
force attack against cryptographic algorithms faster. Standards and Technology) started a standardization
This effect can be negated quite easily by doubling process in 2017, and it is currently in the third
used key sizes in algorithms. This affects all possible round. Anyone was able to submit an algorithm to
algorithms, but public key algorithms are particularly the process at the start, and from those submissions,
the first round candidates for standardization were
2 https://www.openssl.org chosen. Each round, when the candidates were

74
 Implementing Post-quantum Cryptography for Developers

published, researchers had chance to try to find any variants of LWE have been introduced, e.g. Ring-
weaknesses in the algorithms. Also, the submitters LWE (RLWE) and Module-LWE (MLWE). Kyber
were able to make improvements based on the and Dilithium base their security on MLWE. SABER
findings. At the end of each round, the amount of is based on the modular version of the Learning with
algorithms that are candidates for standardization got Rounding problem, which is different from LWE in
smaller. that it is deterministic.
The NIST post-quantum cryptography The three algorithms are all potential standards
standardization process involves two types of (Alagic et al., 2020). Since they all are based on
algorithms - key encapsulation mechanism (KEM) lattice problems, comparison between the algorithms
algorithms and digital signature algorithms. KEM is more meaningful. Lattice-based algorithms have
algorithms are meant to replace public key algorithms become one of the most potential replacements for the
used especially for key exchange, e.g. in TLS. They commonly used public key cryptographic algorithms,
consist of three separate parts: a key generation as is evident by the share of lattice-based algorithms
algorithm, an encryption (encapsulation) algorithm, present in the third round of the NIST standardization
and a decryption (decapsulation) algorithm (Shoup, process. Even though they are relatively young,
2001). researchers are quite confident in their security.
At the time of writing this, there are four KEM Another upside of lattice-based algorithms is that the
algorithms and three digital signature algorithms key or ciphertext size is not massive, like is the case
among the finalists, all presented in Table 1. The e.g. in algorithms that are based on multivariate
KEM algorithms are Classic McEliece which is based polynomials.
on Goppa codes and CRYSTALS-Kyber, NTRU and
SABER which are based on lattices. The digital 2.3 Cryptographic Software Libraries
signature algorithms are CRYSTALS-Dilithium and
FALCON which are based on lattices and Rainbow Cryptographic primitives are usually defined in
which is based on multivariate polynomials. mathematical notation, with mathematical formulae
and operations. Implementing algorithms in a certain
Table 1: The third round algorithms of the NIST post- programming language is always a separate process
quantum cryptography standardization process. from that with its own pitfalls. A mistake in the
Algorithm Mathematical Problem implementation will result in a security flaw even
Classic McEliece Goppa codes if the system is secure in theory (Lazar et al.,
CRYSTALS-Kyber Lattices 2014). It can be surprisingly difficult to implement
NTRU Lattices cryptographic algorithms correctly.
SABER Lattices That is why the general rule when needing
CRYSTALS-Dilithium Lattices cryptography is that there is no need to reinvent
FALCON Lattices the wheel. There are plenty of open-source
Rainbow Multivar. polynomials cryptographic libraries that have implemented the
cryptographic primitives and offer a (hopefully) easy-
to-use interface for the developer to integrate them in
2.2 Chosen Algorithms different programs. By using a cryptographic library
one has succesfully avoided one of the biggest pitfalls.
In this paper, we present work performed with If one wants to use common public key
three of the third round candidate algorithms in the cryptographic algorithms like RSA or elliptic curve
NIST standardization process. Two KEM algorithms algorithms, there is an abundance of cryptographic
and one digital signature algorithm were integrated. libraries that implement these algorithms. On the
The chosen algorithms were CRYSTALS-Kyber (Bos other hand, if one wants to secure their program
et al., 2018), SABER (D’Anvers et al., 2018) and against quantum computers, options are very limited.
CRYSTALS-Dilithium (Ducas et al., 2018). All There are example implementations of the algorithms
three algorithms are based on lattice problems. The and some open-source libraries that specifically
foundation of lattice problems used in cryptography focus on post-quantum cryptography, like liboqs3
is the Shortest Vector Problem (SVP). With some developed in the Open Quantum Safe project. The
conditions SVP is an NP-hard problem, i.e. it does not big and commonly used libraries often include very
have a deterministic solution that runs in polynomial few post-quantum algorithms, if any at all.
time (Regev and Rosen, 2006).
Regev (2005) presented a problem called LWE
(Learning with Errors) that is based on SVP. Different 3 https://github.com/open-quantum-safe/liboqs

75
ICISSP 2022 - 8th International Conference on Information Systems Security and Privacy

2.4 Dangers When using Open-source As post-quantum algorithms run on the classical
Cryptographic Libraries computer, unlike quantum cryptography that runs
on a quantum computer, the challenges related to
Even if an algorithm has been designed to be secure, it implementing cryptographic algorithms in general
does not mean that implementing or using it securely apply to implementing post-quantum algorithms.
is easy. Mistakes in the implementation phase, A great challenge in implementing post-quantum
misunderstandings and other mistakes undermine the cryptography is the mathematical complexity of the
security of the algorithm. algorithms. This makes implementing the algorithm
As all cryptography is implemented by people from just the specification very difficult for an average
and people make mistakes, even high profile open- developer (Gaj, 2018). Currently used public key
source libraries have bugs and vulnerabilities. One of algorithms are based on mathematical problems that
the most well-known vulnerabilities is the Heartbleed are much easier to understand.
bug, which was a mistake in the TLS implementation Another challenge is the often greatly increased
of OpenSSL and allowed adversaries to access critical key size and sometimes the ciphertext size. Table
information (Durumeric et al., 2014). Variation in the 2 presents comparison of key sizes between post-
execution time of functions can lead to timing attacks, quantum and commonly used public key algorithms.
which can be very difficult vulnerabilities to prevent Especially the sizes of the private keys of the
and detect (Almeida et al., 2016). post-quantum algorithms are larger on the same
Even if the cryptographic algorithms are security level as traditional public key algorithms.
implemented correctly in the library, using them is When implementing post-quantum cryptography on
not necessarily easy. In a study from 2014, out of hardware, this becomes even more important.
the examined vulnerabilities 17 % were caused by Because post-quantum algorithms use different
mistakes made in the implementation of the library, operations than e.g. RSA, optimizing the hardware
and 83 % were caused by mistakes in the programs is more difficult (Gaj, 2018).
using the library, e.g. by the programs using the
library incorrectly (Lazar et al., 2014). A study from Table 2: Comparison of key sizes and ciphertext sizes of
some post-quantum and traditional public key algorithms.
2013 found out that in over 88 % of the examined
10 000 Android applications in the Google Play Algorithm Priv. key Public key Output
store there was at least one mistake in the use of (bytes) (bytes) (bytes)
cryptographic interfaces (Egele et al., 2013). Kyber-512 1632 800 768
These examples prove that smart design and clear Kyber-768 2400 1184 1088
interfaces need to be a priority when implementing Kyber-1024 3168 1568 1568
cryptographic libraries. It is quite easy to make LightSaber 1568 672 736
mistakes when using the functionality of the Saber 2304 992 1088
cryptographic libraries. A common mistake is FireSaber 3040 1312 1472
not using cryptographically strong random number RSA-3072 384* 384* 384
generators when generating randomness for an RSA-7680 960* 960* 960
algorithm (Lazar et al., 2014). RSA-15360 1920* 1920* 1920
It is not enough that the implementation of Curve25519 251 256
the cryptographic algorithm is correct and secure. * Modulo.
Performance of the implementation is always crucial
in real use, and has a great effect on what algorithms It is important that there are implementations of
will be used, especially in cases where the operations post-quantum cryptographic algorithms in different
will be performed often. In small IoT devices the languages and for different problems, so that
choice of algorithms is very restricted. replacing algorithms that are not quantum secure
is easier. Table 3 shows the current amount of
2.5 Challenges in Implementing implemented asymmetric post-quantum algorithms
in some of the most commonly used open-source
Post-quantum Cryptographic libraries. Of the algorithms in the table not
Algorithms mentioned before, XMSS is a hash-based post-
quantum signature scheme and NewHope is a lattice-
In principle, implementing post-quantum based KEM algorithm that was removed from the
cryptographic algorithms does not fundamentally NIST standardization process after the second round.
differ from implementing any other algorithm. Many of the largest open-source cryptographic

76
 Implementing Post-quantum Cryptography for Developers

Table 3: Availability of post-quantum asymmetric 3.1 Goals in the Integration Process

algorithms in selected open-source libraries at the time of
the work.
Bernstein et al. (2012) emphasize simplicity
Library Language Algorithms and reliability when designing an API for a
OpenSSL C - cryptographic programming library. They also
LibreSSL C - present countermeasures taken when designing
Botan C++ McEliece how the library works to prevent vulnerabilities,
NewHope e.g. by always reading randomness from the OS
XMSS cryptographic random number generator instead of
Crypto++ C++ - implementing their own complicated way to generate
Bouncy Castle Java NewHope randomness. In that context, they also mention
McEliece code minimization as an underappreciated goal in
Rainbow... cryptographic software.
Forler et al. (2012) present their cryptographic
libraries have not implemented any of the algorithms. API that is resistant against misuse. Namely, it is
For this, there are most likely quite a few reasons. designed in a way that avoiding nonce reuse and
The standardization is still ongoing and many are still plaintext leaking is easier. Green and Smith (2016)
awaiting which algorithm will be standardized. Also, present 10 principles for implementing cryptographic
many of the algorithms have undergone changes, library APIs in a usable way. Because a cryptographic
mostly small parameter changes, during the process. library is used by other people than those who
As many of the algorithms are quite young in age, it is developed it, usability needs to be a focus when
possible that there are still vulnerabilities to be found designing the cryptographic API.
that greatly decrease their security. When integrating the post-quantum algorithms
into the fork of Crypto++, the following were our
goals:
3 ALGORITHM INTEGRATION • Usability. Green and Smith (2016) mention the
API needs to be easy to learn even for users
The availability of the NIST post-quantum algorithms without cryptographic expertise in addition to
in open-source cryptographic libraries is scarce. being easy to use. We see these as the most
There are example implementations, mostly in C, and important aspects in our case. The API needs to
some libraries that specialize in the post-quantum be clear and concise. Changing parameters has to
niche. It would be a lot easier for the end-users be easy.
of these algorithms, i.e. developers, researchers and • Conformity of the code with other algorithms of
hobbyists, if the algorithms were included in the the library. As far as possible, the structure of the
cryptographic libraries they are used to using. That new algorithms’ code is similar to the algorithms
way the user will not have to learn how to use the new already present in the library. Also, library
cryptographic library and how its interfaces work, specific functions are used where applicable.
reducing the threshold for trying out and adopting
• Reliability. The algorithms work as specified and
post-quantum algorithms.
return the correct outputs.
We chose Crypto++4 as the library under
examination, as it did not have any of the algorithms • Prevent unnecessary code. This can be achieved
from the NIST standardization process before. e.g. by using library functions where appropriate.
According to the Github 2020 The State of the • Performance. Algorithms need to be as fast as
Octoverse report,5 C++ was the 7th most popular possible, without any unnecessary overhead.
programming language in Github in 2020 and has
been consistently popular over the years. We used the 3.2 Realization of the Goals
reference implementations of SABER, Dilithium and
Kyber as a basis and integrated them into a fork6 of Because the chosen algorithms, Kyber, Dilithium and
Crypto++. SABER, are quite a bit more complex than traditional
public key algorithms, implementing them based on
just the specification is really difficult. That is why
4 https://cryptopp.com we decided to use the reference implementations
5 https://octoverse.github.com provided by the designers of the algorithms to the
6 https://github.com/juliushekkala/cryptopp-pqc third round of the NIST standardization process.

77
ICISSP 2022 - 8th International Conference on Information Systems Security and Privacy

Because the reference implementations were reference implementation, polynomials and vectors
implemented with C and the language of the have been implemented using structs. The size of
Crypto++ library was C++, choosing to work with arrays in structs needs to be defined before compiling,
the reference implementations directly as a basis and this was not possible, as there was variation in
was very advantageous. This way we were able to the sizes between security levels. Polynomials were
prevent much unnecessary code. We created a fork switched to work with std::array and vectors with
of the at the time most current version of Crypto++. std::vector. Even if this caused in turn some changes
The reference implementations were imported to the in the methods, it was not very difficult, as std::array
fork and changed from C code to C++ code where and std::vector make it possible to work on their inner
necessary. data.
A major goal in the implementation process was Debugging presented quite a challenge at times.
that a potential user would be able to use the As the algorithms involve a lot of different
implemented post-quantum algorithms, e.g. change advanced mathematical operations and rely heavily
between the different security levels, in a similar way on randomness, it is not easy to determine whether
to other algorithms already present in the library. the state of the program is correct at some point. We
Class structure was added, as well as the API through used the reference implementation with randomness
which the user is able to use the algorithms. The API removed in the debugging process to find out where
specified by NIST for the reference implementations the execution of the C++ version goes wrong. That
works as a basis, as we saw no reason to invent the way we were able to find bugs created in the
wheel anew, in other ways we tried to have the API integration process.
work as similarly as other algorithms in Crypto++. Platform independency caused some trouble, as
Platform independency was also desirable, at least using variables to define arrays is possible with GCC
that using the fork would be possible on both Linux compiler, but not on many others, as it is not in
and Windows operating systems. accordance with the official C++ standard. Because
of this we had to change from using arrays to using
3.3 Challenges in the Integration std::vector at many points.
Process Because the NIST standardization process is
not finished, the details of the algorithms and the
Throughout the implementation process, the biggest parameters can change. When we started evaluating
issue that needed a lot of consideration was the the implementation, the security levels of Dilithium
question of how the multitude of parameters should had radically changed from the version that was
be handled. The C reference implementations manage implemented to the work. We had to update Dilithium
the parameters using compile-time constants, and as to an up-to-date version to evaluate it against the
that would require the user to compile the library newest version.
again if they want to change the security levels of the
post-quantum algorithms, it was not a suitable choice
for us. Two different solutions were used for this 4 RESULTS
in the implementations. In the implementations of
Kyber and SABER, templates were used to handle the The performance of the algorithms integrated to
parameters. A base class of the algorithm was created, the fork was analysed by measuring clockcycles
that had two template parameters that were used to with rdstc() instruction and compared against
define all the algorithm parameters. When using the the measured performance of the reference
algorithm, the user would call a subclass of the base implementations on the same device. All
class that creates an instance of the base class with the measurements were done on a laptop (i7-10875H
correct template parameters. CPU @ 2.30 GHz x16) running Ubuntu 18.04 and
Using templates is quite an elegant solution, the programs were initially compiled with G++ using
unless there is a need for a lot of template parameters. the predetermined compiler options of Crypto++ and
In case of Kyber and SABER it was just two, but for the reference implementations respectively. Using
Dilitihium we would have needed quite a list to make different compilers and compiler optimizations will
it work. For code clarity, it was decided to go another bring forth differences in the performance.
route with Dilithium. With Dilithium we ended up
using just member variables, that are changed by the
subclass creating an instance of the base class. This
caused some additional compulsory changes. In the

78
 Implementing Post-quantum Cryptography for Developers

4.1 Performance Analysis SABER was even better than that of the reference
implementation.
When the SABER algorithm first was implemented In addition to presenting the performance of
in the library, the performance was not satisfactory. Kyber and SABER, table 4 includes Dilithium
Compared to Kyber, the integration had decreased performance after updating it to the newest parameter
the performance by much more. The runtime set. Without any custom optimization, the C++
of the algorithm was double of the reference implementation was very close in performance to
implementations, even though not many changes had the original C implementation. With -march=native
been made. After debugging, it was found what enabled, the C++ implementation siginificantly
part of SABER was the bottleneck. One design outperformed the C implementation.
choice of SABER is to use integers moduli that
are powers of 2 (D’Anvers et al., 2018). While 4.2 Security Analysis
this makes the other parts of the implementation
simpler, it prevents SABER from using the number The implementation was analyzed with Valgrind7
theoretic transform (NTT) that is used in Kyber to to find out possible memory leaks. No memory
speed up calculations. The polynomial multiplication leaks were found in the C++ implementation.
algorithm is interchangable and needs to be decided Side channel attacks are always a risk when
by the implementers of the algorithm. In the implementing cryptographic algorithms, especially
reference implementation, the authors use Toom- when optimization is present. Side channel attack
Cook-Karatsuba multiplication. For the sake of analysis remains future work.
time and resource management, we used the Naturally, we had to be careful that there are
construction provided by the authors in the reference no possible parts in the algorithm where an attacker
implementation. Even though the same construction could determine secrets based on execution times.
was used with very little changes, the performance Constant time functions were used e.g. for comparing
decrease was close to 100 %. the equality of byte arrays.
Inspecting the compiler options used in Crypto++
by default and the reference implementation revealed
the cause. After debugging, the compiler option
-march=native used in the reference implementation
5 DISCUSSION
was found to be the culprit. With this option enabled,
The possible emergence of quantum computers
the compiler will detect the architecture of the
presents a threat especially to the current public key
system and automatically optimize the code for that
infrastructure. As there are systems where data
architecture. Without this option, the compiler was
and communications need to be secure for years of
not able to optimize Toom-Cook-Karatsuba construct
time, preparing for possible quantum computers is
in the way that was intended by the authors of the
necessary. Lattice-based algorithms are an emerging
algorithm. While changing the compiler options of
group of post-quantum algorithms that are one
the library on Linux was successful, Microsoft Visual
potential replacement for the currently used non-
Studio Compiler does not offer similar functionality,
quantum-resilient algorithms. As they are still
and the optimization has to be done separately for
quite young, it is entirely possible that systematic
each type of machine.
attacks will be found against them. The current
Table 4 presents the performance measurements
understanding is that the algorithms of this paper,
of the integrated algorithms, with the average runtime
Kyber, Dilithium and SABER, are not affected by
of different versions of the algorithms measured
serious attacks.
in CPU clockcycles. The performance of the
As the NIST standardization process is still
integrated C++ versions, both with and without
ongoing, it is understandable that many big libraries
the -march=native GCC optimization flag, was
have not implemented the algorithms. The algorithms
compared against the reference implementations.
may still undergo and have undergone changes during
Without optimization, both KEM algorithms were
the process, as was the case with Dilithium during
slower than the reference implementation, especially
our work. Also, it is always possible that serious
SABER. Optimization improved performance of both
vulnerabilities are found. Like with AES, usually the
algorithms, but the difference was radical with
standardized algorithm will spread to use and others
SABER, which is emphasized with red and green
will be less relevant. From that perspective, it makes
colors in the runtime change in Table 4 respectively.
With -march=native enabled, the performance of
7 https://valgrind.org

79
ICISSP 2022 - 8th International Conference on Information Systems Security and Privacy

Table 4: Performance of Kyber, SABER and Dilithium on different security levels. The reference implementation performance
is compared first against performance when compiling the fork with default options, and then when compiling with
-march=native eanabled. The red and green color are used to emphasize the difference in the performance of SABER with
and without the option.
Algorithm Function CPU cycles CPU cycles Runtime CPU cycles Runtime
(ref. impl.) (C++ default) increase (%) (C++ with opt.) increase (%)
Kyber-512 Key gen. 70527 77452 10 70106 -1
Encaps. 90177 103454 15 93220 3
Decaps. 106539 124722 17 114415 7
Kyber-768 Key gen. 119089 137032 15 124357 4
Encaps. 141759 170474 20 152433 8
Decaps. 162677 196737 21 180212 11
Kyber-1024 Key gen. 181525 213370 18 191942 6
Encaps. 205682 251775 22 226342 10
Decaps. 230457 283941 23 259733 13
LightSaber Key gen. 43321 84330 95 46551 7
Encaps. 56580 106420 88 51789 -8
Decaps. 62496 121883 95 55970 -10
Saber Key gen. 80317 158330 97 80856 1
Encaps. 100271 193770 93 91811 -8
Decaps. 109088 218243 100 97211 -11
FireSaber Key gen. 132859 257348 94 127774 -4
Encaps. 156832 305424 95 143594 -8
Decaps. 169193 340069 101 153203 -9
Dilithium2 Key gen. 216791 201662 -7 175171 -19
Sign. 920338 863546 -6 788545 -14
Verif. 214877 228392 6 201943 -6
Dilithium3 Key gen. 350129 370364 6 321002 -8
Sign. 1382591 1397358 1 1300339 -6
Verif. 338629 364654 8 320600 -5
Dilithium5 Key gen. 532097 550770 4 471764 -11
Sign. 1674901 1697241 1 1569844 -6
Verif. 562763 594885 6 518180 -8

sense not to implement algorithms that will not be implementation process. It can be hard to find
used. the problematic parts in the implementation as the
implementations are complicated. Because many of
5.1 Biggest Challenges in Implementing the lattice-based algorithms are not deterministic,
Lattice-based Post-quantum the output is every time different for the same input,
and it requires extra effort to be able to debug the
Cryptography implementation. In our work we used the reference
implementations in the debugging process, by
There is a multitude of challenges affecting determining with that program what the state of the
implementing lattice-based post-quantum variables should be in each part of the code. That
cryptography. They are harder to implement than way we were able to find out where mistakes had
algorithms that are based on factoring and discrete been made. If no such reference implementation is
logarithms, as the mathematical operations and easily available, debugging becomes tedious.
theory are much more complex. This makes creating In general use, the key and output sizes and the
an efficient and well optimized implementation use of memory of lattice-based algorithms are not
quite difficult. Implementing based on just the a problem. In memory-constrained environments,
specification is challenging, and without the reference though, it is not possible to use every lattice-based
implementations as a basis, the implementation would algorithm. Also, some communication protocols are
not have been that successful. not suitable for lattice-based algorithms because of
Debugging posed a problem in the e.g. constraints on the message length.

80
 Implementing Post-quantum Cryptography for Developers

5.2 Were the Implementation Goals testing for definite results.

Achieved? While the measured performance of the integrated
algorithms was satisfactory, it would be interesting
In general, the goals we set in 3.1 were mostly to examine it more thoroughly. For example,
achieved. The library specific functions were used the performance of SABER is even better in the
wherever possible, and the structure is quite similar integrated C++ version when using -march=native
to using other algorithms. Performance was also than in the original C version. One could try to find
satisfactory, especially after compiler optimization. out whether this is because of the changes made in
There were some things, though, that left a bit to be our work or because of some compiler optimization
desired. differences, et cetera.
One of our goals was to make the algorithms in the
fork as usable as possible. Now, using cryptographic 5.3 Comparison of the Implemented
primitives correctly is never going to be the easiest Algorithms
thing to do, but as we stayed very close to the structure
of the API specified by NIST, using the algorithms The NIST post-quantum standardization process is
is quite simple. It would be possible to evaluate the still underway. Therefore it is meaningful to make
usability of the algorithms in the library by using some comparisons between SABER and Kyber,
C++ developers as evaluators. For usability, one as both are potential standards (Alagic et al.,
thing that is missing from the current implementation 2020). Based on our work, one cannot make
is handling coding errors, e.g. using too small definite conclusions about which of the algorithms is
buffers. Currently this leads in most cases to just the ultimately better.
compiled executable crashing. Exception handling As the difference in the key and output sizes
would improve the usability, but it is important to is small and performance is not radically different,
consider the points of code where it could be useful these should not be the most importnat point in
for the developer in order not to introduce bloated standardization decisions. From these aspects, both
code. of the algorithm are suitable for standardization.
Another one of the goals was preventing Kyber is structurally a lot more complex than
unnecessary code. Again, we partly succeeded - e.g. SABER. SABER does put a lot of focus on achieving
the hash functions in the reference implementations as much simplicity in the algorithm as possible, which
were as a rule exchanged to using already present probably makes it easier to implement. Kyber is part
library implementations. With better planning and of the same framework as Dilithium, which is one of
carefully designing the class structure more could the candidates to be standardized as a digital signature
have been achieved. Kyber and Dilithium are based algorithm. This is a clear advantage for Kyber.
on the same framework and work very similarly,
and the code could have been designed in a way 5.4 Future Work
that they use common code components for e.g.
NTT functionality. In the current implementation The implementation can be used to further examine
the NTT functionality (essentially being the same) and evaluate the algorithms. The security of the
can be found twice, for each Kyber and Dilithium algorithms and the implementation can be examined
separately. This was mostly caused by our process for example by fuzzing. The fork can be used
of integrating each algorithm one by one. A more to examine the applicability of the algorithms
careful consideration of the overall picture would in different protocols and scenarios. Different
have been beneficial. compiler optimizations can be experimented with
One of the points to take into account when and investigated whether they cause side channel
designing a cryptographic API that we mentioned vulnerabilities.
in 3.1 was misuse resistance. The API in our As the algorithms change during the NIST
implementation is quite resistant against misuse. The standardization process, they need to be updated
algorithms are designed in a way that the user does to keep up with the changes. Maintenance
not supply any own nonces to the algorithms, so and improvement of the library is needed, too.
nonce reuse will not be an issue. Additionally, the Currently only the reference versions of the algorithm
randomness needed in the algorithms is generated implementations are integrated to the library, while
inside the algorithms and not supplied by the user. all the algorithm submissions also included AVX2
Still, it is quite possible that the users would be able (Advanced Vector Extensions 2) optimized versions.
to use the algorithms wrong, and would need more

81
ICISSP 2022 - 8th International Conference on Information Systems Security and Privacy

Integrating them would improve the performance on Arute, F., Arya, K., Babbush, R., Bacon, D., Bardin, J. C.,
devices that can use those processor instructions. Barends, R., Biswas, R., Boixo, S., Brandao, F. G.,
Naturally, other post-quantum algorithms can Buell, D. A., et al. (2019). Quantum supremacy using
be implemented into the created fork. Another a programmable superconducting processor. Nature,
574(7779):505–510.
challenge would be to implement e.g. a Java version
Bernstein, D. J., Lange, T., and Schwabe, P. (2012). The
of the algorithms, as there are no Java reference Security Impact of a New Cryptographic Library.
implementations available that we know of. In Progress in Cryptology – LATINCRYPT 2012,
pages 159–176, Berlin, Heidelberg. Springer Berlin
Heidelberg.
6 CONCLUSIONS Bos, J., Ducas, L., Kiltz, E., Lepoint, T., Lyubashevsky,
V., Schanck, J. M., Schwabe, P., Seiler, G., and
Stehlé, D. (2018). CRYSTALS-Kyber: a CCA-secure
Post-quantum cryptography aims to provide an module-lattice-based KEM. In 2018 IEEE European
answer to the emergence of quantum computers Symposium on Security and Privacy (EuroS&P),
that threaten especially the public key cryptographic pages 353–367. IEEE.
ecosystem. Lattice-based algorithms are one type of Chow, J., Dial, O., and Gambetta, J. (2021). IBM
post-quantum algorithms that are likely to increase Quantum breaks the 100-qubit processor
in use in the coming years. We integrated barrier. https://research.ibm.com/blog/
into a cryptographic library fork three lattice-based 127-qubit-quantum-processor-eagle. Accessed:
2021-11-26.
algorithms from the third round candidates of NIST
D’Anvers, J.-P., Karmakar, A., Roy, S. S., and Vercauteren,
post-quantum cryptography standardization process, F. (2018). Saber: Module-LWR based key exchange,
namely KEM algorithms Kyber and SABER and CPA-secure encryption and CCA-secure KEM. In
digital signature algorithm Dilithium. International Conference on Cryptology in Africa,
We examined the challenges and possible pages 282–305. Springer.
pitfalls of implementing post-quantum cryptographic Ducas, L., Kiltz, E., Lepoint, T., Lyubashevsky,
algorithms in software libraries. The mathematical V., Schwabe, P., Seiler, G., and Stehlé, D.
complexity of the algorithms and difficult to (2018). CRYSTALS-Dilithium: A Lattice-Based
understand specification provide a challenge for Digital Signature Scheme. IACR Transactions on
Cryptographic Hardware and Embedded Systems,
the people implementing the algorithms, and extra 2018(1):238–268.
attention is required not to create possible security
Durumeric, Z., Li, F., Kasten, J., Amann, J., Beekman, J.,
issues. If one algorithm is easier to implement Payer, M., Weaver, N., Adrian, D., Paxson, V., Bailey,
than another, it is an immense advantage, as easier M., and Halderman, J. A. (2014). The Matter of
implementation means less risk of implementation Heartbleed. In Proceedings of the 2014 Conference
errors. on Internet Measurement Conference, IMC ’14, pages
475–488. Association for Computing Machinery.
Egele, M., Brumley, D., Fratantonio, Y., and Kruegel,
C. (2013). An Empirical Study of Cryptographic
ACKNOWLEDGEMENTS Misuse in Android Applications. In Proceedings
of the 2013 ACM SIGSAC Conference on Computer
This research was supported by PQC Finland project & Communications Security, CCS ’13, page 73–84,
funded by Business Finland’s Digital Trust program. New York, NY, USA. Association for Computing
Machinery.
Forler, C., Lucks, S., and Wenzel, J. (2012). Designing
the API for a Cryptographic Library. In Reliable
REFERENCES Software Technologies – Ada-Europe 2012, pages 75–
88, Berlin, Heidelberg. Springer Berlin Heidelberg.
Alagic, G., Alperin-Sheriff, J., Apon, D., Cooper, D., Gaj, K. (2018). Challenges and Rewards of Implementing
Dang, Q., Kelsey, J., Liu, Y.-K., Miller, C., Moody, and Benchmarking Post-Quantum Cryptography in
D., Peralta, R., et al. (2020). Status report Hardware. In Proceedings of the 2018 on Great Lakes
on the second round of the NIST post-quantum Symposium on VLSI, GLSVLSI ’18, page 359–364,
cryptography standardization process. https://csrc. New York, NY, USA. Association for Computing
nist.gov/publications/detail/nistir/8309/final. Machinery.
Almeida, J. B., Barbosa, M., Barthe, G., Dupressoir, Green, M. and Smith, M. (2016). Developers are Not the
F., and Emmi, M. (2016). Verifying Constant- Enemy!: The Need for Usable Security APIs. IEEE
Time Implementations. In 25th USENIX Security Security Privacy, 14(5):40–46.
Symposium (USENIX Security 16), pages 53–70, Grover, L. K. (1996). A fast quantum mechanical
Austin, TX. USENIX Association. algorithm for database search. In Proceedings of the

82
 Implementing Post-quantum Cryptography for Developers

twenty-eighth annual ACM symposium on Theory of

computing, pages 212–219.
Hankerson, D., Menezes, A. J., and Vanstone, S. (2006).
Guide to elliptic curve cryptography. Springer
Science & Business Media.
Lazar, D., Chen, H., Wang, X., and Zeldovich, N. (2014).
Why does cryptographic software fail? A case study
and open problems. In Proceedings of 5th Asia-Pacific
Workshop on Systems, pages 1–7.
Proos, J. and Zalka, C. (2003). Shor’s discrete logarithm
quantum algorithm for elliptic curves. Quantum
Information & Computation, 3(4):317–344.
Regev, O. (2005). On Lattices, Learning with Errors,
Random Linear Codes, and Cryptography. In
Proceedings of the Thirty-Seventh Annual ACM
Symposium on Theory of Computing, STOC ’05,
page 84–93, New York, NY, USA. Association for
Computing Machinery.
Regev, O. and Rosen, R. (2006). Lattice Problems
and Norm Embeddings. In Proceedings of the
Thirty-Eighth Annual ACM Symposium on Theory of
Computing, STOC ’06, page 447–456, New York, NY,
USA. Association for Computing Machinery.
Rescorla, E. (2018). The Transport Layer Security (TLS)
Protocol Version 1.3. RFC 8446. https://rfc-editor.org/
rfc/rfc8446.txt.
Rivest, R. L., Shamir, A., and Adleman, L. (1978). A
Method for Obtaining Digital Signatures and Public-
Key Cryptosystems. Commun. ACM, 21(2):120–126.
Shor, P. W. (1997). Polynomial-Time Algorithms for Prime
Factorization and Discrete Logarithms on a Quantum
Computer. SIAM Journal on Computing, 26(5):1484–
1509.
Shoup, V. (2001). A Proposal for an ISO Standard for
Public Key Encryption. Cryptology ePrint Archive,
Report 2001/112. https://eprint.iacr.org/2001/112.pdf.

83

View publication stats