Crypto and Privacy Village - Migrating to quantum-safe crypto to protect against the quantum hacker
Paquin, Christian
A non-trivial quantum computer would break the public key cryptography in use today. They might be at least a decade away, but nothing prevents adversaries to record and store selected internet traffic today for later quantum-assisted decryption. It is therefore prudent to start the migration to quantum-safe cryptography. NIST is well underway in its post-quantum standardization process. Adoption of these quantum-safe alternatives will however depend on the progress in integrating them into internet standards and systems. We describe how TLS and SSH can be adapted to use post-quantum cryptography. We examine various design considerations and report on our experiences in adding post-quantum and hybrid key exchange and authentication to these protocols. We describe the Open Quantum Safe project, which enables developers and researchers to experiment with post-quantum cryptography in various languages, applications, and protocols, including via our forks of OpenSSL and OpenSSH. Finally, we report on the performance of this new cryptography, and demonstrate conventional and post-quantum hybrid TLS 1.3 and SSH connections.
 All right everybody thanks for being here we're going to kick off next talk with speaker Christian Pacwin and he'll be covering migrating the quantum safe crypto to protect against the quantum hacker. All right thank you very much. Thank you I'm very happy to be back this year to discuss our progress towards migrating to post quantum cryptography. The work I'm presenting today is in collaboration with a lot of people some in my team at Microsoft Research also with some other organizations but for this particular work it's mainly been done with Douglas Stabilla at University of Waterloo. So I don't know if you remember or some of you might not have been born 20 years ago when South Park introduced these very weird characters the little gnomes and they went around and they had a plan to make money a kind of interesting business plan they would go around steal people's underpants and then with some unknown way they would try to make a profit. I'll get back to these guys later but on a unrelated note also something that happened 20 years ago is that I started to study quantum computing in my graduate studies at the University of Montreal was fascinating subject and kind of abandoned it came back to it a few years ago this time not trying to use quantum computing but trying to defend against it because I'm sure we've you all know that was that not on before okay so I'm sure you all know that quantum computers although they would be fantastic for the field of algorithmics you can solve a lot of problems more efficiently for the world of cryptography it's really bad news because a quantum computer would break due to Shor's algorithm it would break RSA and DSA elliptic and eCDH and all the elliptic or variants essentially because it can solve the underlying mathematical problems on which these schemes are based namely they can factor and find a discrete log of numbers very efficiently in polynomial time what does that mean it means that a quantum computer would break all the public eCrypto we use today and by what I mean is that it would break HTTPS TLS it would break SSH it would break peer-to-peer communication messaging systems like Signal break certificates software update channels and bitcoins if you somebody has a computer it could steal all the bitcoins and there's another algorithm that's important in quantum computing it's called the Groover's algorithm it affects hash functions and symmetric primitives like AES but that's not a big problem we can just double the key sizes the hash sizes and we're fine so Shor is really the main problem here and there there's a wide spectrum of of estimates of when a quantum computer is built some people say it will never be built some people say it's going to be done in five years but there's a wide consensus in in in academia and experts that say a specialized quantum computer could be built within a decade or two to break RSA so that means that we need to start thinking about migrating to quantum safe cryptography so quantum safe cryptography or post-quantum crypto is not cryptography that runs on a quantum computer it's a it's a type of algorithm schemes algorithmic schemes cryptographic schemes that run on normal computers but for which we know no way to break them with quantum computers so I get asked often like why do we care now why don't you just tell me a year before the quantum computer is going to be built and then we're going to scramble and rush to to fix everything like we did for y2k a year before and that's a valid argument the problem is that the data we encrypt today uh on the web is at risk it is at risk of being captured now stored for a couple of years and then decrypted so if you're sending important data trade secrets or if you're a whistleblower and sending confidential information then if this data can be decrypted in 10 years and ruin your life then you need to start protecting it differently today another problem is that once we're ready to transition it's going to take a long time to change the standards tls ssh all these things will take years to update and consequently also will take some time to update the software stack all the code there's this notion of crypto agility to to program your your software to be able to replace algorithms we've done that many times replacing md5 with char one char one with char 256 so we're used to that but there you'll be surprised how many places rsa is just art coded in some code bases so it might be hard to transition some software stacks and also these new algorithms they don't necessarily uh function like the old ones some of them have huge keys they run slower so we might have a critical impact on some software bottom line if you have data that needs to be secured in 10 years take all these steps backwards we kind of need to do that today we're back to these guys now so now they have a new idea how to make money they don't need to collect underpants anymore they can simply collect cipher things wait a few years and then they can turn out a profit when they have access to a quantum computer fortunately on the crypto side uh we're on top of things so nis the national institutes of standard and technologies they started this uh this effort to uh provide new standards to replace rsa and the and e cdh and all these these things they started in 2017 they got they they asked the community to uh to provide to propose new schemes there were 69 uh accepted schemes that were submitted uh and uh in January of this year they started round two so Thanos happened and a bunch of these just got uh snapped away and then some more got merged together because they were very similar and now we're left in uh right here with 26 schemes and uh we're two weeks away from a workshop organized by nis where the submitters will discuss these run to candidates what updates they did in the second round and if all goes well then within three to five years nis is going to publish some new standards so it's coming up fairly fairly soon so our goal is to experiment with these new schemes and see what's the impact on our the software we use today so it was this project was started by the university of Waterloo and we we joined among with other mini collaborators uh to create a framework in which you can integrate your new crypto schemes and in turn we can take these and integrate them in higher level software so the open quantum safe project is an open source project it's available at this uh URL our goal is to integrate all the round two schemes where we're on the way of doing that and um we also have integrations into open SSL open SSH and also open VPN which allow you to try and deploy these things uh experimenting with post quantum cryptography what's new uh what we did in the the this year is we kind of completed the roadmap of all the use cases so we can do full post quantum and also the hybrid case classical post quantum and both the key exchange and the authentication the signature part for both the TLS 1.3 and SSH we also have 1.2 support I'll talk about it in a second but it's not as complete and we also implemented wrappers uh so you can use the library from C++ C sharp or python so using uh this uh framework we we did some case studies and analysis of um different ways you can plug in these algorithms uh in our target protocols SSH and TLS so we just released a paper describing this um it's going to be presented at the NIST workshop in more details um and we've also have an extra collaborator on the on the paper Eric Crockett from Amazon who provides also some insight from their S2N SSL integration and I will present a few results from uh from this analysis um to give you an idea of of what is entailed when you try to migrate to post quantum cryptography so first I mentioned this before but we we support what we call hybrid uh deployments so hybrid means that uh so if you take a post quantum algorithm you don't want to transition to it right away you don't want to dump RSA and start using a like picnic signature because these are fairly recent RSA as uh as uh has been there since 76 there's been a lot of crypt analysis done on it so we don't know these post quantum algorithms may be broken in five years not even by a quantum computer but maybe by a classical computer maybe there's a flaw in the algorithm that we haven't seen so um how to achieve um more safety is to combine a classical algorithm with a post quantum one so you take let's say uh pcdh and you combine it with a with a psych algorithm and then you create a new one and uh the resulting communication will be secure if any of the two is secure so if there are no quantum computers then you're safe you have your elliptic curve uh defi element and if there is a quantum computer then your communication will still be secure because uh you would have protected with a post quantum one so tls ssh they already have this this notion of negotiating algorithms the client sends the support list and the server responds and negotiate which algorithm they'll pick but we don't have a way to pick two algorithms at the same time and combine them so that's where we have to work and there there are multiple ways to do that that we we can delist in the paper uh the simplest one is just to create a new scheme it's like you know png uh sandwich you know peanut butter and jelly and just combine it's the new thing it's png so the same thing we can take a classical algorithm a post quantum one combine them and that's a new thing the great thing is that this is backward compatible so when you say I support these these algorithms you just name the new one which is a combination of both and if the other peer supports it you can have this secure uh this this exchange that provides extra security and there are a bunch of more advanced ways to negotiate the two algorithms separately and um they're a bit more complicated they require protocol changes and and might affect uh a few items and the things that you need to keep to take to care about when you design these is okay I was going to affect backward compatibility performance because for example in tls 1.3 when the client sends uh its first message to request communication it has the ability to pre-compute some data so assuming you're going to pick ecdh here's a pre-caputation for this exchange but if I'm going to send three proposals and I have to compute pre-calculations for each I'm consuming data the data is bigger so we don't want to introduce too much uh much more uh problems or more data increase the bandwidth requirements uh and we don't want to add communication messages and uh and affect the data flow too much so these are all things that we take in considerations the first thing we've implemented and the one that we that we use for our experiments is is the first one I mentioned the combo scheme because it is the simplest to implement minimal changes in open SSL and open SSH and also uh doesn't affect backward compatibility so it's easier all around the world um so for the tls uh use cases that we consider we have some work in tls 1.2 the more recent work in tls 1.3 uh the base protocol does not support it only supports let the curve type extensions ecdh um our say is not even there anymore so we have to masquerade our our algorithms as curves so we pretend to be an elliptic curve uh curve and then uh we can run so we don't have to modify the stack and um one problem is the size of these things as I mentioned some scheme have very large public keys or very large encryption systems or signatures and the the protocol specifies a maximum size in this case two six two to the sixteen bytes for uh for public key and two to the twenty four for certificates for example and some scheme uh are bigger than that so they wouldn't fit but also open SSL as smaller limits because rsa is not that big as some main thing that's used so they don't want to provide this empty buffer where people could dust them so they reduce this limit so at some places we had to tweak uh remove uh some of these limits and open SSL to be able to run our experiments open SSH is a kind of similar but uh it has a bigger limit it's two to the thirty two so all the all the proposed round two schemes would fit there um in theory open SSH also has its internal limits that we had to tweak to to fit our algorithms at some places and um in this case we support both the client and server public authentication so it's kind of a full coverage of the of what we want to to achieve here uh just as a summary of uh what we tried is a table that shows for the key encapsulation so the key exchange um so as I mentioned at the beginning the OQS slide there were some algorithms that are in there some are not and there's no particular reason to why schemes are excluded other than the fact that people involved the project contribute their own schemes and the other ones were trying to to fill them uh by taking implementations that we can find uh by the submitters so at some point we hope to have all the NISC candidates in that table um the little yellow uh check mark here for example Frodo as uh as uh larger artifacts that we needed to tweak open SSL internal limits to be able to fit in there uh NTS sorry NTS which is a code based scheme here like a bit like McLeese also is a similar um is a similar scheme which at a very large uh public keys and we cannot uh we're not able to fit them in in the software that we had problem and the spec in theory would support that size but we were not able to make it work so uh it's a good reason to try these experiments in practice because even in theory they say the size should fit uh there's some resulting there's a lot of of uh code paths in the in the software that didn't work for the signatures uh we have a lot more of these yellow boxes meaning that needed to uh augment the internal size in open SSL and open SSH to fit these large signatures or public keys and um we only had two failures picnic level three and five were expected because the uh the signature size were bigger than what's allowed by the the protocol uh the round two version of picnic all fits so they reduced uh they did some optimization that uh allow picnic to be used in in TLS and on the SSH side we had some failures with the rainbow uh some more higher level parameter sets so now uh I'd like just to show you a quick demo of SSH um so if you know and use if you know SSH then that's gonna look it should look exactly as how you're used to see it so only thing we did is add these post quantum algorithms and um nothing is different if you've never seen a SSH connection that's just gonna look a little bit weird sorry for the the unreadability of that of these consoles but when I'm starting on the right hand side is a server it's expecting a uh uh e-cdhe with the niskrv p3-84 combined with a psych algorithm there it is and uh on the left hand side it's gonna be a client requesting the same algorithm and um I've put the debug output there so it's just so that it to show something on the screen otherwise it would just be nothing and uh we see the connection was uh successful the same year the authentication was done with the picnic uh hybrid uh the picnic signature and uh also a ecdsa so the point I'm trying to make here is that we modified these these these these software stacks but they work exactly as you did before uh they did before if you deployed SSH before uh one step that I skipped was the creation generation of the key pair and added it to the authorize set on the server side so it works exactly the same which means that you can basically go out and and try it and uh deploy it even so what's next for us is uh well we want to add more of the round two schemes the one we're missing so we can have a a full list of uh of all the algorithms and we want to do some performance testing we did some tests with the uh a year ago it was round one candidates and it was very promising the fast lattice schemes for example were competitive and sometimes even faster than state of the art ecdh and uh some slower one uh which might not be suitable for you know multiple connections a second like an ssl server could be great for kind of more one-on-one interactions in their in a messaging system or SSH so you really have a broad choice of deployment options uh if you're a system integrator and we also want to tackle more protocols there there's all sorts of things that needs to be uh made quantum safe we want to start looking uh into that and for you an interesting thing to consider is are you working with projects or with software that that protects data that needs to be secured for for a couple years for 10 years and if so you might want to be able to you might want to start using uh post quantum cryptography to protect this data either integrating in your code or using some of our forks and deploy them SSH or VPN all right so that's my time thank you for your attention I'll be posting the slides uh right after the talk and I'm happy to take some questions thank you all right thank you if you have questions please come up to the human microphone that is me come on down can you come up and thanks form an orderly line my question was just um obviously I haven't looked at the github repo yet but did you use the open ssl module api to build your um provider or did you hack open ssl to extend it yeah the engine api you're talking about yeah okay so no we didn't uh so the engine api is uh in open ssl there's a way to provide an alternate implementation uh so if you have rsn you implement rsn hardware you can create an engine to plug it in so since these were new algorithms unknown to open ssl we add to uh to modify open ssl itself and there's open ssl is in two layers the crypto layer and then the ssl layer the crypto layer you could maybe get away with using the engine but in the ssl layer where you define specs uh or specifications for the actual algorithms that didn't work so we modified the the code directly we have a fork you can see the diff between the original project and um I just have a question I don't know I mean obviously you're aware that IBM has actually created the q1 system correct because I was at CES in January and they that's where they showcased it and I don't know if you know anything about it but knowing what it is it's a legit how do you think that's going to help your field of migrating regular like what you were talking about how do you think that the creation of the IBM 1Q system will help maybe not you but like whenever they streamline it more uh how do you think the creation of the IBM q1 system is going to help you and the people that come after you in this particular so yeah so there's a lot of vendors that that have uh you know work on quantum computing and provide specialized chips a lot of what's out today the d-wave system and some others they're very specialized and they're not general computers to do all these things so the the estimates I gave at the beginning 10 15 years uh it's the output of of very serious uh quantum computer experts that took everything in consideration uh research time uh money invested then they give a like a 50% chance to to have something in 10 15 years including all this development that's all that's none of these is surprise work you see the scaling of quantum computer and we have to plan that pessimistically if you're trying to defend against it then our mark is like 10 15 years I mean I just wanted to get your opinion on how you think even though it might not be the q1 system itself that helps you like the later iterations of uh quantum computing do you think that will just streamline the migration from regular to uh PQC? Uh I mean it's it's uh it's like all this stuff the migration doesn't use quantum computers at all right we're just like if they they exist they threaten what's in today and you need to migrate to this stuff so what's going to trigger this is nis is going to do there they're going to have new standards and then the protocols will update and what we're trying to kind of kick start is you might want to migrate before all that takes place because that could be you know five seven years and all the data that you encrypt today until then is at risk to be decrypted later so if you want to migrate to something a hybrid scheme then that you have the tools to do that today expecting that one of these systems the wave IBM microsoft is working on them google everybody has a quantum computing team that somebody will have a functioning one in you know 10 15 years hi um does any of the algorithm being evaluated both any potential application and iot environment where bandwidth computation of power and latency are critical issues yes so so there's a lot of different flavors of algorithms uh some are very big very small very slow very fast and some of them that might not be competitive in in um in speed with some other like fast lattice one they will they will give them the adventures to themselves saying that oh we have very short keys we fit in very small embedded systems so this is the selling point to to some of these and nis said that they won't pick a winner they that they're more likely pick a bunch of them for different use cases including iot which is a very important uh scenario that's all the time we have for questions but hopefully he can be available afterwards outside yes uh all right one more round of applause for our speaker thank you very much
 All right everybody thanks for being here we're going to kick off next talk with speaker  Christian Pacwin and he'll be covering migrating the quantum safe crypto to protect against the  quantum hacker. All right thank you very much. Thank you I'm very happy to be back this year to  discuss our progress towards migrating to post quantum cryptography. The work I'm presenting  today is in collaboration with a lot of people some in my team at Microsoft Research also with  some other organizations but for this particular work it's mainly been done with Douglas  Stabilla at University of Waterloo. So I don't know if you remember or some of you might not  have been born 20 years ago when South Park introduced these very weird characters the little  gnomes and they went around and they had a plan to make money a kind of interesting business plan  they would go around steal people's underpants and then with some unknown way they would try to  make a profit. I'll get back to these guys later but on a unrelated note also something that happened  20 years ago is that I started to study quantum computing in my graduate studies at the University  of Montreal was fascinating subject and kind of abandoned it came back to it a few years ago  this time not trying to use quantum computing but trying to defend against it because I'm sure  we've you all know that was that not on before okay so I'm sure you all know that quantum computers  although they would be fantastic for the field of algorithmics you can solve a lot of problems  more efficiently for the world of cryptography it's really bad news because a quantum computer  would break due to Shor's algorithm it would break RSA and DSA elliptic and eCDH and all the  elliptic or variants essentially because it can solve the underlying mathematical problems on  which these schemes are based namely they can factor and find a discrete log of numbers  very efficiently in polynomial time what does that mean it means that a quantum computer would break  all the public eCrypto we use today and by what I mean is that it would break HTTPS TLS it would  break SSH it would break peer-to-peer communication messaging systems like Signal break certificates  software update channels and bitcoins if you somebody has a computer it could steal all the  bitcoins and there's another algorithm that's important in quantum computing it's called the  Groover's algorithm it affects hash functions and symmetric primitives like AES but that's not a big  problem we can just double the key sizes the hash sizes and we're fine so Shor is really the main  problem here and there there's a wide spectrum of of estimates of when a quantum computer is  built some people say it will never be built some people say it's going to be done in five years  but there's a wide consensus in in in academia and experts that say a specialized quantum computer  could be built within a decade or two to break RSA so that means that we need to start thinking  about migrating to quantum safe cryptography so quantum safe cryptography or post-quantum crypto  is not cryptography that runs on a quantum computer it's a it's a type of algorithm schemes  algorithmic schemes cryptographic schemes that run on normal computers but for which we know no  way to break them with quantum computers so I get asked often like why do we care now why don't  you just tell me a year before the quantum computer is going to be built and then we're going to  scramble and rush to to fix everything like we did for y2k a year before and that's a valid argument  the problem is that the data we encrypt today uh on the web is at risk it is at risk of being  captured now stored for a couple of years and then decrypted so if you're sending important data  trade secrets or if you're a whistleblower and sending confidential information then if this  data can be decrypted in 10 years and ruin your life then you need to start protecting it differently  today another problem is that once we're ready to transition it's going to take a long time to  change the standards tls ssh all these things will take years to update and consequently also  will take some time to update the software stack all the code there's this notion of crypto agility  to to program your your software to be able to replace algorithms we've done that many times  replacing md5 with char one char one with char 256 so we're used to that but there you'll be  surprised how many places rsa is just art coded in some code bases so it might be hard to transition  some software stacks and also these new algorithms they don't necessarily uh function like the old  ones some of them have huge keys they run slower so we might have a critical impact on some software  bottom line if you have data that needs to be secured in 10 years take all these steps backwards  we kind of need to do that today we're back to these guys now so now they have a new idea  how to make money they don't need to collect underpants anymore they can simply collect cipher  things wait a few years and then they can turn out a profit when they have access to a quantum  computer fortunately on the crypto side uh we're on top of things so nis the national institutes  of standard and technologies they started this uh this effort to uh provide new standards to  replace rsa and the and e cdh and all these these things they started in 2017 they got they they  asked the community to uh to provide to propose new schemes there were 69 uh accepted schemes  that were submitted uh and uh in January of this year they started round two so Thanos happened  and a bunch of these just got uh snapped away and then some more got merged together because  they were very similar and now we're left in uh right here with 26 schemes and uh we're two weeks  away from a workshop organized by nis where the submitters will discuss these run to candidates  what updates they did in the second round and if all goes well then within three to five years  nis is going to publish some new standards so it's coming up fairly fairly soon so our  goal is to experiment with these new schemes and see what's the impact on our the software we use  today so it was this project was started by the university of Waterloo and we we joined  among with other mini collaborators uh to create a framework in which you can integrate your new  crypto schemes and in turn we can take these and integrate them in higher level software  so the open quantum safe project is an open source project it's available at this uh URL  our goal is to integrate all the round two schemes where we're on the way of doing that and um  we also have integrations into open SSL open SSH and also open VPN which allow you to try and  deploy these things uh experimenting with post quantum cryptography what's new uh what we did in  the the this year is we kind of completed the roadmap of all the use cases so we can do full  post quantum and also the hybrid case classical post quantum and both the key exchange and the  authentication the signature part for both the TLS 1.3 and SSH we also have 1.2 support I'll talk  about it in a second but it's not as complete and we also implemented wrappers uh so you can use  the library from C++ C sharp or python so using uh this uh framework we we did some case studies  and analysis of um different ways you can plug in these algorithms uh in our target protocols  SSH and TLS so we just released a paper describing this um it's going to be presented at the  NIST workshop in more details um and we've also have an extra collaborator on the on the paper  Eric Crockett from Amazon who provides also some insight from their S2N SSL integration  and I will present a few results from uh from this analysis um to give you an idea of of  what is entailed when you try to migrate to post quantum cryptography so first I mentioned this  before but we we support what we call hybrid uh deployments so hybrid means that uh so if you  take a post quantum algorithm you don't want to transition to it right away you don't want to dump  RSA and start using a like picnic signature because these are fairly recent RSA as uh  as uh has been there since 76 there's been a lot of crypt analysis done on it so we don't know  these post quantum algorithms may be broken in five years not even by a quantum computer but  maybe by a classical computer maybe there's a flaw in the algorithm that we haven't seen so um  how to achieve um more safety is to combine a classical algorithm with a post quantum one  so you take let's say uh pcdh and you combine it with a with a psych algorithm and then you  create a new one and uh the resulting communication will be secure if any of the two is secure so  if there are no quantum computers then you're safe you have your elliptic curve uh defi element  and if there is a quantum computer then your communication will still be secure  because uh you would have protected with a post quantum one so tls ssh they already have this  this notion of negotiating algorithms the client sends the support list and the server responds  and negotiate which algorithm they'll pick but we don't have a way to pick two algorithms at the  same time and combine them so that's where we have to work and there there are multiple ways to do  that that we we can delist in the paper uh the simplest one is just to create a new scheme  it's like you know png uh sandwich you know peanut butter and jelly and just combine it's the new  thing it's png so the same thing we can take a classical algorithm a post quantum one combine  them and that's a new thing the great thing is that this is backward compatible so when you say  I support these these algorithms you just name the new one which is a combination of both and if  the other peer supports it you can have this secure uh this this exchange that provides extra  security and there are a bunch of more advanced ways to negotiate the two algorithms separately  and um they're a bit more complicated they require protocol changes and and might affect uh a few  items and the things that you need to keep to take to care about when you design these is okay I was  going to affect backward compatibility performance because for example in tls 1.3 when the client  sends uh its first message to request communication it has the ability to pre-compute some data so  assuming you're going to pick ecdh here's a pre-caputation for this exchange but if I'm  going to send three proposals and I have to compute pre-calculations for each I'm consuming data  the data is bigger so we don't want to introduce too much uh much more uh problems or more data  increase the bandwidth requirements uh and we don't want to add communication messages and uh  and affect the data flow too much so these are all things that we take in considerations  the first thing we've implemented and the one that we that we use for our experiments is is the  first one I mentioned the combo scheme because it is the simplest to implement minimal changes in  open SSL and open SSH and also uh doesn't affect backward compatibility so it's easier all around  the world um so for the tls uh use cases that we consider we have some work in tls 1.2 the more  recent work in tls 1.3 uh the base protocol does not support it only supports let the curve type  extensions ecdh um our say is not even there anymore so we have to masquerade our our algorithms as  curves so we pretend to be an elliptic curve uh curve and then uh we can run so we don't have to  modify the stack and um one problem is the size of these things as I mentioned some scheme have  very large public keys or very large encryption systems or signatures and the the protocol  specifies a maximum size in this case two six two to the sixteen bytes for uh for public key and two  to the twenty four for certificates for example and some scheme uh are bigger than that so they  wouldn't fit but also open SSL as smaller limits because rsa is not that big as some main thing  that's used so they don't want to provide this empty buffer where people could dust them so  they reduce this limit so at some places we had to tweak uh remove uh some of these limits and  open SSL to be able to run our experiments open SSH is a kind of similar but uh it has a bigger  limit it's two to the thirty two so all the all the proposed round two schemes would fit there  um in theory open SSH also has its internal limits that we had to tweak to to fit our  algorithms at some places and um in this case we support both the client and server public  authentication so it's kind of a full coverage of the of what we want to to achieve here uh just as  a summary of uh what we tried is a table that shows for the key encapsulation so the key exchange  um so as I mentioned at the beginning the OQS slide there were some algorithms that are in there  some are not and there's no particular reason to why schemes are excluded other than the fact that  people involved the project contribute their own schemes and the other ones were trying to  to fill them uh by taking implementations that we can find uh by the submitters so at some point  we hope to have all the NISC candidates in that table um the little yellow uh check mark here for  example Frodo as uh as uh larger artifacts that we needed to tweak open SSL internal limits to be  able to fit in there uh NTS sorry NTS which is a code based scheme here like a bit like McLeese  also is a similar um is a similar scheme which at a very large uh public keys and we cannot  uh we're not able to fit them in in the software that we had problem and the spec in theory would  support that size but we were not able to make it work so uh it's a good reason to try these experiments  in practice because even in theory they say the size should fit uh there's some resulting there's a  lot of of uh code paths in the in the software that didn't work for the signatures uh we have a  lot more of these yellow boxes meaning that needed to uh augment the internal size in open SSL and  open SSH to fit these large signatures or public keys and um we only had two failures picnic level  three and five were expected because the uh the signature size were bigger than what's allowed by  the the protocol uh the round two version of picnic all fits so they reduced uh they did some  optimization that uh allow picnic to be used in in TLS and on the SSH side we had some failures with  the rainbow uh some more higher level parameter sets so now uh I'd like just to show you a quick  demo of SSH um so if you know and use if you know SSH then that's gonna look it should look exactly  as how you're used to see it so only thing we did is add these post quantum algorithms and um  nothing is different if you've never seen a SSH connection that's just gonna look a little bit  weird sorry for the the unreadability of that of these consoles but when I'm starting on the right  hand side is a server it's expecting a uh uh e-cdhe with the niskrv p3-84 combined with a psych  algorithm there it is and uh on the left hand side it's gonna be a client requesting the same  algorithm and um I've put the debug output there so it's just so that it to show something on the  screen otherwise it would just be nothing and uh we see the connection was uh successful the  same year the authentication was done with the picnic uh hybrid uh the picnic signature and uh  also a ecdsa so the point I'm trying to make here is that we modified these these these these  software stacks but they work exactly as you did before uh they did before if you deployed  SSH before uh one step that I skipped was the creation generation of the key pair and added it  to the authorize set on the server side so it works exactly the same which means that you can  basically go out and and try it and uh deploy it even so what's next for us is uh well we want to  add more of the round two schemes the one we're missing so we can have a a full list of uh of  all the algorithms and we want to do some performance testing we did some tests with the  uh a year ago it was round one candidates and it was very promising the fast lattice schemes for  example were competitive and sometimes even faster than state of the art ecdh and uh some slower one  uh which might not be suitable for you know multiple connections a second like an ssl server  could be great for kind of more one-on-one interactions in their in a messaging system or SSH  so you really have a broad choice of deployment options uh if you're a system integrator  and we also want to tackle more protocols there there's all sorts of things that needs to be  uh made quantum safe we want to start looking uh into that and for you an interesting thing to  consider is are you working with projects or with software that that protects data that needs to  be secured for for a couple years for 10 years and if so you might want to be able to you might  want to start using uh post quantum cryptography to protect this data either integrating in your  code or using some of our forks and deploy them SSH or VPN all right so that's my time thank you  for your attention I'll be posting the slides uh right after the talk and I'm happy to take some  questions thank you all right thank you if you have questions please come up to the human microphone  that is me come on down can you come up and thanks form an orderly line  my question was just um obviously I haven't looked at the github repo yet but  did you use the open ssl module api to build your um provider or did you hack open ssl to  extend it yeah the engine api you're talking about yeah okay so no we didn't uh so the engine api is  uh in open ssl there's a way to provide an alternate implementation uh so if you have rsn you  implement rsn hardware you can create an engine to plug it in so since these were new algorithms  unknown to open ssl we add to uh to modify open ssl itself and there's open ssl is in two layers  the crypto layer and then the ssl layer the crypto layer you could maybe get away with using the  engine but in the ssl layer where you define specs uh or specifications for the actual algorithms  that didn't work so we modified the the code directly we have a fork you can see the diff  between the original project and um I just have a question I don't know I mean obviously you're  aware that IBM has actually created the q1 system correct because I was at CES in January and they  that's where they showcased it and I don't know if you know anything about it but knowing what it is  it's a legit how do you think that's going to help your field of migrating regular like what you  were talking about how do you think that the creation of the IBM 1Q system will help maybe not  you but like whenever they streamline it more uh how do you think the creation of the IBM q1  system is going to help you and the people that come after you in this particular so yeah so  there's a lot of vendors that that have uh you know work on quantum computing and provide  specialized chips a lot of what's out today the d-wave system and some others they're very  specialized and they're not general computers to do all these things so the the estimates I gave at  the beginning 10 15 years uh it's the output of of very serious uh quantum computer experts that  took everything in consideration uh research time uh money invested then they give a like a 50%  chance to to have something in 10 15 years including all this development that's all that's none of  these is surprise work you see the scaling of quantum computer and we have to plan that pessimistically  if you're trying to defend against it then our mark is like 10 15 years I mean I just wanted to  get your opinion on how you think even though it might not be the q1 system itself that helps you  like the later iterations of uh quantum computing do you think that will just streamline the migration  from regular to uh PQC? Uh I mean it's it's uh it's like all this stuff the migration doesn't  use quantum computers at all right we're just like if they they exist they threaten what's in  today and you need to migrate to this stuff so what's going to trigger this is nis is going to do  there they're going to have new standards and then the protocols will update and what we're  trying to kind of kick start is you might want to migrate before all that takes place because  that could be you know five seven years and all the data that you encrypt today until then is at  risk to be decrypted later so if you want to migrate to something a hybrid scheme then that you  have the tools to do that today expecting that one of these systems the wave IBM microsoft is  working on them google everybody has a quantum computing team that somebody will have a functioning  one in you know 10 15 years hi um does any of the algorithm being evaluated  both any potential application and iot environment where bandwidth computation of power and latency  are critical issues yes so so there's a lot of different flavors of algorithms uh some are very  big very small very slow very fast and some of them that might not be competitive in in um  in speed with some other like fast lattice one they will they will give them the adventures  to themselves saying that oh we have very short keys we fit in very small embedded systems  so this is the selling point to to some of these and nis said that they won't pick a winner they  that they're more likely pick a bunch of them for different use cases including iot which is a  very important uh scenario that's all the time we have for questions but hopefully he can be  available afterwards outside yes uh all right one more round of applause for our speaker thank you  very much
