The arrival of Quantum computers threatens the security of cryptography as we know it. To take a step ahead, NIST launched a competition in 2016 to find the best quantum-resistant algorithms. Out of the 105 initial candidate schemes, only 15 were selected as finalists in 2020. The research community has done extensive work on assessing their security and weaknesses, and we are now at a point where we can start using them in practice. Unlike the competition that designated AES as the standard for symmetric encryption, it is expected for multiple schemes to be standardized at the end of this one. Indeed, the wide range of approaches taken by the finalists all come with different advantages and disadvantages that might not be suited for all use-cases.

This presentation motivates the need for post-quantum cryptography, offers an introduction to the various techniques used to build quantum resistant protocols and gives an insight on what to expect in the coming years.

Among the remaining candidates, we selected Kyber and Dilithium - two schemes offering respectively a Key Encapsulation Mechanism and a Signature algorithm- and ported the reference implementations to Go. We deviate from a straightforward code translation in order to preserve the security of the implementation, especially against Side-Channel attacks, and to benefit from Go’s special features to obtain a fast and reliable library. We are open-sourcing the library we developed, and it will be available on Github at the time of the talk. We will go through its API and the way one might use it in their own codebase to obtain quantum resistant protocols.

- Matilde is from Kudelski Security, which provides quantum resistant security services. Quantum attacks on quantum computers totally break the security of public key schemes such as RSA. We don't know how long do we have before scalable quantum computers are accessible to attackers.
- Public key cryptography has two main uses. authentication is given by digital signature algorithms. A second case where public key cryptography is very useful is for encryption. Kudelski Security's implementation is open source and available at the following link.
- Our library is both theoretically and practically secure in comparison to the other libraries that provide the crystal sweeps. We integrated countermeasure for many of the published implementation attacks. Regarding the runtime and the size of the outputs, we reported the numbers for the recommended security level.

