🎂 Defending against future threats: Cloudflare goes post-quantum
Presented by: Bas Westerbaan, Cefan Rubin, Wesley Evans, John Schanck
Originally aired on April 22, 2023 @ 8:30 AM - 9:00 AM EDT
Join Cloudflare Product Manager Wesley Evans, Systems Engineer Cefan Rubin, Research Engineer Bas Westerbaan, and Mozilla Cryptography Engineer John Schanck to learn more about post-quantum technology.
Read the blog post:
Visit the Birthday Week Hub for every announcement and CFTV episode — check back all week for more!
English
Birthday Week
Transcript (Beta)
Hi, everybody, and welcome to Cloudflare TV. I'm so glad you joined us today.
We have a really fascinating subject for you today.
Cloudflare is always working on the future of the Internet.
It's our mission to help build the best Internet possible with our collaborators and partners.
And today. I am so thrilled that we are joined by colleagues on the research team, Bas Westerban and Cefan Rubin and some of our external partners, namely John Schanck, who is a PhD in crypto analysis from the University of Waterloo, a member of the Mozilla cryptography team, and most famously, one of the lead authors on Kyber, which is the next generation post quantum algorithm chosen by Nest to help lead the way into a post quantum future.
So guys, I'm super excited to be talking with you today.
We've got a lot to cover and I want to jump right into it.
So let's do a quick round of intros first.
Bas, starting with you.
Yes, hello.
I'm a I'm a research engineer at the research team and I'm working to make Cloudflare and the Internet at large post quantum secure as fast as possible.
So I'm very much the support staff in some of those efforts.
I try my best to enable some of the wonderful thoughts and algorithmic efforts of the research team to find a wider audience and help package it up in ways that more of us can consume and get to that better Internet.
And a man who needs no introduction to the cryptography community.
John, why don't you introduce yourself, introduce yourself for our viewers?
Well, thanks.
Here to give me that great introduction. So I can't really top that, but I am a write about Mozilla Firefox right now working on our NSS library and the Firefox web browser and I'm a post-quantum cryptography enthusiast.
Amazing.
John, let's dive right into it. Recap for me the post quantum threat.
I've got a lot of questions from my friends and family that hear, Oh, we haven't reached a computer that can do quantum supremacy yet or there's only 100 bit computer out there.
Why should we care about post quantum today when most people say potentially we're not worrying about a computer that could beat Diffie Hellman until 2030 or 2040?
Yeah, so I think that's a great question and I just situate my response. I am on the quantum computing side.
I'm pretty skeptical about quantum computing.
I have been for a while.
A lot of my work is on estimating the resources it would take to actually run quantum algorithms.
And for a lot of the things that people want to do, it's expensive, it's too expensive.
But the core thing is that for cryptanalysis, for running Shor's algorithm, the one that breaks RSA and the discrete log problem that we rely on on the Internet, these are about the simplest quantum algorithms that you can write down.
As soon as you can multiply it two numbers together, you're off to the races.
These are these are a real threat. What we have right now is a situation where you have a very deep technological stack, a lot of moving parts, teams working in parallel on different parts, and it's hard to see the progress if you're not really enmeshed in it.
But we have vastly increasing capabilities year after year on the quantum computing side.
And at the same time, the cost estimates for running these algorithms is decreasing and at some point those two lines are going to intersect.
And for my perspective as a cryptography engineer, I just want to make sure that we're ready when that happens, whether it's in ten years or 15 years.
But also we have to be aware that people can collect information right now and save it.
And for some people they need confidentiality for ten, 15 years, 20 years, whatever it is.
And we need to start protecting those people today.
Yeah.
I mean, you couldn't have said it better than I said it. This idea that we need to protect data today.
To prevent this type of harvest now decrypted later attack, right?
Exactly.
Cloudflare. So it runs 20% of the Internet.
We're really talking with a lot of our customers and our end users about how Cloudflare can become their corporate network, How can how the Internet can become their corporate network with zero trust.
We're asking major corporations all the way down to people like my mother, who run a small mom and pop doctor's shop right to trust the Internet with some of the most sensitive and personal data they have.
We've got to make sure that the data that's transiting the Internet and by and large, our network is not just secure from the threats today, but also to care for the threats tomorrow.
Even talk to me a little bit more about what this type of threat analysis that we see from Cloudflare's perspective here.
Well, and precisely John's touched on it, but it's very much that notion.
Right.
We're not asking ourselves, wait, will my traffic or could my traffic be recorded?
That's not the question. We have to expect that it's quite possible and likely that a lot of sensitive traffic flows are indeed being recorded.
The key, though, is we don't want the this the world to arrive where we have lots of recorded sensitive information and the post quantum computers are present that can decrypt them.
And that's exactly what's possible now in theory.
This is all theoretical, thankfully, and we've already touched on that.
But what we're discussing today is really enabling the mom.
You talked about, Wesley and everyone else had benefits from Cloudflare network for when those communications are secured by Kiba, which is the algorithm that John is a coauthor on, that those transmissions recorded or not.
Will not be something that could be decrypted by that future post quantum computer.
And that's something where we're really securing the future in some ways.
And that's, again, something quite wonderful to be able to share with a wide audience.
So, boss, I want I want to talk a little bit about security in the future.
Right.
But in order to talk about securing the future, I want to talk about the past and how we got here.
Talk about Cloudflare's participation in the competition, the work we've been doing with our partners for the last couple of years.
I mean, really at the table for us, right?
I mean, how have we gotten to this point?
Yeah.
So it's been known for quite a while since 1994 that this that, that quantum computers are at risk, but sure, algorithms are ready, and I think it was in 2006 that the cryptography community took note in the first workshops on both quantum cryptography started and where the foundation was laid for the field of quantum cryptography.
At Cloudflare, we've been actively involved in around, I think, 2016 that we started looking at the different post quantum algorithms and seeing what will actually work practically, right?
What's actually practical.
And we've done some very important large scale experiments with quantum cryptography, for instance, one in 2019 with Google where we tested the bigger post quantum cases and recently one where we tested whether big signatures will work.
And we really feel that it's not just about making the cryptography secure, but also is it practical.
And we think that this will be a lot of work and we have to be prepared for this.
So we have been preparing. It's amazing.
And I love that you touch on the practical bit, right, Because this is what I love about Cloudflare research.
It takes work that takes sometimes a decade.
Right now, in this case for post quantum, we've been working on this for the better part of a decade now to encapsulate it, figure out the shape of the problem, figure out how to optimize it, work with all of our partners at Mozilla, Google others to run large scale experiments, work with our academic collaborators across the industry and academia spectrum to really turn to a point where Bas and I were having a conversation with Abe this morning, who's our product manager for Cloudflare Tunnels, where we were reminiscing on the fact that we went to Abe about three months ago and we're like, Hey, we think we should put post quantum in Tunnels to secure Cloudflare Tunnels for all of our origins that use Cloudflare D.
And we were able to do that in under a quarter because of the work that we've been doing right now.
And I asked a question during that segment that Boss was very demure on and refused to answer because this segment was coming up, which was talk to me about the heart of Kyber, right?
Like, what does Kyber do we hear about this encryption algorithm that's so fascinating for key exchange?
John, you were one of the co authors on this.
And so both boss has been demure to this conversation.
So I'm going to ask the question to you, what is kyber and why is it important?
How does it work?
Okay, So, so Kyber is a key encapsulation mechanism. So it allows two parties to agree on a secret without sharing any secret material to begin with.
So you have Alice and Bob. Alice generates a key sense to Bob.
He encapsulates the random key for actually doing the encryption back to Alice, and she's able to retrieve that key using secret information that she has.
As far as how does Kyber work, that's a that's a pretty, pretty difficult thing to go into in our time constraint here.
But I will say a lot of your listeners, probably in high school or college, looked at solving systems of linear equations and basically that's what you're what the hard problem in Kyber.
So the system's linear equations are easy.
You probably did it by hand in one of those classes, but it's difficult when the systems are presented just approximately when you don't have the exact system given to you.
I don't want to go too deep into into the weeds here, but that the problem, the underlying problem is what cryptographers call the learning with errors problem.
And this is what's replaced, factoring in a sense. So instead of factoring numbers, which we traditionally do with Diffie-Hellman or elliptic curve development, we're using a very different math problem.
This idea of a system of linear equations.
Mm hmm.
Mm hmm. That makes sense. So why is Kyber the one that missed, went within your opinion?
Well, I think what it really comes down to is, is that we had a really exceptionally strong team who had expertise in all of the relevant areas from theory side, doing the proofs of security down to the implementations.
And, you know, there was a lot of community consensus around doing something with lattice based systems, which is an example of or learning with aerospace systems.
And Kyber just proposed an attractive trade off between performance and security.
And also size, too.
I mean, I believe that.
So we're talking about when we talk about the actual key that's being accepted in the Handshake mean, we're moving from a very small bite sized world to a kilobyte now, right?
That's right.
Yeah. Yeah.
So it depends on the exact parameters you choose, but it's between 700 bytes and a bit more than a kilobyte.
And this is this is the biggest practical difference between a classical and a new quantum key exchanges.
And it's so one would think post quantum, that must be slow because it must be very secure and very secure.
Slow.
But that's not the case at all, actually. One of the exciting things is that Kyber is much faster, much faster than the classical example of Cloudflare Teams.
And this is very exciting because it allows us to be slow. Let me, let me explain.
So when you do cryptography, you want to make it very fast.
You use all kinds of tricks, and the more tricks you use, the faster you get it, but also the more likely it is to make an error.
And so with Kyber, what we've deployed, we didn't take the fastest implementation.
We took a relatively slow implementation.
But because Kyber is so fast.
It's still fast enough.
And this slow one implementation reasonably slow is very simple.
So it's we have a lot of confidence that there is not an implementation mistake there.
So that's.
It's funny it reminds me of this saying that the pilot community and the diving community have slow is smooth and smooth is fast.
Right.
In the sense that you've picked an algorithm that's exceptionally fast. You pick the slower version of it so that you can have a reasonably strong guarantee that it's not going to error out or cause issues.
And the fact that it doesn't cause issues enables you to be really fast.
And one thing that you mentioned earlier, Wesley, that the bus too, is sensible to to recognizes the experiments that we ran last year help give us more confidence, right?
Knowing that what size would be would be okay is something we already have have some experience of.
So it's step by step finding.
We're still this is still experimental times for all of us.
Right.
But it's really about putting those steps together and gaining confidence because we want this to be something that all can benefit from.
It's not shouldn't just be like a subject small group.
This is something for all of us, for the whole incident.
Yeah, I think that's such a good point.
And this is really where I want you to talk about what have we done here, right?
I mean, we keep saying, Oh, we've done post quantum crypto for everyone, jump post quantum crypto, everyone.
Let's talk about in specifics, right?
Because there are four parts of the connection we've talked about.
Tunnels is part of that.
That was one of our conversations today.
This conversation specifically what have we done here to help release post quantum crypto for the internet?
Yeah, so it takes two to tango here.
So if you want to make a post quantum connection, we and the browser, they both have to support this new cryptography.
And what we've done is we've enabled post quantum cryptography, a hybrid based on Kyber on all our servers, supported for all the domains that are served through Cloudflare.
So in APIs, right, Not just domains.
It's not just browsing.
It's also when you use APIs and basically almost everything now uses the same thing.
A browser is HTTP, almost everything does.
And we've added support for post quantum cryptography there, which is a fifth of the Internet.
So it's a significant, significant amount. And the and this is very important because the problem is that we need that some the Internet is a very big and heterogeneous place and so things can go wrong in unexpected ways.
And one of the things that's really nice about covers that's very fast, but it's also bigger.
It's roughly a kilobyte. It depends on which one you choose.
But the problem there is that some middle boxes, some ISPs, something in the middle might not like that and break right and this is what we've seen before.
So in 2019 we did a similar experiment with Google, where we try to end through a process which is also a bit more than a kilobytes.
And we saw that some connections, they just didn't work because there was a middle box that saw a big thing and it thought, I don't know what this is, I'm just breaking the connection we really want to make because the security, the private secure Internet is on the line.
So we really want to roll out quantum cryptography as fast as possible, but we cannot break the Internet.
So and not just I mean, we're not satisfied if it works for 99%, we want it to work for basically everyone.
So it's very important that we roll, that we've rolled it out and that people can test this and that We can see where things go wrong.
And I think I can segway now into I give to John because John is also very interested in this.
Yeah.
No, I really John, as one of the leaders here, what are some of the next experiments in the future of where we're headed with this that you see.
Yeah.
So I'm personally very excited about the experiment that you guys are running.
And in my capacity as a cryptography engineer at Mozilla, I do have some freedom to explore new technologies, run experiments and things like that.
And so I really want to get Firefox in or operating with, with your servers just to collect some data on things like increases in Handshake latency and whether we have any of these hard failures.
Maybe like saying mailboxes that just close the connection when they see Kyber now.
So right now we don't have that just yet, but we do have a great contributor, Gautam Mehta, who has been working independently.
He's from the Max Planck Institute for Security and Privacy.
He's got a build of Firefox where he has kyber integrated and it's working with your servers.
So I'm reviewing his patches and trying to get that into the browser.
Just, just in my and my, my personal time, really. Thank you for that.
Makes total sense. We appreciate those efforts and we talk to them and all of those sorts of efforts of people, you know, wider community contributing to these sorts of things.
It's, I think, helpful when you say it and you present it that way.
Helpful for me to hear have it reinforced that it really is contributions from many different places.
It's not just big companies deciding this. It's research companies, those who have an interest and working together.
You know, I'm really excited about this.
Yeah.
I mean, it's one of the things in terms of global connection that I think we don't stress enough in our day to day lives that the Internet, as Bob was saying, is this massive, heterogeneous place, but it's also a very heterogeneous community of collaborators.
So, John, who else has been involved in this?
Right.
I mean, we've heard a little bit about them, this competition. But talk to me a little bit about this idea of global collaboration here didn't just appear overnight.
The idea of peak didn't emerge overnight from one person.
What's the process been like and what have the collaborations been like?
Oh, well, I mean, Kyber itself is a very large collaboration.
I actually don't know the current numbers offhand.
It's at least 12 people I want to say industry, academia, many different countries represented.
And the process itself, I mean, we started with close to 70 submissions from all over the world, different research groups, different companies, and they've all worked together to try and achieve some level of consensus on what we should deploy.
So it's really been an amazing effort and experience. Yep.
Bas, I think about the fact that. We you talk about the city of an experiment and not wanting to break things.
Right. What do we see as some of the downsides? Obviously, Middlebury's errors can be a problem.
What are some of the other things that we might be expecting to be problems here?
Yeah.
So another one is so there are two variants of carbon 512 and 768 and one of them will fit into a single packet when we open a connection and the other one will just not typically will not.
That depends on the end.
It will probably not fit.
And so the two packets.
Right.
So is it a problem? Well there's a lot of so it's particularly for quick which is the protocol underlying HTTP three where this might be difficult.
So quick allows this quick allows two packets as the first packet they allow this.
They also have interop tests and the standard says this must be allowed. Right.
But standards are just standards. Unfortunately, what's actually done is quite different.
So one thing where this is difficult is if you have a load balancer.
So oftentimes you have companies which have a load balancer which is in front of all the traffic that comes in.
And these handle huge amounts of traffic.
And when and in case quick, they can make a decision on just a single packet.
Right.
Because basically all packets pick quick packets, they start with just one packet because it fits in one packet.
So they've been engineered to be very fast and just look at a single packet and they and we are afraid that, that there are many load balancers for instance, they just want that there might be a load balancer that which optimized and do not only look at the single packet and can't keep the state between the packets.
So this is an example where there's worry and I mean we can talk about it and we can hypothesize, but what we really need is that we actually see if this is a problem and try to work around them.
This is just one example.
All the examples are just so this is what we call protocol ossification.
It's like if you don't use a flexibility in a protocol, it gets ossified.
It's not like once.
So this is difficult and we will we will have to try to figure out does it occur and then how to work around this.
So there are several ways we might do this, but we will we will see and we will we will do this all at the IETF, you see.
So if anyone wants to follow along, feel free to.
To the acronyms or what's the IETF?
That's the it's an engineering task force.
So that's how it's an organization where people, people can join the open organization, where people collaborate from industry with also product contributors on the on the open, on the standards of the Internet.
So Taylor itself is an ICF standard, and a lot of other standards are made by the ICF.
Nice.
And John, similar question to you, right? Where do you see the edges of this?
Where are the next experiments that we need to start, start proving out what's going to break and what's not going to break so that we can help other clients really have a lot of trust and faith to deploy this in their own builds.
Mm hmm.
Yeah, I think it's it's difficult to say up front. And obviously, I mean we just don't run into any problems at all.
And it goes smoothly and everything's great.
What I think is important and one thing that I didn't mention is that the standards aren't written yet, so we still have some freedom to tweak things.
If we run into to issues where we have something like a change in Kyber itself or maybe a slightly different parameter sets which get us around an issue.
So I think it's really important that we're doing this now, even if it seems a little bit early, we're doing it before things are really set in stone and we have some more freedom to change things if we have to.
Let's talk about that time on a little bit too.
But actually, sorry about you're going to say something.
Yeah, I completely agree.
But I also want to add that it's not just kyber where there's still some flexibility with also in the protocols itself, you could try to find ways around, but it's just about finding the best trade off of that.
And one last point about this.
Again, the why, because that's what I often want to think about is this wider group, not just the us sorts, but users of this sort of thing, is that ossification that Bas was talking about and that is really the death of lots of the wriggle room that we need to make the Internet grow and be dynamic.
We work against that ossification as the wider community that uses the Internet.
So if you are someone who says to your ISP, there's something, you know, this is not working for me, Every time one has those sorts of conversations, you're helping form that dynamic incident that allows us exactly.
We're saying here we want to experiment with it now to find the issues and to make changes that are required.
But it's going to need to take some collaboration.
Hopefully some of those middle boxes and things that don't work will also make some modifications.
That's what's we need the wider community participation to enable them.
That makes total sense.
I mean, you have to have like there's a the Internet's a heterogeneous network, and the only way this works is if everyone agrees on the standards together.
And at the same time, we have to keep pushing forward on the next generation of technologies that may.
Cost complications for the current generation of tech.
And with that, let's talk timelines a little bit, because there's obviously what we announced today and part of Cloudflare research is prognosticating about where the future's going.
So, John, if you look into your crystal ball, right, where do you want the network to be in three years for post quantum?
I hope we have it deployed.
I mean, in three years we're looking at nice has written standards and hopefully we have IETF standards and all these other organizations have filled in the gaps.
Missed isn't going to do everything on their own. So three years gives us enough time to really hope that we have the standards written.
And maybe all this preparatory work that we're doing now makes it easy to actually have quantum cryptography be fairly pervasive on the Internet at that point.
Bas, same question to you and Cefan. Exactly.
I would love to. I would love that.
But this follows the sense that we are ready to turn it on. I mean, that's the ambition.
That's that's that's the goal.
So my contribution, again, returns to these sorts of things get moved ahead by the more people who talk about them.
Right.
So the more we're aware of. It's not just some awful dread future where I don't know what the thing is that we're afraid of the declension.
This narrative of the world is coming to an end because of some grand awful technology.
This is something that we've identified that could be a threat and we can work towards being secure in its face.
So it's really relevant to your question.
It comes down to how many more of these conversations we have, how many more experiments people engage in, how many more times browsers get bug fixes, reports in their stream where people are demanding something work that the browser says, well, you know, it's not maybe our current focus.
We define what those focuses are as users, right?
So we drive that forward.
So hopefully we have lots more discussion about that post quantum future.
So three is we should we should name it, right, John, Come on, come on.
Surely with this amount of effort.
Three years.
Yeah. No, we can hit it in three years. We've been working on it for the last 20.
It should be done.
I think that brings up the important point, though, and see if when you hit the nail on that, when you said end users, because we've been talking a really heavy technical jargon right now, don't get me wrong, I love my mother.
She's amazing as multiple terminal degrees.
But that's in medicine, right?
And when I start talking about peak and Kaiba, her eyes are like, not my wheelhouse, right?
How does an end user experience this right?
Are they going to have to do something crazy like go and put 15 switches or hopefully what's the end state for them?
Potentially they don't experience any changeover, right?
Like the internet just keeps working and it just magically gets more secure.
Right.
And exactly.
The magic is part of that dynamism that these protocols are meant to allow.
Right. So we've talked about some of the realities of it may not be perfect for all systems that traffic traverses, but the standards as they written, many of them allow this sort of thing to happen.
Right.
So it indeed should be that as the browsers feel that these contributions are mature enough for a very wide audience, that browser upgrades will include this as just par for the course.
And it won't just be Cloudflare that enables it for, as you've said already 20% of the internet traffic.
Other providers will do exactly the same at their edges from their servers.
They will enable the same kind of key exchange and transparently all those, you know, maybe there'll be some grand new icon on the top left.
It won't be a lock, there'll be some sort of atom and post quantum.
Marvelous thing, but we will be able to enjoy it.
Just.
Just. Yeah.
For the end user. For the end user, everyone.
It will be transparent.
It will just be done.
And I hope that also it will not affect performance and stability.
But for everyone who is working on it, this will be the big migration, the coming together kids.
Everyone will have to do do a software update and maybe a hardware update, some hardware even.
It really depends.
And some of them, hopefully for most of us it will be an easy path.
But I think there will be a long tail of things that are difficult to upgrade.
And I know we only have 2 minutes left here, but quickly for those CTOs and those CISOs out there that are worried about this now, that have applications that have APIs that perhaps don't need our browser partners to move forward, how can they test it today?
Is there a capability for them to go out and play around with interacting with cloud RPC?
Yeah, you can.
We have with open source support in borrowing SSL and go and more is added so you can just grab it and try it out.
Try if you connect to our website, you can try out peak now and see where it breaks.
And you shouldn't wait too long before for doing this. Yeah, it's amazing.
Awesome.
It's about timelines.
Yeah, exactly.
We have one minute left, John.
Any final thoughts you want to impart to our viewers and the in general?
Well, you know, we've only been talking about encryption so far with kyber and signatures are a big thing.
So I think you do have some a very technically advanced audience.
Start thinking about how you're going to transition the systems that you're using right now, both with encryption, which I think for most people that just means upgrading the software that they use because TLS is going to get it.
But also with signatures where I think we have a lot of people kind of doing things on their own.
I think it's time to start thinking about that as well.
I think it might also warrant another segment with Bas and Nick Sullivan and Eugene to really hash out over the course of 30 minutes why signatures are important.
Yeah, that will be a difficult transition.
Encryption is easier.
The future is going to be super great and I'm so excited that we're building it together with everybody.
John, thank you so much for joining us today.
Bos and Stephane, thank you so much for your contributions internally and for getting this over the line and for all of our Cloud viewers.
Thank you so much for joining us.
Have a good day.