Q-Day is coming: Here’s how to prepare for the threat of a quantum computer

So, I am the product lead for the transition to post-quantum cryptography across Cloudflare, which is a job I really enjoy. I also call myself the post-quantum janitor of the company, so it's my job to clean up all the cryptography. So, I'm going to talk today about post-quantum cryptography, what it is, why we need it, and how we're working to transition the cryptography that we use at Cloudflare so we can provide protection of post-quantum cryptography to our customers. So, let's get started. So, how many people here know the term Q-Day and have heard the term Q -Day? Okay. How many people have never heard Q-Day before? Okay, so Q-Day is just a short form. It's basically a marker that we're using to distinguish a day where we have quantum computers that are powerful enough to break cryptography, classical cryptography. And when we say cryptography being broken by quantum computers, we mean two classes of cryptographic algorithms, basically, which is RSA and elliptic curve cryptography. So this is the public key cryptography that's used as a building block for the whole Internet. And the reason that quantum computers can break cryptography is because of an algorithm called Shor's algorithm, which was invented by Peter Shor in 1994, to show how to do things like factor numbers very quickly on a quantum computer in a way that we can't do on a classical computer. So, quantum computers can do certain computations that classical computers, like the kind of computers we use every day, don't know how to do. And they're very good at certain kinds of math problems, solving certain kinds of math problems. And in particular, the math problems that they're really good at solving are the ones that underpin all the public key cryptography that we've been using for the last 20, 30, whatever years on the Internet, which is RSA and elliptic curve cryptography. So the remediation to these attacks, and I should say, Q day is a future day, right? We have quantum computers today, but they cannot run Shor's algorithm at a scale that can actually break the cryptography that we use on the Internet. And post-quantum cryptography is here to basically be based on a math that is not broken by quantum computers. So quantum computers are generally run, attacks with quantum computers are generally using Shor's algorithm. There are mathematical problems that are not impacted by Shor's algorithm, that Shor's algorithm can't solve. And so what post-quantum cryptography is, it's basically cryptography that's not based on RSA or elliptic curve cryptography. It's based on other kinds of assumptions, which are generally lattices. I don't understand lattice math. I don't understand elliptic curve math enough to talk to you about it. You don't need to know any of this. All I want to say is that there's the old kind of mathematical foundation for cryptography, and then there's the post -quantum mathematical foundations for cryptography. And for most people that are working in this area, including me, that's really all you need to know. And so the upgrade to post-quantum cryptography is really just changing the public key cryptography that we use to be based on different assumptions that are not broken by Shor's. So nothing in post-quantum cryptography involves a quantum computer. Post-quantum cryptography is just a software upgrade. It's a change to the algorithms we use for public key cryptography. There's no physical connection between devices. There's no optical things. There's no quantum effects. It's just different kinds of math. And so that's what post-quantum cryptography is. And so we have been investing in post-quantum cryptography since 2017, as Wesley said, on the main stage, hopefully you all saw. And recently, on April 7th, we announced that we were going to be ready for full post -quantum security by 2029. So this was a day we pulled forward our deadlines. We had like no real public deadline. We had like a mental model of 2035 for a quantum computer arriving. That was the mental model. Now, if you talk to our quantum computing experts, which are not me, but I talk to those people all the time, like every day, they would tell you that we think that there's about like a 5% to 10% chance that there would be a quantum computer that could break cryptography before 2030. So most likely it won't happen. However, I don't care because I'm a cryptographer and I deal in small probabilities. If cryptography is going to break with probability 10%, for someone like me, that's too much. So we can debate whether or not there'll be a quantum computer by 2030. Like I would bet that it won't. Okay. Because the probabilities are not like 90% that they will. It's probably 90% that they won't. However, we need to do something about this and be ready. Because if that 10% thing happens, then we don't want to be kind of caught off guard, like a deer in the headlights. We want to be prepared. And Cloudflare is an infrastructure provider to the world. And we want to be prepared, help the Internet prepare, and also help our customers be ready in case we have this quantum computer by 2030. The reason we pulled forward our deadline was a bunch of research results that came out around March 31st of this year. And that's the reason that a number of other companies have pulled forward their deadlines. The deadlines that were announced a couple of years before these results came out was that RSA and ECDSA would be deprecated by 2030. So this was an announcement made by NIST. NIST does not make these announcements lightly. That was a really big deal in 2024. But, you know, there weren't as many mandates that you saw a couple years ago as you see today. So for example, we are a vendor to the US government. And if we want to continue to sell to the US government, we need to be post-quantum by 2030. So there are these kinds of mandates that are coming out in financial services, in public sector, in different areas. And we have customers who are feeling this from their regulators and from their boards that they need to get ready. And we do see that in certain sectors. And for us as an infrastructure provider, we really want to be ready quite before everyone else because the rest of the Internet relies on us. Okay, great. So now that I've talked about dates and motivations, and feel free to ask me questions about any of this afterwards, is I want to sort of get into the technical details as a technical session. And so what we're going to do is we're going to talk about post-quantum cryptography, what the migration needs to be. So hopefully you can walk away and not feel like it's so mysterious. Okay, that's the goal. Okay, so we like to simplify things by kind of calling out two different things. One of them is post-quantum encryption. And the other one is post-quantum authentication. So what is post-quantum encryption? When we say post-quantum encryption, we mean algorithms to protect us against what we call harvest now decrypt later attacks. So this is an attack which an adversary collects your data now, stores it, waits for Q day, and then decrypts it after Q day. Okay, so your data today is at risk for harvest now decrypt later attacks. So your data today would love to be protected with post -quantum encryption, right? Because that means you don't have to worry about a future attacker decrypting your data from today. And in particular, if you have data that is going to be useful in three to 10 years, so for example, if you're a defense company, your defense systems are going to be interesting in three years. If you're a pharma company, your pharma formulations will be interesting in three years, right? All of this stuff needs to be protected in the long term. You want post-quantum encryption now, okay? So at Cloudflare, we've been investing in post-quantum encryption as our major point of focus for the last, I guess, 10 years or more, okay? So nine years, I guess I would say. And we actually, and when Wesley was up there on the stage, and he said, we have coverage, right? What he was talking about was post -quantum encryption, because what we're doing is we're covering our on-ramps and off-ramps. We're protecting them with post -quantum encryption today against adversaries that would harvest the data today and decrypt it in the future for Q day. Makes sense. Good. Okay. So that's cool. That's great. Now, the problem is that, you know, for a while we thought PQ encryption was great. It's all we need. And we'll just do that for a while. And we can't really kind of go around the business and start forcing everyone to upgrade their cryptography for anything other than PQ encryption, right? Because that's the threat that we're facing right now. And that's the world we were living in. And so if you have been following the industry, you hear a lot about data protection and harvest now decrypt later attacks. That was how we were thinking about it when we thought that Q day was in 2035 or later, right? Because that's so far away. We have time, right? But now we feel like we have less time. And so if we think we have less time, that there's some probability that we have less time, we need to also worry about attacks after Q day, right? Because everybody in this room probably knows you can't upgrade cryptography very quickly. It requires standards in NIST. It requires standards in the ITF. It requires ecosystem migrations. It requires coordinated deployments. This thing doesn't happen in a quarter, right? It takes time. So if we think Q day is in 2030, then we need to figure out how to be ready for Q day now so that we just can actually execute the transition. And so PQ authentication is sort of a term to cover things that we need to stop attacks after Q day when you have quantum computers attacking live systems, right? So you have a system that's being attacked now with a quantum computer, okay? So the main thing to think about is just unauthorized access, right? When I log into Cloudflare in the morning as a Cloudflare employee, I have access to Cloudflare things. People who don't work at Cloudflare do not have access to Cloudflare things for good reason, right? So if an adversary can start to compromise the authentication systems, they can log in as a Cloudflare employee and compromise our systems, right? Apply that to every system you can think of. This is a problem. So PQ authentication is really just about making sure that we can stop unauthorized access by adversaries after Q day. So big point number two is that this isn't just about data protection. This is just about security, right? So we have to be thinking not just about data protection, which is PQ encryption, but also about security for the long term. Okay, so now we understand what this is for. Let's talk about what we've accomplished at Cloudflare in terms of migration to PQ cryptography, and that is mostly post-quantum encryption, which is needed now to prevent harvest now decrypt later attacks. So we have been running PQ encryption on our edge. So basically, if you're a device that connects to Cloudflare and you hit our edge, you are going to let us know if you speak PQ encryption. So if you use a modern browser like Chrome or Firefox or basically any browser you could probably come up with at the top of your head, that browser will usually support post-quantum encryption. And so if they advertise to us that they speak post-quantum encryption in the browser, we will respond and we will create a post-quantum encryption connection. And this thing, this plot shows you the fraction, the share of browsers, the orange one, that know how to speak post-quantum encryption over time. So you can see this climbed over time, but also notice that it takes time, right? This is when we were kind of chilling because, you know, the NIST announcement only came around here. So you can see there's like not much happening. Then there was the NIST announcement and then, you know, it started to grow and this was Safari. This was the Apple ecosystem turning on. So we do, we have been able to support post-quantum encryption on the edge, but it really depends on what the devices that speak to us are doing. Okay. And so how can you see that this is real? So I picked a website. I picked Shopify because I know we love Shopify here at Cloudflare. If you do on Chrome, you do inspect and you look at the security tab, you'll see this text here. And somewhere over here, it's telling me that's post -quantum encryption encrypted. Can anyone see where that's happening? Okay. There it is. Okay. So that's PQ encryption. It's X25519. So it's an elliptic curve key agreement in parallel with a post-quantum key agreement. The result is being mixed together. And that is the secret key that's being used to encrypt your data. I'm not going to get into the cryptography here. I would love to, but I guess I don't have enough time. So that is PQ encryption and you can see it in the browser. I just wanted to point out, this is GCM, the Galois Counter Mode, which is used for symmetric cryptography. I just want to emphasize that this is running at AES 128. We are not upgrading symmetric cryptography. If you're interested, I can send you 12 blogs written by quantum computing experts talking about why we don't need to upgrade symmetric cryptography as part of the quantum transition. TLDR is the following. Symmetric cryptography is attacked with Grover's algorithm. Grover's algorithm is not Shor's algorithm. It's much less practical and efficient on a quantum computer. And if you talk to quantum computing experts, they will tell you they don't even know if it's more efficient than a classical algorithm because of the practicalities of quantum computers. So you're talking about Shor's algorithm, which is very highly optimized versus Grover's algorithm, which is not. And so as a result, our focus is on public key cryptography and not on symmetric cryptography. And I would really encourage anyone who's being pushed on symmetric cryptography to really potentially push back. There's tons and tons of blogs about this online by lots of different experts. A new one just came out from someone from MIT last week about why post-quantum encryption is really about the public key part and not the symmetric. Okay, so we can see it now. And so what does this look like on Cloudflare? So if you are a site behind Cloudflare, this is the connection between the browser and Cloudflare. This is where I showed you that graph, right? So we need the browser to be PQ because we don't control people's browsers. If you have an origin that's behind Cloudflare, you control that origin. So there's lots of ways you can make that origin PQ. One is if the origin actually supports PQ, we will speak PQ to it. If your origin doesn't support PQ, we have a compensating control, which is Cloudflare tunnel. You can put Cloudflare tunnel in front of your origin. That will create a post-quantum tunnel for you from the origin to Cloudflare. This is PQ encrypted. So even if your origin is not PQ, you're okay. You get end-to-end PQ protection. Okay, so very important. This is a compensating control. This is a really important concept if you're PQing things. Not everything can be upgraded. We can't trash all our hardware. You can't throw everything away necessarily to meet these deadlines. Sometimes you need to make compensating controls. And so this is a really good example of putting something that is PQ that's tunneling your traffic over a PQ tunnel because maybe your origin server is too old or you don't want to touch it or upgrade it, right? So this is a perfectly fine thing to do. And we have lots of such examples in our product suite. And I encourage you when you're thinking of your own transition to think about where you can get away with doing this rather than trashing something you've already invested in. Okay, I just wanted to let you know, we launched a feature a couple of weeks ago that was really cool, in my opinion, because I launched it with my intern. And what she built was, she built, if you have a domain behind Cloudflare, you can actually now go see what people are using to connect to your specific domain. We've had aggregate statistics for a long time, but now you can see about your specific domain and you can see this via log push in some of our dashboards. So if you want to learn how to set that up, there's the QR code for doing this. And it can help you figure out what user agents are the ones that are not PQ, what connecting services are the ones that are not PQ. So you go fix those endpoints that are not PQ and breaking your interoperability for PQ. Okay, switching gears into another part of Cloudflare's product suite, we have a Zero Trust platform, a SASE platform called Cloudflare One. In June, the Office of, oops, the Office of Management and Budget, which is a government office in the US, posted in their guidance that PQC is a key, is a foundational dependency for zero trust architectures. So basically, if you're building a Zero Trust system to secure your enterprise network, if the cryptography there is not PQ, you have a gap, right? Because you're going to need to upgrade that cryptography, you're exposed to harvest now, decrypt later attacks today. And so they actually put out guidance saying that you need to include PQC in your Zero Trust architecture. Well, this made me very happy because I, for a long time, was one of the product managers for Zero Trust, and I still am. And so Cloudflare One, we've been PQing all of the connections for a long time. And as Wesley announced, all of our connections into the Cloudflare One SASE platform are now PQ. So what this means is, you can use this for enterprise networking, where the enterprise network is connected with PQ encryption. Okay, so just to emphasize, I'm talking about encryption right now. We're going to talk about authentication next. So we have that on our client, which sits on people's devices. We have that with the Cloudflare D that I already showed for connecting into data centers. It works with Cloudflare Mesh. It works with Cloudflare IPsec. And so all that is there. And so you can think of your VPN or your SASE platform as another compensating control, because what you're doing is you're securing your perimeter and making that PQ. So that means you don't need every single service that you have in your environments to be PQ. If the connectivity that you're using into your environments is PQ, hopefully you're tunneling most of your traffic over that, right? So if you use, for example, like a VPN client like Cloudflare One, this creates a tunnel and all your traffic will go through this. This tunnel is PQ. And so it removes some of the need to make sure that this entire, you know, that whatever this is that it's talking to is also PQ, right? Because again, we've got like a giant compensating control. So again, please think in terms of compensating controls where you can. And so you don't have to necessarily upgrade every single service. Okay, cool. We have other, you know, PQ use cases. I just want to quickly mention, we announced that we have PQ encryption on our IPsec product. This was really fun because the standard was very new when we implemented it at the end of the start of this year. And we were able to actually show interoperability with all of these different vendors as well. This is not widely available at every vendor now, post -quantum encryption with IPsec, but it is for some, and we are able to interoperate with them. And we've also contributed some standards to make IPsec more robust to post-quantum downgrade attacks, and I won't get into that. So all of this is really fun and cool. And that's what we're doing on post-quantum encryption. I talk really fast. Let me stop talking. Okay, any questions about that before we, so I have time. So questions about post-quantum encryption and how to think about post -quantum encryption before we get into certificates. Yes. I saw a question. These quantum computers, right, as they're being developed that form qubits, they'd add all of the arts. Does PQ work in combination of how many qubits do you have Yeah. Yeah, that's a great question. So a quantum computer can be big and powerful in terms of the number of qubits it has, but then you need algorithms that can actually attack the cryptography. So we know algorithms that can run on quantum computers that can break RSA, for example, that's Shor's algorithm, right? So there is Shor's algorithm which can run on a quantum computer. We don't know of an algorithm that can break the cryptography behind MLDSA and MLChem, which are the post-quantum primitives. We don't have like the equivalent of Shor's algorithm that attacks those types of problems. And so even if the quantum computer is very effective and has a lot of qubits, there is no algorithm to run on that, that actually has an impact on lattices, any better than a classical computer would have impact on lattices. So right now there is no known quantum algorithm to break these quantum post-quantum cryptographic, post-quantum cryptography. So it's a really good point. There's two things you need. You need a computer that actually is, you know, has enough bits, but then you need an algorithm to actually break the cryptography. And that's what Shor's algorithm is. So we've had Shor's algorithm since 94. We just haven't had the computer. But now soon we'll have a computer, but we won't have an algorithm to break lattices. Did someone try to get at you with the quantum computer? Did you trace the source? No, I mean, this is the same as any kind of attack, right? Like if you were doing Harvest Now Decrypt Later attack, if someone collected your data from the public Internet, you may not see it. So there's not going to necessarily be markers of all of these types of things. Yeah, question there. Go back one slide. Yeah. Oops. For your Zero Trust algorithm? Yes. Are you possible post-quantum? Aha, we will be. So the answer today is no, but we have a team that's building it right now, actually. So we're working on that right now. Then there's a whole, yeah, so there's a whole work stream around that. So the question was, this is a post -quantum encryption support on our Stasi platform, a Cloudflare one. Is there post -quantum authentication? The answer right now is no, nothing, but we're working on it. I'm hoping that you'll be able to see something next year at the very least. So we're going to have to go through all of these different systems here and add PQ authentication on all of these systems. So that's not there yet, but that's coming. Yeah. So following up on that, both of the algorithms you listed were lattice-based and then SphinxPlus is the hash-based. Where are you guys at in terms of other code-based or other types of algorithms? Because the thought being, if you figure out the lattice-based encryption, that might be transferable. Okay, that's a great question. So I didn't talk about the ciphers that were used here, and I should talk about this. X2551.MLCHEM768, that's an algorithm that's been selected and recommended for use with TLS. There's currently only one recommended algorithm by, I think it's IANA for TLS, and it's that. So when we make decisions at Cloudflare about what algorithms to support, we don't make unilateral decisions because we have to live in an Internet that's interoperable. So we go with whatever the protocol standards would be. So if it's TLS, we need to go by the TLS standards. We do contribute to the TLS standards, but we have to go by those standards. And however the ITF arrives at its standards, we go through that process. And so when the ITF went through that process, this is where they landed. Now, so I mentioned the ITF. MLCHEM768, that's a NIST algorithm, right? So we need to talk about the standardized process, standard process, which I think is very confusing for people, and I didn't include a slide about this, but I usually do. So when things get standardized, post-quantum cryptography gets standardized, first we have algorithms, then they get standardized by NIST through contests, international contests where people submit algorithms that get studied and potentially attacked by anyone all over the world. The selected algorithms become NIST standards, but you know what? A NIST standard doesn't do me any good until it's actually part of protocols that we use. So the fact that something's a NIST standard doesn't mean it's a TLS standard. That's happening in the ITF. Something in NIST standard doesn't mean it's used in DNS or used in IPSec or SSH or JWT or any of the other standards that we rely on. So we have to wait for that process. So we don't really make decisions unilaterally about what algorithms to support. We see what NIST comes out with. We see what ITF comes out with. We do do a lot of work with the ITF more than with NIST, I would say. And then whatever that is, we go with. And so we try to build an interoperable Internet rather than decide that we're going to support one algorithm or another. And that's a very strongly held sort of belief about how we need to do things because we don't want to splinter the Internet as we're building this. Okay, last one. Yeah, go ahead. Hi there, Beto Cruz from Main Character. So we have a consultancy that has multiple client portals for the client, the coaches and whatnot. So what should we inventory or change now to prepare for post-quantum encryption authentication? Like, how do we do this without disrupting existing clients practically? Yeah, so I am going to talk about the transition and I have a bunch of slides about that. So let's get into the transition stuff. But I'm glad we took a pause and talked about encryption. So I want to talk about authentication, actually. So here's Shopify again. We're going back to this screen. Okay, so we looked together and we saw the PQ encryption, which was that X255 and whatnot in MLChem. But you can see there's also a View Certificate. Okay, so if I click View Certificate, I see the certificate. And this is the Certificate Authority, which is the WE1 Google Trust Service Certificate. So Shopify happens to bring this certificate into our systems. And then if I go over here, you can see that their public key and you can see it's an elliptic curve public key. So now you know it's quantum vulnerable. Okay, so we have another problem to solve, which is post-quantum authentication, making sure that certificates are post-quantum as well. All right, pretty much any certificate you will use today is quantum vulnerable. The reason is because the roots of the browser, the root stores, do not support any post-quantum certificates at the moment, public certificates. So we're making that transition that's happening, but it hasn't happened yet. So let me talk a little bit about our plans to PQ the certificates. We've actually been working on Merkle Tree certificates. One of my colleagues, I think he came up with them. I'm not completely sure. He came up with them. Okay, so Bas designed these and then he took them to the ITF. And now this is where the Internet is converging. And so the way that these work is post-quantum certificates need post -quantum signatures and post-quantum keys. Okay, post-quantum signatures are long. Now that's okay in a lot of settings, but it's not so okay in the web. If you ever look at a web request, you see how many HTTP requests will be made every time you view a web page. If you had to make those HTTPS handshakes longer, then they get slower and we don't want a slower Internet, right? And so there needed to be a solution for dealing with the fact that these signatures are so long. And that solution is Merkle Tree certificates. Just in one minute, I want to show you the way that it works is instead of just having a certificate and just issuing it with a signature, what the certificate authority will do is they'll have a bunch of certificates and then it'll hash it into this data structure like this. And this is sort of representing all of the certificates in this batch. And then that thing gets signed. Okay, so now you need a signature on only one signature on lots of certificates. So that's an extremely fast explanation. If you want to deep dive into this, my colleague Chris Patton is going to do a talk on this. So I really encourage you to come and learn about how these things work because these are the future of certificates on the web. We've seen a lot of different organizations mentioning Chrome, Apple. We have some CAs like Let's Encrypt that are going to support this. And we're also going to be not only a server that serves Merkle Tree certificates for our sites, but also an issuer of certificates, which just was announced at Birthday Week a couple weeks ago. So that's really exciting. We'll be both a classical CA and a Merkle Tree CA. So that's going to be a big change for the Internet. And you'll start to see these becoming online at the first half of next year. And that's what Wesley announced on the main stage as well, that we would be becoming a Merkle Tree CA. Okay, so of course, if we're going to secure TLS, we have to deal with all of the certificates. Now, the world of PQ has been maybe overly obsessed with TLS. So I just want to pop up and say, hello, this isn't just about TLS. Everybody in this room knows cryptography is used in lots of things, not just TLS. So if you're planning a PQ migration, you can't only think about TLS, even though most of the PQ solutions are TLS focused. And so as a reminder, cryptography is not just TLS. And so I have a few things to say about that. Okay, so the first thing I wanted to say is that if you are building on Cloudflare, and you want to start building systems that use post quantum cryptography, now you can, we support them in web crypto on workers now. And so this is like a fun example that was deliberately chosen, showing you how to sign a JWT with a post quantum signature. Okay, so do we know what a JWT is? It's what you use to authenticate to systems, right? And you have the holder of the JWT, I can't remember, then you have the issuer. And then you pass that along into like log into a website or to do OAuth to do SSO. So these things are usually signed, and they're usually signed with RSA, by the way. That's the standard, the must support algorithm is RSA. There is a new standard for post quantum JWTs with MLDSA, they're called MLDSA 44 JWTs, rather than RS 256 JWTs. So we're now going to have to transition to this, right? So you can start to use these on Cloudflare Workers. And we also internally at Cloudflare have to do a lot of work to transition all our JWTs to PQ JWTs, because JWTs are what do authentication. So if those are not post quantum, they're not secure. And we have attacks after QA, right? So this isn't about data protection, this is about unauthorized access, access tokens need to be post quantum. Okay. Okay. To your question in the front row. These are some quotes from different places, recommending that organizations begin to develop their transition plans. If you look at this, some of the dates are 2026, some of them are Q1 of 2027, developing a transition plan. So Cloudflare is also developing a transition plan. I'm really proud to say that I'm one of the persons figuring out the transition plan, which has been really fascinating and interesting. And so I wanted to talk a bit about our transition plan, how we're making a transition plan, and what we've learned so far, as we're in the middle of this, which we're still in the middle of. So to help our transition plan, we built a tool called Cryptolabe from Astrolabe. It's our internal cryptography discovery tool. You may have noticed that this company really likes to build things. And so as a result, most of the things that we operate are built by us. As a result, we know how they're built. We have the code. Okay. So we have many, lots of code, lots of products. They're all sitting in our code repositories. So our approach for discovering cryptography and understanding what cryptography we had to start with, was actually scanning our own code repositories and see what we can find in there. And this makes sense for us. Other organizations may have other types of balance between build and buy, but for us, it makes a lot of sense. So Cryptolabe is our internal tool. The reason it's internal, because I, you know, I believe that every organization is going to be different. And our value proposition right now is to really help people accomplish the PQ, like become PQ by using us. But there is a whole sort of world of figuring out how you're going to actually discover cryptography. So the way we did it with static code analysis, we've open sourced the prompts that we use. So if you want to grab the prompts and try them on your own repositories, they're there. And so we built a tool on our Cloudflare developer platform to scan our code repositories and find cryptography and analyze the cryptography findings. So here's the result of one of the findings. You'll notice I put a JWT here. I've lots of different findings I could have shown. Again, I put the JWT here for a reason. We found RS-256 tokens. Those are RSA with SHA-256 tokens. So that's quantum vulnerable because it uses RSA. So we have to upgrade this. We have lots and lots of these things. And in fact, I would say that like if we, before we built Cryptolabe, I wasn't personally so obsessed with RS-256 tokens as I am today, because we have a lot of them. You may have something else in your environments that will cause you to become obsessed with them. But this is the thing that we've become obsessed with. We found all kinds of other things. We found SAML, which is an authentication protocol, which is kind of old. Doesn't have a PQ standard in the ITF that works. How are we going to upgrade this? I don't know. We might stop using it. I don't know. So like there are stuff like this that you'll find as well, which is maybe harder to think through. And so this is what we found. And so as a result of this, we put together a transition plan. This is really high level, but we've kind of created different tracks. We have a TLS, which is the majority of our stuff is TLS, and some IPsec and SSH as one track. We have JWT and Identity as another track. We have hardware as another. And then this is like the bucket of other things that don't fit neatly into this. And we don't have as much sort of volume of these things. So we start with pilots this year in these two areas. We're going to then be migrating all of our TLS, JWT to PQ, both authentication and encryption. And then for hardware and firmware, we actually have an architecture that is in the process of being approved right now and being reviewed by people. Then our hardware team is going to be building to this architecture for the next year. Again, compensating controls are your friends, right? And so finally, for other stuff, some of this requires ecosystem work. We have blind signature schemes. We have things in there that are more custom, more specialized that has to be addressed. And so our research team is focused on those. And in 2029, we're going to be looking at how to deal with third parties where hopefully our third parties catch up to where we are as well. Product-wise, I just wanted to share, we're going to launch an MTCCA. Cloudflare 1 will be fully PQed, to your question, 2028. So that's the goal. And then we have this gap for dealing with our dependencies. So my recommendation to answer your question is really think about what are the tracks, what are the things that you have, right? We have a lot of code, stuff that we've built. We have a lot of TLS. We have a lot of JWT. We have IAM systems that we built ourselves. So all those things have to be migrated as part of a big standout across the company. And so that's why we've kind of pulled them out here because there's just so much of it. And then of course, hardware is its own track. You may find that you have other ways to do this. Maybe you have a set of vendors. Maybe if you're a bank, you have some kind of interbank protocol that needs to be PQed and you have to work with your partner banks. Like, I don't know what you're going to have, but kind of thinking about what are the tracks and what are the problems and where are the standards? Where are your partners? How are you going to figure all of that out? So that's the way we've been thinking about this. And I know this is high level, but again, we're also figuring it out as we go. Okay. So this is the last thing I wanted to say. So what can you do having left this room? So hopefully we understand this is really just about software, changing the algorithm, changing the software for the most part. I do think building a transition plan in the next like three to nine months makes sense. What are the systems you're going to upgrade? What are the programs you're going to upgrade? How do you find the cryptography that you have? And I would say, even for the purpose of a transition plan, you don't need perfect crypto discovery. You just, if you, we ran our crypto lab like two months before we considered it anywhere close to ready and we found a million JWTs, not a million. We found a lot of JWTs and it was like, oh, JWTs, right. Like we need to think about this, right. Before that we weren't focused on JWTs as much. So that will probably happen to you. So even just sampling like what you have in your environments will give you an idea of like where the problems are. Question your vendors. So at Cloudflare, we want to be your compensating control. Your vendors can be critical compensating controls. That's why our WAF and our CDN are PQ encrypted and will be PQ authenticated. As someone who worked in this market for many years, I think this is maybe one of the strongest value propositions that you can have at enterprise networking. If your enterprise network is not PQ, it's currently vulnerable to harvest now decrypt later attacks. So there's really no reason for it to not be PQ at this point because it is something that you can get. Cloud providers, identity providers, by the way, none of this is existing yet. Identity providers. So ask your identity provider when they're going to be PQ. They're going to all wake up, I think in the next like six to nine months, but we don't have yet a PQ identity provider yet. Outside of busting your binaries, you have any other ways we can identify dependencies in your binaries? I don't. We didn't try that. I don't. We haven't tried that. Yeah. So there's this cottage industry of like PQ consulting and discovery. We were very lucky. I would say that because so much of our stuff is built in code that we don't need any of that really. Like we can see what we have. And generally, if you know how Cloudflare is built, like we're a giant TLS overlay on the Internet. So we kind of assume that like just because we have a colo here and a colo there, they're like quote unquote connected. They're actually going over the Internet. So all of that is insecure, right? We have a TLS connection that protects them and that's the TLS connection that we built and we controlled. So like the way that our network is built actually makes it a little easier for us to PQ it because we don't have like dedicated links that we know are somehow secure. We assume everything is insecure unless it's sent over TLS. So if we PQ those things, we get what we need and we don't need to go into the lower levels. I have talked to companies that are like layer two network providers in Australia, for example, like that's a different protocol, a different layer, and that's what they're offering and that's where they have to focus. But that's not where we operate, right? So I guess everyone will be in a different place depending on what your services are. So just trying to understand like what is your transport? What layer are you operating and what is your security properties? That's where the that's where the analysis has to come from. So for us, it's TLS and JWT. For you, it may be IPSec and JWT or OAuth or something like this. Okay, as I mentioned, post-quantum encryption is a mature enough technology at this point. It is a recommended algorithm in TLS 1.3. So if you're still on earlier versions of TLS, it's time to move to 1.3 and get some PQ encryption. And then this is the other thing. We have a really big focus on just uncovering what we don't know. So if there are systems that don't understand or cryptography that's like quote-unquote non -straightforward or exotic, it's not so exotic, but like a blind signature or maybe, I don't know, whatever you may have, right? So knowing what those systems are and starting on them early, like this can be a long project, let's say, to PQ things that are less, you know, standard and less going to come out of the ITF and less going to kind of evolve from the ecosystem. So hopefully you don't have too many of these, but if you do, don't ignore them. Look at them now and start thinking about what you're going to do because you can have some years to solve the problem as opposed to like a short time. A long time is better than a short time. So that's my suggestions on what to do next and that is what we're doing ourselves. So yeah, that's the plan. Cool. And on that note, I'm actually really happy to finish. So thanks everyone.