Christian_Paquin_-_Migrating_to_quantum_safe_crypt_IqCw19bKE6c_0_1247.png Christian_Paquin_-_Migrating_to_quantum_safe_crypt_IqCw19bKE6c_1248_2651.png Christian_Paquin_-_Migrating_to_quantum_safe_crypt_IqCw19bKE6c_2652_3335.png Christian_Paquin_-_Migrating_to_quantum_safe_crypt_IqCw19bKE6c_3336_3863.png Christian_Paquin_-_Migrating_to_quantum_safe_crypt_IqCw19bKE6c_3864_5027.png Christian_Paquin_-_Migrating_to_quantum_safe_crypt_IqCw19bKE6c_5028_6395.png Christian_Paquin_-_Migrating_to_quantum_safe_crypt_IqCw19bKE6c_6396_7007.png Christian_Paquin_-_Migrating_to_quantum_safe_crypt_IqCw19bKE6c_7008_7403.png Christian_Paquin_-_Migrating_to_quantum_safe_crypt_IqCw19bKE6c_7404_7535.png Christian_Paquin_-_Migrating_to_quantum_safe_crypt_IqCw19bKE6c_7536_7835.png Christian_Paquin_-_Migrating_to_quantum_safe_crypt_IqCw19bKE6c_7836_9071.png Christian_Paquin_-_Migrating_to_quantum_safe_crypt_IqCw19bKE6c_9072_9215.png Christian_Paquin_-_Migrating_to_quantum_safe_crypt_IqCw19bKE6c_9216_9455.png Christian_Paquin_-_Migrating_to_quantum_safe_crypt_IqCw19bKE6c_9456_10367.png Christian_Paquin_-_Migrating_to_quantum_safe_crypt_IqCw19bKE6c_10368_11243.png Christian_Paquin_-_Migrating_to_quantum_safe_crypt_IqCw19bKE6c_11244_13271.png Christian_Paquin_-_Migrating_to_quantum_safe_crypt_IqCw19bKE6c_13272_14315.png Christian_Paquin_-_Migrating_to_quantum_safe_crypt_IqCw19bKE6c_14316_16355.png Christian_Paquin_-_Migrating_to_quantum_safe_crypt_IqCw19bKE6c_16356_19283.png Christian_Paquin_-_Migrating_to_quantum_safe_crypt_IqCw19bKE6c_19284_19763.png Christian_Paquin_-_Migrating_to_quantum_safe_crypt_IqCw19bKE6c_19764_21779.png Christian_Paquin_-_Migrating_to_quantum_safe_crypt_IqCw19bKE6c_21780_22619.png Christian_Paquin_-_Migrating_to_quantum_safe_crypt_IqCw19bKE6c_22620_23483.png Christian_Paquin_-_Migrating_to_quantum_safe_crypt_IqCw19bKE6c_23484_24575.png Christian_Paquin_-_Migrating_to_quantum_safe_crypt_IqCw19bKE6c_24576_25703.png Christian_Paquin_-_Migrating_to_quantum_safe_crypt_IqCw19bKE6c_25704_25931.png Christian_Paquin_-_Migrating_to_quantum_safe_crypt_IqCw19bKE6c_25932_25979.png Christian_Paquin_-_Migrating_to_quantum_safe_crypt_IqCw19bKE6c_25980_27179.png Christian_Paquin_-_Migrating_to_quantum_safe_crypt_IqCw19bKE6c_27180_27287.png Christian_Paquin_-_Migrating_to_quantum_safe_crypt_IqCw19bKE6c_27288_27335.png Christian_Paquin_-_Migrating_to_quantum_safe_crypt_IqCw19bKE6c_27336_27455.png Christian_Paquin_-_Migrating_to_quantum_safe_crypt_IqCw19bKE6c_27456_27503.png Christian_Paquin_-_Migrating_to_quantum_safe_crypt_IqCw19bKE6c_27504_27791.png Christian_Paquin_-_Migrating_to_quantum_safe_crypt_IqCw19bKE6c_27792_28379.png Christian_Paquin_-_Migrating_to_quantum_safe_crypt_IqCw19bKE6c_28380_29459.png Christian_Paquin_-_Migrating_to_quantum_safe_crypt_IqCw19bKE6c_29460_33863.png Christian_Paquin_-_Migrating_to_quantum_safe_crypt_IqCw19bKE6c_33864_37115.png Christian_Paquin_-_Migrating_to_quantum_safe_crypt_IqCw19bKE6c_37116_37583.png Christian_Paquin_-_Migrating_to_quantum_safe_crypt_IqCw19bKE6c_37584_38335.png
All right everybody thanks for being here we're going to kick off next talk with speaker Christian Pacwin and he'll be covering migrating the quantum safe crypto to protect against the quantum hacker. All right thank you very much. Thank you I'm very happy to be back this year to discuss our progress towards migrating to post quantum cryptography. The work I'm presenting today is in collaboration with a lot of people some in my team at Microsoft Research also with some other organizations but for this particular work it's mainly been done with Douglas Stabilla at University of Waterloo. So I don't know if you remember or some of you might not have been born 20 years ago when South Park introduced these very weird characters the little gnomes and they went around and they had a plan to make money a kind of interesting business plan they would go around steal people's underpants and then with some unknown way they would try to make a profit. I'll get back to these guys later but on a unrelated note also something that happened 20 years ago is that I started to study quantum computing in my graduate studies at the University of Montreal was fascinating subject and kind of abandoned it came back to it a few years ago this time not trying to use quantum computing but trying to defend against it because I'm sure we've you all know that was that not on before okay so I'm sure you all know that quantum computers although they would be fantastic for the field of algorithmics you can solve a lot of problems more efficiently for the world of cryptography it's really bad news because a quantum computer would break due to Shor's algorithm it would break RSA and DSA elliptic and eCDH and all the elliptic or variants essentially because it can solve the underlying mathematical problems on which these schemes are based namely they can factor and find a discrete log of numbers very efficiently in polynomial time what does that mean it means that a quantum computer would break all the public eCrypto we use today and by what I mean is that it would break HTTPS TLS it would break SSH it would break peer-to-peer communication messaging systems like Signal break certificates software update channels and bitcoins if you somebody has a computer it could steal all the bitcoins and there's another algorithm that's important in quantum computing it's called the Groover's algorithm it affects hash functions and symmetric primitives like AES but that's not a big problem we can just double the key sizes the hash sizes and we're fine so Shor is really the main problem here and there there's a wide spectrum of of estimates of when a quantum computer is built some people say it will never be built some people say it's going to be done in five years but there's a wide consensus in in in academia and experts that say a specialized quantum computer could be built within a decade or two to break RSA so that means that we need to start thinking about migrating to quantum safe cryptography so quantum safe cryptography or post-quantum crypto is not cryptography that runs on a quantum computer it's a it's a type of algorithm schemes algorithmic schemes cryptographic schemes that run on normal computers but for which we know no way to break them with quantum computers so I get asked often like why do we care now why don't you just tell me a year before the quantum computer is going to be built and then we're going to scramble and rush to to fix everything like we did for y2k a year before and that's a valid argument the problem is that the data we encrypt today uh on the web is at risk it is at risk of being captured now stored for a couple of years and then decrypted so if you're sending important data trade secrets or if you're a whistleblower and sending confidential information then if this data can be decrypted in 10 years and ruin your life then you need to start protecting it differently today another problem is that once we're ready to transition it's going to take a long time to change the standards tls ssh all these things will take years to update and consequently also will take some time to update the software stack all the code there's this notion of crypto agility to to program your your software to be able to replace algorithms we've done that many times replacing md5 with char one char one with char 256 so we're used to that but there you'll be surprised how many places rsa is just art coded in some code bases so it might be hard to transition some software stacks and also these new algorithms they don't necessarily uh function like the old ones some of them have huge keys they run slower so we might have a critical impact on some software bottom line if you have data that needs to be secured in 10 years take all these steps backwards we kind of need to do that today we're back to these guys now so now they have a new idea how to make money they don't need to collect underpants anymore they can simply collect cipher things wait a few years and then they can turn out a profit when they have access to a quantum computer fortunately on the crypto side uh we're on top of things so nis the national institutes of standard and technologies they started this uh this effort to uh provide new standards to replace rsa and the and e cdh and all these these things they started in 2017 they got they they asked the community to uh to provide to propose new schemes there were 69 uh accepted schemes that were submitted uh and uh in January of this year they started round two so Thanos happened and a bunch of these just got uh snapped away and then some more got merged together because they were very similar and now we're left in uh right here with 26 schemes and uh we're two weeks away from a workshop organized by nis where the submitters will discuss these run to candidates what updates they did in the second round and if all goes well then within three to five years nis is going to publish some new standards so it's coming up fairly fairly soon so our goal is to experiment with these new schemes and see what's the impact on our the software we use today so it was this project was started by the university of Waterloo and we we joined among with other mini collaborators uh to create a framework in which you can integrate your new crypto schemes and in turn we can take these and integrate them in higher level software so the open quantum safe project is an open source project it's available at this uh URL our goal is to integrate all the round two schemes where we're on the way of doing that and um we also have integrations into open SSL open SSH and also open VPN which allow you to try and deploy these things uh experimenting with post quantum cryptography what's new uh what we did in the the this year is we kind of completed the roadmap of all the use cases so we can do full post quantum and also the hybrid case classical post quantum and both the key exchange and the authentication the signature part for both the TLS 1.3 and SSH we also have 1.2 support I'll talk about it in a second but it's not as complete and we also implemented wrappers uh so you can use the library from C++ C sharp or python so using uh this uh framework we we did some case studies and analysis of um different ways you can plug in these algorithms uh in our target protocols SSH and TLS so we just released a paper describing this um it's going to be presented at the NIST workshop in more details um and we've also have an extra collaborator on the on the paper Eric Crockett from Amazon who provides also some insight from their S2N SSL integration and I will present a few results from uh from this analysis um to give you an idea of of what is entailed when you try to migrate to post quantum cryptography so first I mentioned this before but we we support what we call hybrid uh deployments so hybrid means that uh so if you take a post quantum algorithm you don't want to transition to it right away you don't want to dump RSA and start using a like picnic signature because these are fairly recent RSA as uh as uh has been there since 76 there's been a lot of crypt analysis done on it so we don't know these post quantum algorithms may be broken in five years not even by a quantum computer but maybe by a classical computer maybe there's a flaw in the algorithm that we haven't seen so um how to achieve um more safety is to combine a classical algorithm with a post quantum one so you take let's say uh pcdh and you combine it with a with a psych algorithm and then you create a new one and uh the resulting communication will be secure if any of the two is secure so if there are no quantum computers then you're safe you have your elliptic curve uh defi element and if there is a quantum computer then your communication will still be secure because uh you would have protected with a post quantum one so tls ssh they already have this this notion of negotiating algorithms the client sends the support list and the server responds and negotiate which algorithm they'll pick but we don't have a way to pick two algorithms at the same time and combine them so that's where we have to work and there there are multiple ways to do that that we we can delist in the paper uh the simplest one is just to create a new scheme it's like you know png uh sandwich you know peanut butter and jelly and just combine it's the new thing it's png so the same thing we can take a classical algorithm a post quantum one combine them and that's a new thing the great thing is that this is backward compatible so when you say I support these these algorithms you just name the new one which is a combination of both and if the other peer supports it you can have this secure uh this this exchange that provides extra security and there are a bunch of more advanced ways to negotiate the two algorithms separately and um they're a bit more complicated they require protocol changes and and might affect uh a few items and the things that you need to keep to take to care about when you design these is okay I was going to affect backward compatibility performance because for example in tls 1.3 when the client sends uh its first message to request communication it has the ability to pre-compute some data so assuming you're going to pick ecdh here's a pre-caputation for this exchange but if I'm going to send three proposals and I have to compute pre-calculations for each I'm consuming data the data is bigger so we don't want to introduce too much uh much more uh problems or more data increase the bandwidth requirements uh and we don't want to add communication messages and uh and affect the data flow too much so these are all things that we take in considerations the first thing we've implemented and the one that we that we use for our experiments is is the first one I mentioned the combo scheme because it is the simplest to implement minimal changes in open SSL and open SSH and also uh doesn't affect backward compatibility so it's easier all around the world um so for the tls uh use cases that we consider we have some work in tls 1.2 the more recent work in tls 1.3 uh the base protocol does not support it only supports let the curve type extensions ecdh um our say is not even there anymore so we have to masquerade our our algorithms as curves so we pretend to be an elliptic curve uh curve and then uh we can run so we don't have to modify the stack and um one problem is the size of these things as I mentioned some scheme have very large public keys or very large encryption systems or signatures and the the protocol specifies a maximum size in this case two six two to the sixteen bytes for uh for public key and two to the twenty four for certificates for example and some scheme uh are bigger than that so they wouldn't fit but also open SSL as smaller limits because rsa is not that big as some main thing that's used so they don't want to provide this empty buffer where people could dust them so they reduce this limit so at some places we had to tweak uh remove uh some of these limits and open SSL to be able to run our experiments open SSH is a kind of similar but uh it has a bigger limit it's two to the thirty two so all the all the proposed round two schemes would fit there um in theory open SSH also has its internal limits that we had to tweak to to fit our algorithms at some places and um in this case we support both the client and server public authentication so it's kind of a full coverage of the of what we want to to achieve here uh just as a summary of uh what we tried is a table that shows for the key encapsulation so the key exchange um so as I mentioned at the beginning the OQS slide there were some algorithms that are in there some are not and there's no particular reason to why schemes are excluded other than the fact that people involved the project contribute their own schemes and the other ones were trying to to fill them uh by taking implementations that we can find uh by the submitters so at some point we hope to have all the NISC candidates in that table um the little yellow uh check mark here for example Frodo as uh as uh larger artifacts that we needed to tweak open SSL internal limits to be able to fit in there uh NTS sorry NTS which is a code based scheme here like a bit like McLeese also is a similar um is a similar scheme which at a very large uh public keys and we cannot uh we're not able to fit them in in the software that we had problem and the spec in theory would support that size but we were not able to make it work so uh it's a good reason to try these experiments in practice because even in theory they say the size should fit uh there's some resulting there's a lot of of uh code paths in the in the software that didn't work for the signatures uh we have a lot more of these yellow boxes meaning that needed to uh augment the internal size in open SSL and open SSH to fit these large signatures or public keys and um we only had two failures picnic level three and five were expected because the uh the signature size were bigger than what's allowed by the the protocol uh the round two version of picnic all fits so they reduced uh they did some optimization that uh allow picnic to be used in in TLS and on the SSH side we had some failures with the rainbow uh some more higher level parameter sets so now uh I'd like just to show you a quick demo of SSH um so if you know and use if you know SSH then that's gonna look it should look exactly as how you're used to see it so only thing we did is add these post quantum algorithms and um nothing is different if you've never seen a SSH connection that's just gonna look a little bit weird sorry for the the unreadability of that of these consoles but when I'm starting on the right hand side is a server it's expecting a uh uh e-cdhe with the niskrv p3-84 combined with a psych algorithm there it is and uh on the left hand side it's gonna be a client requesting the same algorithm and um I've put the debug output there so it's just so that it to show something on the screen otherwise it would just be nothing and uh we see the connection was uh successful the same year the authentication was done with the picnic uh hybrid uh the picnic signature and uh also a ecdsa so the point I'm trying to make here is that we modified these these these these software stacks but they work exactly as you did before uh they did before if you deployed SSH before uh one step that I skipped was the creation generation of the key pair and added it to the authorize set on the server side so it works exactly the same which means that you can basically go out and and try it and uh deploy it even so what's next for us is uh well we want to add more of the round two schemes the one we're missing so we can have a a full list of uh of all the algorithms and we want to do some performance testing we did some tests with the uh a year ago it was round one candidates and it was very promising the fast lattice schemes for example were competitive and sometimes even faster than state of the art ecdh and uh some slower one uh which might not be suitable for you know multiple connections a second like an ssl server could be great for kind of more one-on-one interactions in their in a messaging system or SSH so you really have a broad choice of deployment options uh if you're a system integrator and we also want to tackle more protocols there there's all sorts of things that needs to be uh made quantum safe we want to start looking uh into that and for you an interesting thing to consider is are you working with projects or with software that that protects data that needs to be secured for for a couple years for 10 years and if so you might want to be able to you might want to start using uh post quantum cryptography to protect this data either integrating in your code or using some of our forks and deploy them SSH or VPN all right so that's my time thank you for your attention I'll be posting the slides uh right after the talk and I'm happy to take some questions thank you all right thank you if you have questions please come up to the human microphone that is me come on down can you come up and thanks form an orderly line my question was just um obviously I haven't looked at the github repo yet but did you use the open ssl module api to build your um provider or did you hack open ssl to extend it yeah the engine api you're talking about yeah okay so no we didn't uh so the engine api is uh in open ssl there's a way to provide an alternate implementation uh so if you have rsn you implement rsn hardware you can create an engine to plug it in so since these were new algorithms unknown to open ssl we add to uh to modify open ssl itself and there's open ssl is in two layers the crypto layer and then the ssl layer the crypto layer you could maybe get away with using the engine but in the ssl layer where you define specs uh or specifications for the actual algorithms that didn't work so we modified the the code directly we have a fork you can see the diff between the original project and um I just have a question I don't know I mean obviously you're aware that IBM has actually created the q1 system correct because I was at CES in January and they that's where they showcased it and I don't know if you know anything about it but knowing what it is it's a legit how do you think that's going to help your field of migrating regular like what you were talking about how do you think that the creation of the IBM 1Q system will help maybe not you but like whenever they streamline it more uh how do you think the creation of the IBM q1 system is going to help you and the people that come after you in this particular so yeah so there's a lot of vendors that that have uh you know work on quantum computing and provide specialized chips a lot of what's out today the d-wave system and some others they're very specialized and they're not general computers to do all these things so the the estimates I gave at the beginning 10 15 years uh it's the output of of very serious uh quantum computer experts that took everything in consideration uh research time uh money invested then they give a like a 50% chance to to have something in 10 15 years including all this development that's all that's none of these is surprise work you see the scaling of quantum computer and we have to plan that pessimistically if you're trying to defend against it then our mark is like 10 15 years I mean I just wanted to get your opinion on how you think even though it might not be the q1 system itself that helps you like the later iterations of uh quantum computing do you think that will just streamline the migration from regular to uh PQC? Uh I mean it's it's uh it's like all this stuff the migration doesn't use quantum computers at all right we're just like if they they exist they threaten what's in today and you need to migrate to this stuff so what's going to trigger this is nis is going to do there they're going to have new standards and then the protocols will update and what we're trying to kind of kick start is you might want to migrate before all that takes place because that could be you know five seven years and all the data that you encrypt today until then is at risk to be decrypted later so if you want to migrate to something a hybrid scheme then that you have the tools to do that today expecting that one of these systems the wave IBM microsoft is working on them google everybody has a quantum computing team that somebody will have a functioning one in you know 10 15 years hi um does any of the algorithm being evaluated both any potential application and iot environment where bandwidth computation of power and latency are critical issues yes so so there's a lot of different flavors of algorithms uh some are very big very small very slow very fast and some of them that might not be competitive in in um in speed with some other like fast lattice one they will they will give them the adventures to themselves saying that oh we have very short keys we fit in very small embedded systems so this is the selling point to to some of these and nis said that they won't pick a winner they that they're more likely pick a bunch of them for different use cases including iot which is a very important uh scenario that's all the time we have for questions but hopefully he can be available afterwards outside yes uh all right one more round of applause for our speaker thank you very much
I'll get back to these guys later but on a quantum computer would break due to Shor's would break all the public eCrypto we use today post-quantum crypto is not cryptography that runs on a quantum computer it's a it's a type of soon so our goal is to experiment with these new create a framework in which you can integrate and both the key exchange and the authentication the signature part for both the TLS 1.3 and SSH these algorithms uh in our target protocols SSH this um it's going to be presented at the NIST in TLS and on the SSH side we had some failures the picnic uh hybrid uh the picnic signature and the algorithms and we want to do some performance want to start looking uh into that and for you an it's uh it's like all this stuff the migration do there they're going to have new standards and will give them the adventures to themselves