 Let's go right away in the next talk with Kutian Paquette. He's a crypto paquette, Paolo. He's a paquette, he's a crypto specialist in Microsoft Research, Security and Cryptography team. He's currently involved in projects related to post quantum cryptography, such as the Open Quantum Safe project. He's also leading the development of the U-Proof technology. He is also interested in privacy enhancing technologies, smart cloud encryption, and the intersection of AI and security. Prior to joining Microsoft in 2008, he was the chief security engineer at Credentica, a crypto developer at Silanist Technology, working on digital signatures systems, and a security engineer at Zero Knowledge Systems, working on Toralike systems. So give a good round of applause again for Kutian Paquette on his talk on Stake Quantum Safe, future-proofing encrypted secrets. All right. Hello, everybody. It's good to be back virtually in Montreal. I'm a Montreal native and a native French speaker. She detects an accent. That's the reason. So today, I mean, we are staying COVID-19 safe by doing this virtually, which is a great idea. And I will explain how to Stake Quantum Safe as well. And the goal of the presentation is to explain how to future-proof our encryption systems to defend against the quantum computer. So as it was said, my name is Christian, and I work for Microsoft Research. Well, since I like to talk about me, let me talk a little bit more about me. I, we've all been hearing about quantum computers lately. They're all over the news. Well, in fact, I've been hearing about this for a long time. I was a young student here at the University of Montreal almost 25 years ago. And that's where we studied quantum cryptography and trying to build this new things. I promised to revolutionize the world of cryptography and computing. After that, I joined a more practical side of the industry. I became a crypto engineer, worked for many years until I landed a little bit more than 10 years ago at Microsoft, currently in the crypto and security team, where at MSR, where we work on cutting-edge cryptography, things that will end up in products in five to 10 years. And our current focus is a post-quantum cryptography, which is the subject of this talk. I was here last year, an insect to present on the subject. So the goal of this year's presentation is to give an update on what happened in the field and what can be done to start migrating our systems to post-quantum cryptography. We've heard about the quantum revolution and the promises that this magical computer will have on the field of computing. Using the special properties of quantum mechanics, computers that built with such properties could magically calculate all sorts of parallel computations at the same time, resulting in algorithms that are impossible to implement on normal classical computers. So there's a lot of R&D around the globe on this trying to realize the vision of this quantum computer. In fact, I have some colleagues at MSR that are building both the actual physical stack, the quantum gates, and I have some other colleagues building quantum software. You can download a QQiri, a quantum development kit for Visual Studio. It would start programming in Q-sharp to implement these quantum algorithms. So now they could be just, now they would be simulated on a normal computer, but as soon as we can plug in one of these, quantum computer, the same software would work. So for all of you aspiring quantum hackers, and you should start to learn these things now. So one big problem for the field of security is that quantum computers completely break our existing cryptography. Indeed, in 1994, Peter Schor developed this famous algorithm that allows to factor and find a discrete logarithm of large number, large numbers. So essentially breaking the RSA and ECDSA algorithms. That also it's valid for Diffie Elman and the electric curve variance. There's also another famous algorithm called the Grover algorithm that breaks some symmetric primitives such as hash functions and block ciphers like AES. But not in a catastrophic way. It improves the attack. And by simply doubling these primitives, we're able to resist the quantum computer. So this is less of an issue. But for asymmetric primitives, like asymmetric encryption and signatures, it's a terrible result. And essentially breaks most of the protocols we use on the internet today. So you can say bye to your HTTPS TLS connections and your SSH connections to your servers, your certificates, your update channels are using signed messages, your private communications like signal and even your bitcoins all done if a quantum computer is built. And there's different opinions on it. When will this be implemented? Some say five years, some say never or a longer time. But there's a big consensus around a quite serious possibility that these could appear within a decade or two. And being security practitioners, we have to take this kind of worst case scenario in mind in order to migrate to a quantum safe cryptography. That is using changing our base algorithms to rely on problems that we don't know how to break with a quantum computer. And one question is why we wanna do that now? Why can't we wait in 10, 15 years like we end up in Y2K if you're old enough to remember? Just do it the year before and panic and we'll be safe. Well, the problem is that the data that we exchange today on the internet is at risk because it can be captured and equipped it later with the help of a quantum computer. So if you have long live data, data that has a long live threat model that needs to be secure for multiple years, you have to take that into consideration. Another point is that these cryptographic algorithms are using protocols like TLS, SSH, et cetera. And these take a long time to update. They are designed by committees and we need to define new extensions and agree on them so that they can be used in an interoperable fashion on the internet. And also, new quantum safe algorithms would behave differently than the RSAs and the DSAs that we know. Some could have longer keys and message signature sizes. They could take longer to run. And we don't even know if the code that we wanna modify is easily modifiable. When we transitioned from MD5 to SHA-1 to SHA-2, we found some horror stories in some code bases where these things were so hard coded that update was difficult. So when you run the clock backward, taking in account your threat model time and the time it would take to change the infrastructure, you get a date of when you need to start this transition. And for many use cases, this date could very well be yesterday. Fortunately, cryptographers are on top of this. NIST, which is the National Institute of Standard and Technology, this US body that dictates the crypto permit is used by the US government. It is also a de facto standard organization for the world because most of the NIST standards are adopted around the globe. So they into 2017, they made a call for a new set of algorithms that could resist the quantum computers. And we're at the beginning of last year, we went into a round two where the 69 proposal in a Thanos-type fashion that reduced to a smaller subset of these 26 remaining and some of them got merged together. And we are now just at the, we're expecting very soon this summer the announcement of a round three survivors of all these algorithms. So we expect a smaller list and in two to four years, we're expecting new draft standards that would make these algorithms standards unavailable for the industry. So the question for us now or dealing with integrating algorithms or have protocols and services that use cryptography is how can we get ready? And more importantly, what about the data that works today? Should we ignore these few years or can we do something today to mitigate the quantum risk? Well, there's a lot, many things can be done today. And that's what I'm gonna discuss in this presentation. So we joined this open source project called the open quantum safe project where we offer a framework integrating multiple quantum algorithms from the NIST competition. And this allows to make some experiments and study them in various environments. So as you can see from the list here, it's a big industry and academic collaboration project that's led by the University of Waterloo. And we've integrated the open SSL library into different applications and TLS, SSH and VPN, for example, through forks from the popular boring SSL, open SSL projects and open SSH and open VPN. We also have some wrappers in different languages. If you're interested to use OQS in C++ or C-Sharp, Go, Java or Python, we have these wrappers available as well. So the openquantumsafe.org project allows you to get all these links and to learn more about the project. So the main thing I'd like to discuss today are the results of two studies we did using the OQS project. The first one deals with integrating this post-quantum cartography in TLS and SSH. So we wanted to see what would be the impact of changing these algorithms and specifically how to integrate it in a hybrid scenario. I'll discuss that in a second, what that means. So we did that, I'll talk now about the results in open SSL and open SSH for TLS and SSH. So a hybrid scenario essentially mixes both a classical algorithm with a post-quantum one. The trust we get with crypto algorithms comes with time. The reason we believe this in the security of RSA is because it's been a long, long time. It's been around since 1976. A lot of people tried to break it and what it was able to, not until a quantum computer comes around. These new post-quantum proposals, some of them are very new. So even if we don't know how to break it with a quantum computer today, it doesn't mean that we won't be able to do it in 10 years. In fact, we could break it with a normal, a classical computer, we don't even know. So one strategy is to try to get the best of both worlds to combine the security of our classical scheme, let's say RSA or ECDHE, and combine it with a post-quantum one. And the resulting key that we use on the wire is secure. If any one of them is secure. These protocols, when you do a TLS connection, you don't use your ECDHE or RSA key directly to enter the message. You use it to derive a secure and quick, fast, symmetric encryption key, like an AES key that you use to do your encryption of each packet. So we would do the same in the hybrid fashion and have a both classical and a post-quantum input to the key derivation function to result in the AES key that would be based on the security of both schemes. So fortunately we're able in TLS and SSH to negotiate algorithms, but we don't have the ability to negotiate two different algorithms and use them in conjunction. So the paper explores different ways to do that. One way is to just invent a new scheme instead of saying I'm gonna use ECDHE and I'm gonna use SITE together, SITE as a post-quantum algorithm. I'm gonna use a new algorithm called ECDHE SITE. And for the TLS layer, it's completely oblivious to the fact that under the cover in the crypto layer, we're separating these two things and doing both ECDHE and SITE computation in parallel and combining the results. So it's a great approach that it's easy to implement without changing the protocol or the implementation, but it doesn't give you a lot of flexibility for negotiating different variants. And alternatively, we could define new hybrid approaches that requires changes to the protocol through extensions. When you consider all these options, you have to think about the backward compatibility, performance, latency, you don't wanna introduce new data flows, new messages, you don't wanna break old hardware implementing TLS protocol, for example. So for our implementation, we use the naive approach, the first one, where we define new combo algorithms to allow us to do a quick implementation without changing anything in the protocol. So we were able to integrate in the key share TLS 1.3 extension and just gonna concentrate on TLS 1.3. We also add some code in TLS 1.2, but kinda forward-looking, let's talk about TLS 1.3. So the results were quite positive. Some crypto algorithms are a bit too big to fit in the TLS which has limits on the public key and signature sizes. And OpenSSL, that's implementation, also constrains things that further down. But by modifying the code, we're able to fit most of our integrations, our algorithms and I'll discuss that in a second. And we're able to use this OpenSSL, modified version of OpenSSL to stand up NGINX and Apache servers to test our modified clients as well. Get a link here, that's also everything's available from the open source, openquantumsafe.org project that I showed at the beginning just shows you that if you're, if you know how to use OpenSSL, then you can use it exactly the same way to stand up the test client and server with these new post-quantum hybrid algorithms, in this case, Frodo and ECDHE with the P256 NIST curve and using a ECDSA and QTESLA hybrid certificate there. And then you get the connection, everything works as expected. So we also add another part of the paper was to discuss SSH, SSH is kinda more the same, so I'll skip over it. It's another key exchange protocol with authentication and we're able to provide both hybrid, classical and post-quantum key exchange and authentication as well. And again, if you're aware of how to use SSH, you'll notice that we can use it in exactly the same way. You can take our fork and install it on a server and start connecting to it using hybrid post-quantum security. So the interesting thing about what we observe, as I said, is that most quantum algorithms were able to be integrated. Some of them with the yellow check mark just means that we had to modify some of the code in OpenSSL to allow bigger structures. That was just a implementation choice of the OpenSSL designers to limit that. And some scheme, for example, NTS, which is a code-based version, use a very large artifacts in there that we were not able to fit them. But for most of them, it was okay. For signatures, a lot of signatures use quite big artifacts as well, keys or signatures. And we had to update, modify the OpenSSL and OpenSSH code to make it work. And very few of the algorithms we tested were not able to fit. So picnic, for example, with picnic version one, the IR level, level three and five wouldn't fit. But in the second round, picnic two version, they did modify the algorithm and we were able to fit them in TLS. And only the rainbow signature algorithm, we were not able to fit it in the SSH code base. So very positive. Overall, these new schemes fit well into our target protocols, TLS and SSH. The other thing we wanted to consider was benchmarking. So how efficient these algorithms would be in real life. In the second paper, we designed two experiments. The first one, we use a network emulator as part of the Linux kernel to connect to virtual internet endpoint, a client using the OpenSSL S time connecting to a server that would instead share it with NGINX. And the nice thing about the network emulator is that you're able to change its behavior. So we added a different round time, different distance between these two endpoints and also changed the packet less probability from zero to 20% in multiple clicks. So I apologize, the screen is very small. The point is not to see the details of each result but just to show the trend. And what we observe is that for most algorithms on good networks, the performance was quite good. We compared the state of the art, ECDHC connection algorithm with a hybrid version of itself with three different post quantum algorithms. And most of them had very similar performance. And what we observe is that for a couple of years algorithms with larger keys, for example, then they would have to be split across multiple packets when there would be to be fragmented. And if the packet loss probability is higher than 5%, then there's a good chance that some data would need to be recent. And that would slow things down for these algorithms. So yeah, so overall good news and good simulation for the usage of hybrid exchanges compared to the pure ECDHC. The second result, we try to emulate something, not emulate the first one, the emulation, but the second one, we try to simulate real life conditions by having a client in virtual machine connected to four different virtual machines across the planet in different data centers and trying to retrieve various size web pages from one K to 10 to 100 to 100 K to one megabyte. And some surveys we looked at put the average websites to two to three megabytes. So having a one megabyte limit gave us a good approximation. And so not surprisingly, when we try to fetch these different pages across these different VMs, we notice that of course, the further away you're connecting to in the larger web page connection slows down. But what's interesting is that ECDHE with ECDSA certificate is it's performance is not that much better than the same thing in hybrid combination with a post quantum algorithm as things gets further away and with bigger web pages. So the more we look with real life conditions, the hamertized costs of adding this extra layer of post quantum security does not penalize you too much, which is good news for if you wanna try to deploy these technologies today and start experimenting with them. So you get a lot of protection, basically a safety net against quantum computers for the data that's exchanged today for a very adequate performance costs. So these are good news for experimenters and deployers. So the last project I'd like to discuss today is the VPN tunnel that we played with. So we have an integration into open VPN through our open SSL fork because open VPN bases security on TLS. And this is a nice scenario for both legacy applications and for clients that would be difficult to update like IoT devices that have a long lifespan. So it would be hard to magically transform all these devices and clients to make them quantum secure. So one way to do this is to leave them on touch and simply add a post quantum tunnel and tunnel their communication through it. So you get the quantum safety automatically without having to change what's going on in the wire. And we experimented with this approach in a real life scenario. So there's one of our sister team at Microsoft Research is working on Project Natic, which is an underwater data center module that floats, not floats, but is in the ocean on the North Sea of Scotland. And the reason to experiment with these is that it brings data closer to the customer and there's some inherent cooling benefits to be in the water like this. And we ran a post quantum VPN to it from our Redmond headquarters and just with normal or rekeying and everything. And we ran this for a long time, the details are in this URL here. And what's interesting is that this experiment kind of gives us confidence that we're ready to start experimenting with post quantum deployments with real life data. So this is a test data center, so it's not real customer data. So we're kind of, we're allowed to experiment with this without putting anybody in danger. And also, as you can see, the little seal on the water there, that picture was taken from a webcam outside the data center. It's not easy to send a technician down there to fix something. And the fact that we're able to do this experiment gives us confidence that the techniques we use could be replicated in normal data centers. So that brings us to the end of this presentation. And I hope that you got the message that quantum computers are coming and that's the safe standpoint to take as if you work in security and photography because the cost would be high if you're wrong and don't expect them. And there are things we can do today to protect the data that's on the wire, dissenced them. And we need to start thinking about transitioning to quantum safe. There's a few things that we can do today before we wait for new standards. And I hope that the various projects that I presented to you at the start. And we're always happy to hear some feedback, some contribution in these open source projects. Either a photographer, a practitioner, or an enthusiast like to integrate these things. Please feel free to communicate with me if you have some questions or other questions. Thank you very much. Okay. So let's go with the first question. Will Microsoft support the winner of round three in its mainstream products when most popular only or even some legacy but still supported always? I can speak on behalf of the Microsoft product teams which will have their own decision making in there but I just assume that Microsoft will follow the industry. In fact, we have my colleagues at MSR, we have four of these teams in the competition. So of course we have like our favorites and we're experimenting with these more than some others but the Microsoft servers and teams and Edge which is based now on Chrome would just work in collaboration with the industry to pick the winners. I know Google did some experiments with Cloudflare and then we'll see what emerged there. Yeah, it's tricky. Sorry, Microsoft vision, go ahead, go ahead. Do quantum computing break perfect forward secrecy as well? TFS? So yes, so I mentioned a lot of RSA and ECDHG. So RSA is not perfect secrecy, you break it once and you can break all the history of the communication that was done with that key. ECDHG uses a just ephemeral defilement, DC or electric curve defilement. You need to break every renegotiation with it but if you store it today, you can, if you have access to a quantum computer later you can break any of these rekeying. So yes, it breaks it. Okay, good. Bitcoin question, you say Charles algorithm is a threat to Bitcoin, doesn't it apply only to signature verification of new transactions but Merkle tree remains immutable? Well, so, I mean, wherever you use, I know that some Bitcoin uses the, was it DSA or ECDSA, I forget, I'm not a Bitcoin expert, but it's whatever that part that part will be broken. And I'm not sure what's the impact on the Merkle tree I say, but one thing I would say is that there's a different threat, there's a different threat model for key exchanges and encryption and signatures. So encryption, like the key exchange you get in TLS to define a secret that you'll use to encrypt the session, that you can record and decrypt later. For authentication, the attacks are more online. So you need to convince somebody that you have to forge a signature, you need the quantum computer now. You cannot back break an authentication app in 20 years ago or 10 years ago. So you would be able to forge it, but it's been signed with a timestamp. So what's at risk today that you need to migrate first is everything that uses encryption, asymmetric encryption and the signatures, we have a bit more time. So don't want to scare all the Bitcoin crowd. I put that on purpose, this will go just to freak out people, but the risk will come a bit later. Yeah, they still have time to cash out. Okay, how many qubits are needed to run algorithm to break RSA? IBM's claiming they can reach 53. Yeah, so it's gonna be a lot more. But right now we're a bigger situation where before the invention of the transistor, computers, they were big light bulbs and they would break and everything. So it was inconceivable that you could build larger algorithms with this technology until somebody invented the transistor and then everything got smaller, faster and you were able to scale up quite fast. So we're waiting for a break through like this in quantum computing. And my colleagues at Microsoft were working on this specifically not using the type of physical systems that implement the qubit that, for example, IBM has been using, my colleagues are working on something called the topological computer that would be more stable and scale better according to their research. So if they're able to build this, that's kind of all taken into consideration in the various estimates that are floating around. It's really hard to predict. It's just we're expecting a breakthrough to happen within a decade that will allow us to build these things. So yeah, so these, you would need millions of qubit to build the current algorithms and it's doubtful that the current technologies used today would be able to by themselves be able to scale up to that level. Okay, we'll do one last question. Okay, have you looked at wire guards capabilities for post quantum encryption? It might be more relevant than open VPN in the future. Yes, so I have not personally. I know that some people did. I saw a recent paper, I forget by whom that I think they were experimenting and implementing post quantum into a wire guard. The reason we did open VPN because it was almost free because they use open SSL. So we just plugged in our fork in there and with little modification, we were able to do that. So some people has been looking at that and we ended up in OQS if they contributed at some point but I think if you just search for that, you might get, if you're interested in the details, you can look it up, wire guard post quantum. Or if you wanna post the paper too in the Twitch chat, that'd be great as well, if you can find it. Yeah, we'll have to do the same and search for it. I don't know. It might be unpublished results, I think which is because that was some colleagues, yeah. Okay, okay. Oh, thank you very much, Christian. We're out of time. We'll give you a big round of virtual applause. It was really great to have you again at Nordsec. Before moving out of the Twitch stream because my colleague Flo is going to take the next moderator spot, I would like that we give a big round of applause to our AV guys. I'm just gonna post their Twitch handle in the Twitch stream just because everybody said that what they're doing is awesome. They've been working for like a week on this. I know they're gonna probably thank them again later, but I don't know, it's just nice to recognize their work right now and later as well. And well, see you in 10 minutes for another talk.