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.