 please welcome our next speaker, Christian Pacwan, on integrating post-quantum crypto into real life applications. Thank you, thank you. So welcome everybody to the last session in the crypto and privacy village. First of all, I'd like to thank the organizers for an invitation. It's a great pleasure to come here at DEF CON to present my work and along with the work of my esteemed colleagues from the post-quantum crypto group at Microsoft Research. And today I'll be talking about our experiments and incubation projects of integrating post-quantum cryptography into real life applications. So a little outline, very straightforward and logical, start to introduce what is quantum computing, the quantum and then talk about what we need to do after that in the post-quantum world and then I'll discuss our integration experiments. So first of all, just a little poll, like to know who's familiar, not just the word, but quantum computing works in the room. Oh, fairly good. How about on YouTube? See that later in the comments. Okay, so we've all heard about quantum computing, at least the words. And we've been hearing the quantum revolution is coming. Well, I've been hearing that for a very long time. I was a very young student at the University of Montreal, 20 years ago, was studying quantum computing and quantum cryptography with under supervision of Gilles Brassard, who co-created or co-discovered quantum key distribution and quantum teleportation. So it was really hard to be in that lab and do anything other than quantum. It was quantum everything. Then I decided to go and get a job. It was a bit hard to be applied cryptography and doing some quantum things at the time. So I went off becoming a quantum or crypto developer, work at a company zero knowledge systems where we built a predecessor to TOR, did some PKI work. Then I went to a company called Credentica where we built an anonymous credential system for PKI with privacy and technology, developed a U-proof technology, ended up at Microsoft. And then many years later I'm back at this quantum thing. But this time on the other side of defense, not trying to build a quantum computer, but trying to defend against it. And I'll talk about it a bit more. So it's hard to just keep track of what's going on. Every week there seem to be a new result, new quantum computer being built bigger, many more qubits. I can't put slides anymore of a news report. Just put the search slide and search link and then you'll be able to find the results of the week. Also down the hall my colleagues at Microsoft Research are building or trying to build a quantum computer. And also they just released this year a Visual Studio programming language Q-sharp in which you can program a quantum computer. So we don't have the chip yet, but when we do we'll be able to just plug in that software and be able to use it. So they're trying really hard to do it. Which mean for us crypto specialists we have to do some things to defend against it. We'll talk about it later. So first of all what is a quantum computer? Well very simply it's just a machine that operates with the laws of quantum mechanics. Computers we have they all operate with the classical laws of physics. We understood them. But when we start using smaller particles that follows different laws of physics there's some really weird things that are happening. So first the basic of a quantum computer is a qubit, a quantum bit. And unlike its classical counterpart it's not either zero or one. It can be zero and one at the same time. A bit like that. Famous experiment. Toth experiment of the cat that can be dead or alive. Showing your cat. Well a quantum bit can be zero and one at the same time. Which is great if you want to build algorithms with that. Because imagine you're trying to solve a problem trying let's say trying to find the path in a maze. Well if you can see zero is turned left, one is turned right. Then you can put it both zero and one at the same time. And then have both path be taken at the same time. And all have the computation paths be followed at the same time. And at the end one of your parallel paths of computation will have found the exit to the maze. The problem is that when you look at the solution, when you look at your quantum register, at your memory, this quantum superposition is not visible to you in the classical world. One state gets picked at random depending on the amplitudes alpha and beta of the quantum bit. And only one result at random gets returned to you. So great. Parallelism not great output. So quantum algorithm designers they have to find ways to use quantum interference like if you remember your physics class this double slit experiment where you can put two holes in a piece of paper, shine some light and then kind of the wave properties interference makes a little black, white, black, white pattern because the waves interfere at some points and where there should be lights there there's not because the light particles the the interfered and cancelled each other. So we can do the same with quantum algorithms where we can just have some paths being destroyed and only the computation results that you want to get popped up at the end of the computation. So it's a very subtle and hard art to design quantum algorithms. But there's a few that are being around. Another strange property is that qubits can be entangled. Entangled means that imagine you have two coins and you take them apart and you flip them and you're going to get zeros and ones and double zeros, double ones, zeros and ones, ones and zeros. But if they are quantum coins and you have them interact in a special way and they become entangled and you can separate them and they can be very far apart and you flip them they're always either zeros or always either one. Either tails or head or tails. You'll never see tail and head and head or tail. That's really weird. That freaked out Einstein he called that a spooky action at a distance because he imagined that one coin would get a result and would need to send a faster than light signal to the other coin so it matches its response. So it's hard to understand what's going on but it's just an observable fact that these particles can be entangled and to always share a state across space. And that can be used in quantum algorithms as well. And quantum computers can be built with all sorts of things. The spin of an electron, the orientation of a photon, my colleagues are betting on this topological computer being used with anions that could provide better stability with bigger machines. And Richard Feynman, a famous physicist, famously said that nobody understands quantum mechanics. You just get used to it. For us computer scientists we don't really care. I don't ever care how it's built. It's just a black box and you give me these mathematical properties and we can design algorithms to solve new problems, new class of problems. So it's all great. Some of my colleagues are very excited about that. Security folks are a bit more worried because although quantum computing provides great advances in many fields and chemistry to find new ways to design molecules and optimization problems and machine learning, it has terrible consequences for cryptography because there are two algorithms. Ironically the first two algorithms that I have known in 20 years ago were only used to break cryptography almost. The first one here is the quantum menace. This is Peter Schor. Designed in 94 is famous algorithm that by doing what's called period finding in our algorithms it can be used to factor large numbers and find a discrete log of numbers which are the two problems underpinning RSA and DSA and the elliptic curve variants like ECDH, DSA. So using Schor we can basically break most of the cryptography, all the public key cryptography that we use today on the internet. The other algorithm that's very important is Grover algorithm. It allows database search function inversion. It improves it by a square root factor. Essentially it's kind of described as finding a needle in a haystack. It's able to find a unique solution to function that you're looking for. And it can be used to help the brute force of finding a digest in hash functions or breaking block ciphers like AES. And it has consequences but they are not terrible because of the square root improvement what we need to do to secure against this algorithm is just double the key. The key size of AES or double the hash size of Schor. 256 to 512. So, okay. Sounds bad. So how long do we have? When is this quantum computer going to be built? Well, there's been a lot of studies about that trying to see what's the best estimate when the Schor algorithm will be built. Michele Mosca is a professor at Waterloo. As a often cited quote that by 2031 there's a half chance, a 50% chance that we'll get a quantum computer. And he revised that in 2017 to last year. This one in six chance, 10 years ago. So. And another researcher, Simon Benjamin from Oxford, if you're willing to go Manhattan Project, meaning you just put all your effort as a big government behind it then maybe, yeah, six to 12 years. Some of my colleagues also shared this 2030 deadline or estimate. And that's a little diagram that shows you the difference between breaking RSA 2048 with a classical or quantum computer. So you need about a number of bits for the algorithm. And for a classical computer it would take billions of years. So we're safe. We know that. For a quantum computer, depending on its operational speed, so at one gigahertz for example you would just get a few seconds. So it's a game changer. It breaks it totally. So now what we need to do given the quantum people would be very optimistic because yeah, we're going to build it soon. We've been trying and we're going to build it soon. So I don't necessarily believe that we're going to have a fully functional computer in 12 years. But as security specialists we have to be careful and assume the worst case and be ready to have something else. And we do need something else. We need alternatives, so-called quantum sales algorithms or post quantum cryptographic algorithms. Which are algorithms that are secure against a quantum computer. Doesn't mean that they run on a quantum computer. That doesn't mean that at all. And it's not quantum cryptography which is another field or quantum key distribution which is using quantum mechanics to exchange a key. So these are all separate subjects. This is normal classical cryptography for which we don't know any classical or quantum algorithms to break them. And that is the big field of post quantum cryptography. Which is getting more and more attention. But first question we can get now is why would we care about this now? Okay, we'll think about it in 10 years. We have time. We're busy. We have all sorts of things to do. We have block chains to implement. And all sorts of things. Well, the main, one of the main reasons, the big reason is that the secrets you have today are at risk. Not to be encrypted now, but they can be captured now, recorded now and decrypted later. All major countries have the capabilities now to just save the internet traffic and decrypted later at their leisure when they have a quantum computer. So that's very significant. Another more practical but no less important item is that it takes a long time to update standards and software. So we need to understand today. So if we are to replace these algorithms, what does it mean to plug them in TLS and SSH and to update all our software stack? We know at Microsoft we have a lot of experience from the flame malware and all the other stocks next and all. Attacking very old hash functions like MD5, these MD5 collisions. We know it's been outdated, it's been replaced but there's some very old software that's still running it and some weird configuration takes a long time to get rid of it. So we need to make sure that by the time the quantum computer is here, all the insecure algorithms are gone. And lastly, one thing that's very important or to consider is the ability to use hybrid modes. So to be able to use classical cryptography with post quantum cryptography in a safety net, to have the best of both worlds, the two protections. And that's going to be an interesting scenario for a while. I'll describe that later. So most of the industry now is focused on the NIST competition. NIST is the National Institute of Standards and Technologies in the U.S. It is basically the de facto, they define the de facto standards for the cryptography used around the planet. Whatever NIST does typically is followed around the world. They've basically made a call to replace the cryptography that we have today with post quantum version. So they have this competition. It started in November of last year. And they're basically looking for new signature and encryption mechanisms with five security levels. And they got 64 submissions in their competition. 19 signature schemes and the rest are encryption or key encapsulation mechanisms. So you can see all the details on that, at that link, all the submissions. And some of the work I'll be presenting later is integrating some of these in higher level applications. And they think that they're going to have standards by 2022, 2024, so to give us time to integrate so that we're ready by this 2030 deadline. So what do these post quantum algorithms look like? We know we cannot base them on factoring and we cannot base them on discrete log because they're broken by shore. So there are many more families of mathematical problems that we can use to build new type of crypto systems. The first one, the most popular one is the lattice based systems. They're based on mathematical lattices. And as one of them has been around for a long time, and true has been around from the mid 90s, always been competing with RSA, but there was no ever reason to move away from RSA. So never got much traction. But now it's kind of, some people have been looking at it. And also me and more newer versions of data problems with provable security. For example, they're learning with error problem. And it's ring version, ring RLWE. And I'll be presenting one scheme that's been designed by Pickert and some of my colleagues have been designing this scheme BCNS to plug it into TLS. It's been improved, optimized by another team and became New Hope. And then there's some other subsequent scheme like Frodo that comes back without the ring. We'll talk about it in a few seconds. Another family is a code based systems. They're based on error correcting codes. They've been around forever. And they've also been proposed as a public system at the same time as RSA. So they've been around for a long time. But they have some disadvantages. They're huge keys. So they were never considered as an alternative to RSA until now. And there's been a lot of code based system proposed, 19 of them out of the 64. Another one is multivariate systems. So they're based on essentially multivariable polynomials. And you have to solve the equations. Also developed in the 90s and now nine submissions based on this family. The other one is ash based systems. So these ones are also very old. Like a lot of these ideas are dated back from a long time because researchers, cryptography researchers have been busy in proposing things. But in practice we're very conservative. We pick the standard and we are not allowed to be creative and take new ideas in very often. Until we're forced to. So this one signatures based on the import signatures and Merkle co-inventor of public key cryptography designed this Merkle signature scheme. It's a tree of ash digest. And there's been newer proposal LMS and XMSS extended Merkle signature scheme I think that means. And these will probably be considered for earlier adoption than what the NIST competition because they're very well understood. We know the impact of quantum computer on ash functions. And we know that Grover is optimal so we know it's like the worst case scenario. We can go with that and we'll be safe. And there's some pros and cons with the ash tree versions but at least we know that they'll be secure. And finally there's the other category. There's seven of them. It's one that we've been working on based on isogenes. They've been in the talk last year in the village about it on SIDH. And another one from my colleague is based on symmetric ciphers and zero knowledge proofs called picnic signature scheme. So there's a wide thing. So NIST and the crypto academy I would be very busy to analyze all that. You know you need a specialized PHG in each field to be in a sentence in one scheme. So it takes a lot of it's hard to find somebody with the knowledge to look all of that. So the old industry is looking at that in detail. I don't want to go into details about these slides because they're very small. But these are slides from NIST after the competition deadline that just showed some results of performance that they ran. You see a key size. So you see the different families. So lattices typically perform very well. And some others like the code base for example have very large keys, public keys. And so it might be more difficult to integrate. Same thing with signatures. I'll let you inspect the slides at your leisure to see the details. I'm just going to fast forward that a little bit. So my colleagues I've been dealing more with crypto integrations and programming these things. Some of my colleagues are actual mathematicians building these schemes and these are the four collaborations we add in the competition. As you can see it's always multi organization teams. A lot of collaboration across the industry and academia to make these. So Frodo is essentially like new hope but without the ring assumption in the learning with error. So Frodo is you remove the ring, get it. And so it's team felt it was more secure that the ring learning with error might not be as secure as we know because it's very new. And the just learning with error counterpart is safer. It's lower but it's safer. Psyche is updated SIDH. It allows you to reuse the keys. So it felt it was a better design for the submission. Picnic as I described it a little bit and Qtesla is a ring learning with error signature scheme. So all the code is all open source of these things like all the submissions and you can take a look and experiment with them. So one thing we did is trying to plug these into real life applications like in TLS and open SSL CI works. So after doing that a few time independently it gets bothersome. So along with a colleague Douglas Stibilli at McMaster now he's at Waterloo. He started this project called Open Quantum Safe and we joined and integrated our solutions and helped designing the signature API in that project. Essentially the goal is to have a framework where you can plug in all these post quantum algorithms and then in turn you take the framework, this common API and integrate it into your applications. So if you take that and plug it into Open SSL and then you have a new scheme then you can just integrate it in OQS and then you get the integration into Open SSL and Open SSH for free. So it's very useful. It's been useful to us. It allows us to do prototyping really fast. And it's also open, right? So we're open to invitations. I don't know that there's a lot of people in this room. I'm sure some of them might know or have been involved with one of the 64 submissions. You might want to take submissions. If the core team didn't have time to take a new algorithm and plug it in we're trying to do that but you can accelerate that by submitting a pull request with your own algorithms and integrate it into OQS if you want to see how it performs in TLS for example. There are two branches. One is the master branch which allows us to have a tighter integration and reusing a random number generator in all the constructs of OQS common code and it's meant for integration into applications and with the goal to ship it. And there's a NIST branch which has a more lightweight approach is just to take the NIST submissions and easily integrate them without touching their code base too much and just to be able to compare them. So okay. You get the link there so feel free to come use that project or contribute to it. We're welcoming feedback and new contributions. Okay so now I'll be talking a bit about the integrations that we've been doing. So the first one we did was in TLS 1.2. We've integrated into open SSL 1.0.2. Open SSL has two layers. There's the bottom crypto layer and there's the top SSL layer. So to do the key exchange we only had to touch the SSL layer because when there's the post quantum crypto which is branch off to OQS rather than using the low level crypto API. But when we integrated the signature API in the PKI we added to touch the PKI ASN1 infrastructure which is in the crypto layer. So that was a bit more work. Actually a lot more work but the result is that you're able to issue post quantum certificates and use them in TLS to do authentication. So for key exchange we have two modes. We define new cipher suites and we also defined hybrid cipher suites in which you essentially do a classical key exchange and a post quantum key exchange and then you take the results of both and you co-continate them and that's what you feed into as the master, pre-master secret that gets fed into the key derivation function of TLS. And that gives you double the protection. So we might be worried that you're doubling the time, the work so it might have bad consequences on performance but we'll see that's not that bad on the next slide. And we also as I said did the post quantum certificates and there were some problems there. Some of these schemes for example Picnic has a very large signatures. So the signature size in TLS is to the 16. So everything passed the level one of Picnic. There's level one, three and five but so everything three and five didn't fit in TLS. So that's why it's useful to do these experiments. Right now we can see and give feedback to the designers that okay it's things too big it won't fit so the crypto designers might want to tweak their things, remove a few bits here and there so it fits into unknown algorithms that are targeting. So that's why we were able to in fact this work was done before the submission didn't fit change a few things and what was submitted to NIST made sure that would fit into TLS. And also tested in Apache 2.4, .25 at that time and worked well. So we could deploy that and so can you, you can test it, just download our fork and you'll be able to test that. If you don't have time to take notes in there that's all in the open quantum safe project everything is listed there with all the sub projects and forks so don't worry about that. So this is an interesting diagram that shows our experiments running these algorithms in TLS. So these are pre NIST submissions so all the algorithms are either been optimized or changed to be more secure so take the performance as a grain of salt here with a grain of salt but the, what's interesting is to see the trend. So ECDHE, the orange line here is the baseline that's basically what's being used, favored today by web servers. We see that some of the post quantum ones like New Hope is the lattice ring learning with error, quite efficient, even more efficient than ECDHE. And the Frodo one is the same one without the ring, without the ring so just the learning with error option so slower but not as bad. These are connections per second so here it's 900 up to 1600 and ECDHE like 1200 or so. So it's not bad like things are going to have to give at some point we can't have the same efficiency as we have today in the world while the quantum computer exists but things are not catastrophic that we see that we've seen some, you look at the specs of some of these crypto algorithms, this is the terrible, the key sizes and the running time but when you plug them in real life like with the good settings you see that's not that bad. And the other interesting thing is that here is we retrieve multiple payloads like web pages of different sizes, one byte, 1K, 10K and 100K. So normal websites today they're quite big so the cost of the crypto gets amortized like if the more the bigger the websites, the page then the cost of to do the TLS negotiation gets amortized with the download time of the page so the more we get to normal size pages they all kind of merge together and the cost of the post quantum there is not very apparent. Bottom line, this stuff is quite practical and can be considered to be used today in the hybrid mode and the other thing I haven't mentioned is the hybrid modes. You have here new hope plus ECDHE run built in parallel so very close to ECDHE so the cost of new hope. And the same thing with Frodo and Frodo plus ECDHE here so you, so running the hybrid which is the recommended way to go for a while because you want the security of the classical system today with the protection against future quantum computer you want it now and it doesn't cost you too much to have it. This is a similar diagram with signatures also don't care about the numbers too much but the clustering we see that comparing here a picnic and RSA for the signature just because that was the only algorithm available in OQS when we did that, that's pre-submission and yeah so picnics more expensive as a very big certificate but at the end of the day when you plug it in the real world TLS it's really not that bad. Okay now most interesting more recent work the TLS 1.3 integration so TLS 1.3 was officially released yesterday and we already got it working and OQS did that overnight. We've been doing on the draft specs and the draft code and this is the integration we did in the open SSL 1.1 and beta 4 so it's really nice to work with TLS 1.3 I'm just gonna put all the information right there because it's a way nicer protocol state machine is cleaner so it's easier to to deal with integration points in particular the key shares that's where you put all the crypto information and that you exchange and it already supports hybrid with with the pre-shared key PS key and ECDHG so there's already these mechanisms to negotiate multiple keys which is nice that we can use. The Bayes spec consider everything curves because they only use elliptic curves so we have to cheat and call our self curves that's what we do to define new algorithms but I figure that's gonna be fixed at some point and somebody will write extensions probably want to retrograde the retrofit RSA in there I'm sure some people will do that so somebody will define will agree at some point on post-quantum official ways to integrate so right now just test and prototype we just call ourselves curves and we tested that in the NGIX web server just because Apache didn't support TLS 1.3 on the master branch when I tried that but this web server did also you can use curl to do your tests and everything works and the details are also on this open quantum safe wiki page. Alright I wanted to uh am I doing on time? Let's see oh good. Um I guess I'll finish the presentation first and now I'll get to the demo afterwards. So a little bit about hybrid scenarios um I've been talking about the key exchange hybrid and there are multiple ways to go about it so the first one the one that we have implemented is called the naive implementation you essentially just do the classical key exchange and the post-quantum one independently and then you just mix the results you concatenate the results feed that into the key derivation scheme. Uh you just need to give a new name to this algorithm as a combo scheme so you define a new uh uh like a new identifier for that and then you can call it in your library. There are more advanced proposals out there uh one by uh white and one by Schengen's Stabila they have different pros and cons one that supports multiple key shares you could mix uh classical and and the lattice scheme and the code base scheme and like like multivariate scheme all in there to to edge your bet that's the roulette here to edge your bet you have to pick a number you can pick a color or a series of numbers so to uh to be safer uh the other one is more of a dual just two schemes and I did not implement that in this integration just because uh open a cell was not ready they didn't even support multiple key shares at the time which is needed by the base spec so when they do and we can take that code and upgrade it and do more advanced uh hybrid schemes. For PKI it's uh we haven't done that yet but it's a bit uh future work it's also uh not as urgent because for key exchange as I said you can record a traffic now and decrypt it later so the attack is valid today for breaking the authentication it's an active attack so you need somebody to be able to break your signature or forge your certificate during the lifetime of the certificate so let's like let's say the certificates valid for a year so if we have quantum computer in ten years and nine years we'll care about that but we're starting to think about it so uh in a year or two we'll probably have uh a solution for that and the question is how do you convey two signatures in the TLS exchange so do you have two certificates do you have a certificate with two public keys one in an extension do you use the TLS extension mechanisms to provide a second public key multiple ways to go around it about it and this paper is a good overview of all the problems that needs to be solved in that case but as I said it's not as urgent uh for hybrid deployments today. But our performance measures with TLS 1.3 that was run just on this machine on local hosts between the client and server just to get ballpark figures so uh nothing's optimized but uh just to to get the ballpark and that's with the schemes that were in OQS some of the schemes um so we see again that the lattice the ring version of the lattice performed very well very comparable to uh uh e-c-d-h-e which is the orange uh baseline and when you remove uh the ring assumptions you get something like Frodo and it's a bit uh not as efficient but more more trusty uh more trustiness in it and something like Entru for like this something like Psyche which is really nice because it's uh very comparable to elliptic curves the closest thing we have to elliptic curves it can be a drop in replacements uh and a lot of of protocols that assume elliptic curves defilement type exchanges unfortunately they don't perform as well and for signatures we get the expected again Q-Tesla 1 lattice scheme performs very well as well as uh uh e-c-d-h-a with uh P-256 and picnic it's a simpler assumptions in a way hash functions uh and uh performs just a bit slower than RSA okay so that was one TLS I was been a lot of work in TLS cause it's an important protocol we also did other integrations one is an SSH SSH uh uh uh as another protocol I mean it's you know similar to TLS in spirit so you can go in and replace the crypto parts with the post-quantum ones and uh it's another exercise that we did um and the latest uh software that we have is a fork of open SSH 7.7 uses the key exchange algorithms in OQS so the more we had and uh refresh that fork then the more algorithms we'll have in there and it supports post-quantum and hybrid modes uh for the key exchange only no no signatures yet so I don't want to spend too much time on that cause it's a little bit uh similar ideas but you can check it out in our fork if you want to try so another uh interesting integration point that we have is open VPN so unlike other VPN solutions open VPN uses TLS uh for its uh security so which is nice and uses open SSL so we can use open SSL fork to uh to protect the VPN exchange and so we have a fork of open VPN that allows you to test the key exchange algorithms and use either RSA or picnic certificate so what's nice about that is that for a long time uh in the future there's gonna be applications that will never be updated or there's gonna take a long time to be updated so there's gonna be a long tail set of applications that uh will not be uh quantum safe for a long time so what you can do is just have your classical software running and just wrap it in a VPN post-quantum VPN tunnel so then you don't have to touch the applications and you can just secure the channel and you get uh great uh protection against quantum computers uh in a centralized manner so we tested that for example we built a client or Raspberry Pi and when those clients communicating with Azure VM uh Linux VM and uh to do that also have your did a little experiment with you have your mobile phones connect to an access point and then that thing calls your web services or a post-quantum VPN so don't have to change the phone or have to change your applications it's very cheap and easy way to achieve that and uh that's projects available also on our get up page and uh you're welcome to try it another integration that we did was in hardware to see if we could uh actually write these these post-quantum libraries um in secure hardware so we partnered with the Ultimaco tried it on one of their HSM and essentially we just using their their uh the reference implementation of picnic and and compile it for the HSM uh little bit of of engineering there and then got it to work able to issue uh picnic route certificates on the device and be able to issue and users RSA certificates and everything works as expected and the details of that can be found in the picnic uh NIST submission so if you're interested so all this goes to to say that we've post-quantum cryptography is uh it's it's it's just crypto algorithms okay it's nothing fancy about it there's just things that we have not studied for 20 years so they're they're new but other than that there's just regular algorithms they can be integrated across all the software stack and and hardware so at this point it's a matter of us and community and if any of you have uh software that they realize on cryptography you can take these things and starting with the open quantum safe project and try to integrate it and see what breaks so we want to we want to see what breaks and and and no you as as as owner of of of crypto software you want to see uh if you put it these new algorithms what's going to break so you can be agile and be able to change it when it's ready not today but in 10 years when you'll have to change then you want to be ready and good thing to try it now and you can give feedback to this crypto designers then this competition is quite uh new since recent so this these algorithms are able to update themselves before the final so if we find out that oh just by just changing this uh this properties reduce the the bit size by one or two it's going to fit this application it's good feedback for the designers of these algorithms and uh hybrid solutions important thing to consider and uh because it's cheap way as we've seen with TLS it's not a big impact but it could have a great protection for future proofing your your your data against quantum computers and also a centralized solutions like having a post quantum VPN allows you to get a blanket protection without modifying your legacy applications or touching all your applications today so that's that I'm gonna switch to the TLS demo I'm gonna run it on local hosts because you know DEF CON so I will not communicate with a real web server but everything is real code running here I apologize it's very small so um let's see I'm gonna try to type and hold the mic at the same time so what the first thing I'm gonna do this is in our open SSL uh fork the first thing I'm gonna do is generate a certificate you can really read but it's the standard open SSL tune the request tool to generate a certificate the only thing that's different is I I'm requesting a Q Tesla key all the rest is standard open SSL so there it goes it's very fast as expected let me just print out the certificate okay it's like it looks like an RSA size key like some crypto algorithms will just scroll a few screens until it ends but Q Tesla is a very uh compact scheme and very efficient being a lattice one the key also works pretty well so now I'm gonna just uh start a server so it's the S server tool specifying the certificate Q Tesla one that's SRT and Q Tesla key and asking for TLS 1.3 alright there we go and now on the other console I'm just gonna have the client uh it's gonna ask for Frodo so it's gonna be a Frodo key exchange with the authentication is gonna be provided uh with Q Tesla so it's a fully post quantum key exchange and authentication transaction and it's gonna talk to the port here so there you go because the exchange got the certificate um you're gonna have to believe me what's written here because it's not very clear but signature Q Tesla one and the server P2 oh I actually asked for the the hybrid um P256 here so you use that's the hybrid scheme so I did ECDHE with P256 curve and using Frodo and we get a TLS 1.3 connection so now let's try to uh deploy that in uh actual web server so I'm gonna copy these certificates I said copy Q Tesla dot star into my end jinx configuration directory it's asking for my password first try very nice so let me just okay so I'm gonna just look at the end jinx configuration and we can see here I'm specifying the Q Tesla certificate as the SSL certificate and then the last line SSL protocols TLS 1.3 so I'm just gonna start it alright the web server now is running and I'm just gonna repeat my client call same thing so establish the communication and then we can make sure that the HTTP connection works I'm just gonna get the default web page get slash and I get the HTML welcome page back all this calling from a TLS 1.3 post quantum client to TLS 1.3 post quantum server everything works well and you can deploy that and have fun today in the hybrid mode and get protection against the quantum computers that uh might be built in 10 years or might actually be built in some very dark rooms and very powerful organizations so that completes the talk I'll be happy to answer questions if you have