Hello everyone, my name is Matilde, I am from Kudelski Security and I
am very happy to be here and to welcome you to the presentation. Taking the
postquantum leap with so a bit of background before we start,
the library I'm going to present was developed as part of my master thesis.
So this is technically a joint contribution between Kudelski Security
and my university EPFL. So without me,
I enjoy working with all kinds of crypto two and eventually apply them
towards privacy enhancing technologies. I would like to mention and
thanks one more, my supervisor, Yoland Homay. At Kudelski
Security we are studying state of the art technologies
actively involved in research. We also run a crypto blog and
provide quantum resistant security services. Because what's
more state of the art than post quantum cryptography?
So let's start with a quick introduction. Just like classical
computers work with bits and logical gates to
create softwares, quantum computers use qubits,
and this enables them to perform some
computation way faster than any classical supercomputer
could. This has a lot of benefits in many areas, such as health,
finances, pharmaceuticals. But the problem is that it
also threatens the security of the cryptographic
algorithms that we know and use nowadays.
So quantum attacks, basically quantum
algorithms run on quantum computers totally
break the security of public key schemes
such as RSA, meaning that such algorithms will
not protect your sensible information when facing
postquantum adversaries. Symmetric key and hash functions are
also expected, but not broken. Their security
is weakened, but can be fixed by increasing the
key size. So you might be wondering, yeah, but why
can't we just get rid of public key cryptography then, if it's broken? The problem
is that we are using public key cryptography all the time
in our online world. Whether it is to store encrypted password
with GOPAss, using some SSH,
with traffic, encrypting emails,
using virtual private networks, or exchanging cryptocurrencies,
all of these projects rely on the security of
public key cryptography. So it is very much needed,
but not always lost, right? There exists a new
kind of cryptography, namely the post quantum cryptography,
which as its name states, is quantum resistant,
remaining that in addition to being resistant to attacks that
run on classical computers, it is also resistant
to these new kinds of attacks run on postquantum
computers. There exist many classes of postquantum cryptography
that offer different kinds of tradeoff. For example, a lower runtime,
a lower bandwidth, and it is important to know your application and
your setup in order for you to choose the best kind of postquantum cryptography
to use. So if you're wondering when
should you start thinking about using post quantum cryptography,
the correct answer actually was yesterday, because the
process from scratch to actually complete transition to post
quantum alternatives is extremely wrong. It works
in few steps that include the research and standardization process
where we at the deployment of the implementation,
and then the integration of the said implementation into
the security infrastructures. Right. A problem arises
from the fact that we don't know how long do we have before
scalable quantum computers are accessible to attackers?
And if it is the case before the
transition to post quantum alternatives is finished,
then we are potentially exposing our data,
whether it is messages, bank's information of passwords, to the
quantum attackers. We have no idea of
how long it will take for this quantum
computer to be built and accessible to attackers.
But we should not overestimated it, just like the way that git
did it, for example, with Shawan. So for
the story, Shawan was known to be vulnerable since 2005.
But git suited and waited, and it took a really long time
to finish the transition from Shawan to the
safe alternative shot 2056.
And actually an attack was
mounted in 2012, if I'm correct,
and attackers created a collision on Shao one.
And this had disastrous effect on some repositories.
So if git were to have been faster in this transition,
this attack would not have been possible. And the process
in postquantum computer computing has been really fast.
So, as I mentioned, quantum computers now are protocols,
right? People cannot, attackers cannot really break
the keys and security level of the things that we use nowadays.
But it is a matter of years before fully functional
computers are accessible. And we should not
wait more, because as we saw with a few
examples, crypto agility. So changing crypto
primitives is a true challenge. And moreover,
we cannot simply run with the fact of. But can't we
increase the key sizes? Because if you want something that
is somewhat quantum resistant, taken for example, for Erisa,
you would need to use 1 tb large keys,
not very practical. And before I introduce our library,
I would like to give a little crypto refresher. So I talked
about public key cryptography. And public key cryptography has two
main uses. The first one being authentication.
And authentication is given by digital
signature algorithms, certain to DSA. Digital signature
algorithms produce a signature on the message. Given a secret
signing key, the signature can taken, be checked,
verified against the message, and a
verification key that is openly disclosed.
The DSA have the enforceability property,
meaning that it is very hard to produce a valid signature without
actually knowing and holding the secret signing key. And in that
case, GSA actually do provide authentication because a
signature in that case is the proof that
the signer knows and holds the secret signing
key. A second case where public key cryptography is very
useful is for encryption. The thing with public key cryptography
and encryption is that it is extremely slow and people want
fast internets. So this is why public key encryption
is mainly used in hybrid encryption schemes.
Hybrid encryption schemes are a specific case of encryption
where the public key part is used to transmit
securely a symmetric key and the said symmetric
key will later on be used to exchange the
actual data via symmetric encryption, which is way faster.
And so this step of encapsulating this symmetric key
and securely transmit it is obtained with key encapsulation
protocols shortened to KeM. So in our crystal
go library we propose both a DSA dilithium
and a Kem Kyber. Both Kyber and dilithium are
quantum resistant and very good candidates for
the plus postquantum area. They both are finalists
in the NIST standardization competition and if
you want more technical details, they are lattice based and they stood
out to us because of their simplicity, tight security and overall
versatility. Both have a very high performance and
as you will see, they can even excel some of the classical schemes that we
use nowadays. The main drawback of the crystal
suite is their relatively large output size. And when
I say outputs, I mean public key ciphertext or signature
size. It will impact the performance
of your project, but it will never be a bottleneck, just like a
1 tb key could be. So really our
contribution is that we ported the reference implementation of the
crystal algorithms from the original C language two
go. We make our implementation open source and available at the following
link. We also included the QR code for faster access
at Kudelski Security. Our mission is really to
focus on practical security. So the theoretical part has dealt
with with the crystal papers which include title security
proofs which were reviewed and confirmed. So we put a lot
of effort into having an implementation that is secure
and we integrated as many security features as possible.
We want this security process two be continuous.
So we encourage you to open issues on our GitHub either
to challenge our code or just engage in some kind
of discussion. I will now present our API and demonstrate
how easy to use our library is. So the
flow of Kyber and dilithium is very similar. It works
in two steps. First, the user has to choose a security level
they want to work with, and this will define all the parameters that are
used internally so that no mistake is made, and once all the
parameters are defined, then the core functions can
be used. Our library also has helper functions other
than the core functions, but I will not go much
into the detail as I want to say very high level. If you want
to learn more about all the features that our library has,
I suggest to go and read the readme.
So the two steps that I mentioned are really clear when
looking at the API. So the functions are really divided into two
groups. The first group are the type functions that define a
delifum instance with a specified security level. So from
top to bottom we have an increasing security level, meaning that delifum
two is the lightest schemes, while dilithium five
is the strongest scheme in terms of security taken.
Once the parameters are defined, the code function of gefium signature
can be invoked and the code methods are of course the key generation
functions, the signature and the verification functions.
Otherwise it looks like this. First a user wants to
go and have a signature protocol, agree on
a security level and create the dailyfam instance.
Then on this delifam instance they can call
the core function. So the first user, for example, generates the
verification and signing key pairs.
The public verification key can be openly
disclosed. Then when the first user wants to sign the
message, he can take his sign in, key the message and
produce a signature signature that can be transmitted along
with the message and checked again. The public verification key
that the second user receives. If everything went fine and the users are
honest taken, the boolean returned by verify is going to be
true. Similarly for Kyber, we have two groups of
function. So front, top to bottom, we also have
increasing security, meaning that Kyber 512 is the
lightest and Kyber 1024 is the strongest in
terms of security. So Kyber being a key encapsulation
mechanism, the core functions are different. Now we have the key generation
function that creates public and secret key pair
and we have the encapsulation and decapsulation functions.
The encapsulation function, given a public key and some
coins creates a shared secret and the
encryption of the state secret. So the encryption of the shared
secret can be transmitted to the secret key holder for it to be decapitulated
and thus the shared secret recovered.
So for practical example, similarly,
the user have to agree on the security level they want to use.
In that case they want to use lite security. They create the
Kyber instance and invoke the core functions. So following the
flow of the kem, the first user generates the public and
secret key pairs. Openly disclose the public key,
and the second user can now engage in the translation
mechanism by taking this public key and generating
a shared secret and its encryption. By calling encaps,
the ciphertext can be shared back to the first participant,
who can use his secret key to recover the shared secret.
In our case, the value of fs is going to
be the same for both participants, and can be used as
symmetric key material to then go further
into this hybrid encryption process.
Performance wise, what do we have? So if we're
talking about security, our library is both theoretically and
practically secure in comparison to the other libraries
that provide the crystal sweeps. We integrated
countermeasure for many of the published implementation
attacks, so namely the side channel attacks.
Regarding the runtime and the size of the outputs,
we reported in this table the numbers for the recommended
security level. So which is the medium one? And you can see that
a function call takes from a fraction up to two milliseconds,
and the size of the outputs ranges from 1 megabytes.
So we thought that this number might give you some idea of
the practicality, but still be a bit abstract. So what we did is
that we actually compared the performance of our library against
the library that are contained into the go crypto official package.
So we compared dilithium against ECDSA
and Kyber against RSA. OAB for can
equal security level, of course, in the classical setting, because ECGSA
and RSA are of course broken when facing quantum
algorithms. And as you can see, our scheme, our library
in blue is actually way more performance in term
of runtime than the go crypto implementations highlighted
in orange. But the tradeoff becomes evident when looking
at the bandwidth that is being used. Just as like I mentioned,
the output size of the crystal suite
is way larger than what we use to deal
with. Nevertheless, we wanted to test the practicality of
our library. So what we did is that we implemented it and integrated
it into the wireguard protocols. And when adding quantum resistance to
the Wireguard protocol, while spoilers alert, it is still
practical. It has another head of zero two milliseconds
regarding the runtime and requires sending two extra
IP packets. This overhead is totally
acceptable, especially knowing that the transition
towards postquantum schemes must happen with the arrival
of quantum computers. And if you want more details, we encourage you to
attend our talk at Nistford standardization
conference. So to conclude with,
we presented a library that is fast,
secure and easy to use, and we therefore more showed
you some experimental results that you should use as motivation to
start integrating post quantum cryptography in your project
as last word, I would say that if you're going to use cryptography any
kind, you should make sure that it is very safe,
especially regarding implementation security which is
often overlooked, and make sure to use library
that are secure in that aspect, just like we made
sure to do with ours. So I hope that you enjoyed this presentation.
If you want to learn more about post quantum cryptography in general,
I added some other material that might be of interest to
you, so thank you for very much for your attention,
and if you have any questions, feel free to contact me.

Priority access to all content

Video hallway track

Community chat

Exclusive promotions and giveaways