Preparing for Q-Day

Most of the cryptography securing the internet today rests on mathematical problems that classical computers cannot solve in any reasonable timeframe. That assumption is now being tested. Recent advances in quantum computing have dramatically compressed timelines, and many in the industry have set a target of full post-quantum security by 2029, meaning a complete migration to algorithms designed to remain secure against quantum attacks. Bas Westerbaan https://x.com/bwesterb is a cryptography engineer at Cloudflare https://www.cloudflare.com/, where he leads the company’s efforts to migrate to post-quantum cryptography. In this episode, Bas joins Kevin Ball to discuss how quantum computers threaten public key cryptography, what post-quantum algorithms actually are and how they work, the timeline shifts that have made quantum readiness feel so urgent, and what software engineers need to do now to prepare their systems. Kevin Ball https://www.kball.llc/ or KBall, is the vice president of engineering at Mento and an independent coach for engineers and engineering leaders. He co-founded and served as CTO for two companies, founded the San Diego JavaScript meetup, and organizes the AI inaction discussion group through Latent Space. Please click here to see the transcript of this episode. http://softwareengineeringdaily.com/wp-content/uploads/2026/06/SED1936-Cloudfare-Quantum-Readiness.txt Sponsorship inquiries: [email protected] https://cms.megaphone.fm/organizations/619b680e-d813-11ea-9750-e7ecac406436/podcasts/e60108fe-e328-11ea-b2b6-1348249f900a/episodes/3913370a-bc44-11ed-ace6-8b1f96d82bba/[email protected] The post Preparing for Q-Day https://softwareengineeringdaily.com/podcasts/preparing-for-q-day/ appeared first on Software Engineering Daily https://softwareengineeringdaily.com.

• 0:00Speaker 00

  Most of the cryptography securing the Internet today rests on mathematical problems that classical computers cannot solve in any reasonable timeframe. That assumption is now being tested. Recent advances in quantum computing have dramatically compressed timelines, and many in the industry have set a target of full post-quantum security by 2029, meaning a complete migration to algorithms designed to remain secure against quantum attacks. Boss Vestabon is a cryptography engineer at CloudFlare, where he leads the company's efforts to migrate to post-quantum cryptography. In this episode, Boss joins Kevin Ball to discuss how quantum computers threaten

• 0:41Speaker 00

  public key cryptography, what post-quantum algorithms actually are and how they work, the timeline shifts that have made quantum readiness feel so urgent, and what software engineers need to do now to prepare their systems. Kevin Ball, or K-Ball, is the Vice President of Engineering at Mentoo and an independent coach for engineers and engineering leaders. He co-founded and served as CTO for two companies, founded the San Diego JavaScript Meetup, and organizes the AI in Action Discussion Group through Latent Space. Check out the show notes to follow K-Ball on Twitter or LinkedIn, or visit his website, kball.llc.

• 1:30Speaker 01

  Boss, welcome to the show.

• 1:32Speaker 02

  Hey, Kevin. Nice to be here.

• 1:34Speaker 01

  Yeah, I'm excited for this topic. This is one that has been suddenly raising my awareness, but I don't know enough about it, so I'm really eager to pick your brain. But let's start with a little bit about you. Can you kind of give us a little bit of your background and how you got to where you are today?

• 1:49Speaker 02

  It's quite a windy road. I always liked security and cryptography at high school. Decided to go study physics and mathematics, because I thought it would be more challenging. Didn't end up being very good at the physics, so I stuck with the mathematics, at least. I mean, physicists, they know how to bend the rules, right? And I don't know how to do that. Did mathematics, then I did a PhD, going back to physics a little bit and the mathematical foundations of quantum computing. And the physics kept pulling me. But actually, I did that at the security group of my university. So when I would be avoiding working on my actual thesis, I would be spending time with the cryptographers around there.

• 2:32Speaker 02

  So there's the, there's people doing post quantum cryptography there and this is symmetric cryptography. So I kind of learned by osmosis just during the coffee breaks and stuff. After that, when I did, went for a postdoc to London. London is expensive, so I thought, maybe I can find an internship or something. Already some crypto engineering, so I via via, I ended up with an internship at Cloudflare. I enjoyed that so much doing crypto engineering there that after COVID, I got invited to join full time in the Netherlands back. And I've been there ever since, leading for the last few years, our efforts in migrating to post quantum cryptography.

• 3:11Speaker 01

  That's awesome. I actually also started in physics. I studied physics as an undergraduate and got away from it. And then like in recent years, there's all these things that feel like, oh, that's suddenly relevant again. There's so much that is becoming interesting. Let's talk a little bit about quantum security, quantum cryptography and all of this. Cause I feel like this is something that most of us as software engineers weren't worried about. Hasn't been that big on the radar. Maybe if you were in kind of a niche area and then suddenly it's a big concern. So maybe start back with like, what are the problems that quantum computers create for cryptography?

• 3:48Speaker 02

  Yeah, so quantum computers, it's quite an old concept. I think even earlier than the nineties, Richard Feynman, the famous physicist and some other folks, proposed that you can use quantum computers to more efficiently, similar in nature. So the whole thing about quantum computers is that things are in superposition. So if you want to compute things about them, you have to carry around actually an exponential number of probabilities, which they call amplitudes, which is inefficient. But then they realized if you use quantum mechanics itself, the full power of it to actually do computations instead of just using zeros and ones, you can actually compute it more efficiently. So that's all well and good, the physicist's toy with hopefully amazing applications in material science and stuff, but.

• 4:34Speaker 02

  So it was all positive until in 94, Peter Schor, mathematician, he figured out that if you have a quantum computer, then you can also efficiently solve factoring and discrete logarithms. And that's a little bit inconvenient because basically all of our public key cryptography, not all cryptography, but basically all cryptography, that's important, relies on that today. So if a quantum computer is actually built, doesn't exist yet, but if it's actually built, that's big and powerful enough, then most of the cryptography falls away.

• 5:09Speaker 01

  Yeah, that's really interesting. So I think some of our listeners will be crypto experts, but let's maybe really quickly talk about asymmetric cryptography and like how this works and why this ability to factor large numbers suddenly makes this fall away.

• 5:23Speaker 02

  So you have these two big groups of cryptography, symmetric cryptography, which is AES, SHUTU. That's mostly about jumbling bits, right? Mix things up a bit so that they become unpredictable. That's in a way, it's a bit of a messy thing, but it's well understood and quantum computers don't touch that. That's still completely fine. Now, the public key cryptography, that's the cryptography where you have a public and a private key. And that requires something mathematical, sort of magical to make it work. And in the case of elliptic curves, that's discrete logarithms. And in case of RSA, it's using the fact that multiplying numbers is easy, but factoring them is hard. Well, we think it's hard. It is hard, we think, for normal computers, but for quantum computers, it's pretty easy.

• 6:07Speaker 02

  And the problem is, if you can solve that problem, if you can do a factor a number easily, then you can also break the public key and from the public key derive a private key. And maybe we should go, what does this actually mean? What's the actual impact, right? Instead of the mathematical bits. And the thing is, so we use cryptography for basically two things, mostly. I mean, for a lot of things, but the two big things are protecting data and protecting access and authenticity.

• 6:35Speaker 02

  So if you make a connection, you do a TLS handshake, there's what is called a key agreement first. And after the key agreement, both sides have a shared key, which they then use for bulk encryption using typically AES. So this key agreement today also relies on either elliptic curve of RSA. And if that's broken, then people who recorded the encrypted conversation can retroactively decrypt it and see the data. So that's the famous harvest now decrypt later. People can record encrypted sessions today. And if they are not protecting using post quantum cryptography, cryptography designed to be secure against the attack of quantum computers, then they can be decrypted in the future. So that's one.

• 7:19Speaker 01

  Yeah, and just to like even put it in broad terms. So that's every connection we have today, especially now. Everything's using HTTPS. If you're on the web, you're going and logging in to Google, to your bank, to what have you. All of those at the root are doing a TLS handshake, shared key and encrypting it using AES, which if it's being recorded, which I mean, I live in the United States. I kind of unfortunately assume everything is being recorded at this point. All of that could be replayed and cracked with a quantum computer.

• 7:49Speaker 02

  Well, luckily, we have made some good. I mean, we've known about this problem for quite a long time and we've made some good progress. By default, if you use a modern browser, Chrome or Safari or Firefox, then that already tries to make a connection using post quantum cryptography that is that secures it against harvest now decrypt later.

• 8:08Speaker 01

  So that is good to dig into. So actually first, what does it mean to be post quantum cryptography? What is that?

• 8:14Speaker 02

  Yeah, so post quantum cryptography is cryptography that is designed or we believe is secure against the attack of quantum computers. So the funny thing is, is this cryptography is typically already quite old. So so LatticeS, which is the frontrunner. I mean, there are many different types of post quantum cryptography. Hash based cryptography, lattice based cryptography, asogeny based cryptography, not a very base cryptography. The one that are really taking are on the frontier that are being deployed now is lattice based cryptography. And we believe that they are secure against the attack of quantum computers. Believe that sounds weak, but I mean also with classical cryptography tomorrow, we can wake up and someone discovered a classical algorithm to factor numbers quickly. That is possible. Luckily, it hasn't happened, but for the best of our knowledge, we have quite a good confidence in it,

• 8:59Speaker 02

  that lattice based cryptography is secure against the attack of quantum computers. And if you use that lattice based cryptography, then you're secure against this threat.

• 9:08Speaker 01

  So let's maybe really quickly talk about what that actually is because I, you know, I think it's, I enjoy geeking out on this, right? So we've talked about the two examples where you've got elliptic curves and computing things there. We're using logarithms. We talked about large number multiplication being easy, but factoring being hard. And those are kind of the two quantum crackable approaches that we have. So what does it mean lattice based cryptography? What's the underlying math happening there?

• 9:31Speaker 02

  Yeah, so what is a lattice? So a simple example of a lattice, it's simplified example of it. Toy example of it is think of a plane. So a plane with X Y grid. And you have two points on the plane. So we start with just two points. Now what we do is we create a grid from those points where each of those points, they make, think about a parallelogram and then it just repeats, it repeats. So if you have such a grid at this point, it's very easy to say, what is the smallest point in the grid that's closest to the origin? That's pretty easy if you give the grid as two points that are like neatly orthogonal. So that's what they call a good basis. But you can also give the same grid by giving a point that's very far away,

• 10:14Speaker 02

  two points that are very far away and close together. Those two points can also generate the same grid. But that's what's called a bad basis. It's a basis where it's not that clear to see where the actual smallest point in the grid is. A picture is worth here more than a thousand words, but maybe you can add a link to a picture about this.

• 10:35Speaker 01

  Yeah, I mean, I think conceptually it makes a lot of sense, right? Where if you're imagining this plane, if we're looking at a point that's very close to the origin, you can be very zoomed in. It's able to be very high level of fidelity, high detail. You have two points, okay, but you're still looking in very good fidelity. Whereas if it's very far out, conceptually, you're having to zoom way out. And it's hard to see any level of detail.

• 10:59Speaker 02

  Yeah, it's also when they're close together, it's really hard to see how will things cancel out if you start adding and subtracting them. But actually, on the plane, you can, I mean, it's a fun thing to run an algorithm for it if you're lighting your spare time. It's actually pretty easy to figure this out in the plane, right? Because that's just two dimensions. But it turns out that if you do this in a space that has a thousand dimensions, it's not just X and Y, but a thousand different directions, then this becomes computationally very, very hard. And that's the basis of lattice based cryptography.

• 11:27Speaker 01

  So I'm going to use the example of the multiplication and factoring because that one I understand personally more than I understand the elliptic curve one. In that example, the way that the public and private works is you say, okay, if we know the private, we can do the multiplication root. We just show the end version. We both got to the same thing, but somebody just seeing that end version, they can't factor it. In the lattice, what is the equivalent here? Like, what am I sharing with my counterparty? Or how do I get to some sort of shared basis for encryption?

• 11:57Speaker 02

  So actually, do you know about Diffie-Hellman, the clock things?

• 12:00Speaker 01

  Only somewhat. Why don't you explain it and then we can go with it?

• 12:03Speaker 02

  Diffie-Hellman is a classical one, which is based on discrete log, where each of us starts with a secret number, A and B. And we do this using modular arithmetic. So it's like time on a clock. I have a secret B, you have a secret K, right? For Karen and Boss. And we both agree on the basis number, let's say two. So I compute two to the B and modulo, I don't know, the big prime number we choose. And you compute two to the K. You send two to the K to me, and I send two to the B to you. Going from two to the B, figuring out, I mean, if it's normal numbers, it's easy to take a logarithm. If you see two to the B, to then see what is B. But if you do this modular prime, this is actually hard.

• 12:46Speaker 02

  This is called the discrete logarithm problem. Well, hard for us now with our puny classical computers, but with the quantum computer, it's easy. Okay, so that's the public key, 2 to the B. It's my public key, 2 to the K, your public key. Now, you've got my public key, 2 to the B. And what you can do is you can exponentiate in your K. So you can do 2 to the B to the K. And I can do 2 to the K, and I can exponent in B. So 2 to the K to the B. And what we end up with is, both of us end up with 2 to the B times K.

• 13:20Speaker 01

  Right.

• 13:21Speaker 02

  So we both got the same shared number, which we can use as a secret to then do AES. So this is called Diffie-Hammam. And with lettuces, you kind of do the same, but then with adding a lot of noise. So it's like a noisy version of this.

• 13:39Speaker 01

  That makes a ton of sense, actually. That's really helpful. So you're each starting with essentially this like small, easy to understand piece. And then you layer it and you end up with this, okay, this is way out in the world. This is hard to decrypt.

• 13:53Speaker 02

  My colleague, Chris Button, he wrote together with Peter Schabber, one of the designers for the scheme. He wrote a nice blog post with this analogy explaining it some more. I really don't do it justice in five minutes. Maybe we can add a link to it.

• 14:04Speaker 01

  Yeah, we can go and check that out. So if you're looking for it, Google will turn it up, I'm sure. Okay, cool. So that, I think, helps us understand a little bit more about like an example of post-quantum cryptography. And so you're saying, essentially, we're all, if we're using modern browsers for web traffic, we're pretty much all protected from?

• 14:22Speaker 02

  That's bad news, almost.

• 14:24Speaker 01

  Okay.

• 14:25Speaker 02

  We're protected against harvest now, decrypt later.

• 14:28Speaker 01

  That's where I was gonna go. Yeah, we're protected against harvest now, decrypt later. But there was this recent announcement from Google that I think has shifted the threat model a little bit.

• 14:38Speaker 02

  Yeah, so Q Day. Q Day is the day that we expect there will be a cryptographically relevant quantum computer one that's powerful enough to actually crack real keys used in production. And if you think that Q-Day is far away, then it's really about the harvest now, dig up later, right? It's about, I'm still using, if we're honest, I'm still using passwords I've been using 10 years ago. I don't want to change those passwords. I want them to be secure today. So if Q-Day is far away, it's the harvest now, dig up later. But we don't just need to fix the harvest now, dig up later, bit of it, we also need to fix the authentication, the certificates bit of it. Because just as we explained, we had this shared secret, this 2 to the B to the K, which we can then use for AES.

• 15:20Speaker 02

  But we did this exchange, but how do I know that I'm actually talking to you, right?

• 15:24Speaker 01

  Yeah, yeah. How do you know that you're sending your secret to actual Kevin and not someone else?

• 15:29Speaker 02

  Yeah, it might be someone in the middle who does this dance with me and with you separately and then re-encrypts everything, right? That's a classical man in the middle attack. So the way that that is solved is that we use certificates to authenticate. So after we do this thing, you would send me a certificate signed by a certificate authority, which says, I am Kevin, I have, I don't know what's your personal website. I mean, in TLS, it's, the CA says, you can trust this public key for doing connections with this particular domain. So a key agreement ensures that you have a secure connection, but you don't know with whom. And the certificates make sure that you're talking to the right person.

• 16:10Speaker 01

  Yeah.

• 16:10Speaker 02

  Now, there's no deployment of post-quantum certificates today. It's all classical certificates stuff, which is fine.

• 16:16Speaker 01

  Until Q-Day.

• 16:17Speaker 02

  Until, yeah, until Q-Day, right? Because COMQ-Day is not just about an active attack, right? Because COMQ-Day has these root certificates of big certificate authorities. A quantum computer just has to crack one of them. I mean, each browser trusts a whole bunch of them, not just 10. So it's hundreds of authorities that are trusted. Quantum computer just has to crack one of them and then create a certificate trusted by basically any browser or basically everyone uses the same kind of trust infrastructure as the browsers. That's a huge problem.

• 16:49Speaker 01

  And so when you have that in place now, suddenly the consequences of this is essentially whoever owns this quantum computer can set up a man in the middle to anywhere.

• 16:57Speaker 02

  Well, not just men in the middle, because that sure they can do a man in the middle, but they don't need to be in the middle. They can just, if I crack a CA key, I can create my own certificate. I don't necessarily have to be in the middle. It depends on what it is, right? I can, if I'm on your network, I don't even have to talk to the actual server. I can just respond as if I were the real server, right? It's just not in the middle. It's just you talk to no one else but me. But it's even scarier with things like, for instance, if you have a phone, the way it trusts a software update is using a public key.

• 17:32Speaker 01

  If you have a Tesla or some other car that does over the wire updates or other things?

• 17:36Speaker 02

  Yeah, so last year I bought a new secondhand car, which is new enough that it has a remote unlock and all this kind of jazz, but old enough that it probably won't get any post quantum updates. I don't want to buy a new car, so probably, let's hope at least we can turn off the remote control functionality. One of the best practices in software is to have auto update mechanisms, right? That you can quickly push in a software update for a zero day. Every software update mechanism becomes a remote code execution for a quantum attack.

• 18:09Speaker 01

  So what do we do? You mentioned for fighting against decryption for this by now, our Harvest Now decrypt later, like we have alternate approaches that we know work, that we've been deploying out through at least critical pieces of software, like browsers and things like that. Do we know the answer? What does post quantum authentication look like?

• 18:33Speaker 02

  Yeah, so maybe also in the previous one to say, actually, on our view, we can see how many of our clients already can do the post quantum key agreement, and that's now more than 65% already protected. I mean, that's

• 18:46Speaker 01

  That's pretty good.

• 18:46Speaker 02

  Yeah, we want, of course, we want high, we want 95%, 100% ideally. We never get to 100%, 95 would be nice, but it's pretty good, yeah. But that's, we turned it on in 2022, and it took until now to get to 65%.

• 19:03Speaker 02

  We know how to do post quantum authentication. We have the algorithms. It's trickling down in software as we speak and people are starting to move faster.

• 19:13Speaker 01

  Amazing what threats will do, right?

• 19:16Speaker 02

  Yeah, yeah, yeah, yeah, yeah. Things move fast. I mean, people start only working when the deadline is near anyway, right? If we're completely honest. So we have the algorithms. We're finishing up the final little standards, how to do it in the protocols. It's just about deploying. And I think there's good news and bad news here. I think like a lot of software development, there's a 90 10 rule here where in the vast majority of cases, it will not be a very difficult upgrade. In a sense, it's just a different type of certificate. It's just you have to keep your software up to date. You just install a different kind of certificate and you're secure. But it's a 10% of cases that are really difficult. It's the cases where you critically depend on cryptography baked into hardware, where you can't replace the hardware.

• 20:01Speaker 02

  It's when you depend on the box that someone bought before you joined the company. Does the vendor still exist? What does it actually do? It's these hard cases for several reasons that you need to service, which makes it hard. And also by its urgent to start looking to even know what the deal is. But luckily, and probably if you just use modern stuff, PLS, then it will probably be reasonably straightforward.

• 20:28Speaker 01

  So let's start with the straightforward ones and then we can like dig our way down into the deeper ones. So to deploy this out, it sounds like first you probably need the certificate authorities themselves to be updating, having another approach. And then it's for users, it's like a software upgrade. It's like, okay, next version of Chrome, next version of SSH and all these other different things. They're going to use post quantum authentication?

• 20:52Speaker 02

  Yeah, so Chrome already announced their roadmap on when they will accept post quantum certificate authorities and they will start accepting them in Q1 of 2027. So probably we will see the first ones then. So one thing that is new is that you will need two certificates because the thing is not everyone can upgrade at once. Maybe if you have an internal network, you can just replace everyone, have a flag, they flip the switch. But if you have some kind of serious system or maybe even just. A few different teams in a big organization, you can't get it done all at once. So you need to be able to deal with clients and servers that both are not upgraded yet.

• 21:31Speaker 02

  So on the server side, that means that a server needs to be able to install both a traditional RSA or an ECC certificate, but also a Post Quantum certificate.

• 21:41Speaker 01

  Oh, that's right. So it's not just the root certificate over at the authority that needs, like this actually needs to get deployed out to anyone with a web server, essentially.

• 21:49Speaker 02

  Yeah, yeah, of course.

• 21:50Speaker 01

  It makes sense, but I hadn't made the connection somehow. So yeah, okay. So anyone running your own web server, you've got NGINX doing something or whatever, you're going to need to update. Next time you do a certificate update, you need to have two of them.

• 22:02Speaker 02

  Yeah, so hopefully a lot of people do certificate automation, right? So you don't do this certificate installing yourself, you get Acme or some kind of Acme client to do it for you. So hopefully that's easy.

• 22:13Speaker 01

  That's maybe the 90% case at this point. I, that feels generous, actually. I don't know if we're up to 90% of people hosting servers are already using like Acme. I don't know.

• 22:22Speaker 02

  I mean, it's something you can do today, right? Even though there are no Post Quantum certificates today, you can at least do certificate automation today.

• 22:28Speaker 01

  Yeah.

• 22:28Speaker 02

  Another thing you can do is check whether your application server can actually install two certificates. A lot of pieces of software assume there's just the one certificate, right? Just one slot, whereas you really need at least two slots here. Although if it turns out it's really hard to get application servers to move, we might need to define an ugly certificate format where we squeeze in two certificates into one. But let's hope we won't need that.

• 22:54Speaker 01

  How bad would that be? Because I, you know, once again, having been burned before, I suspect there will be a long tail of application servers that are not going to be updating.

• 23:03Speaker 02

  Oh, for sure, for sure. That's the reality, right? We can't have the slow movers hold back the fast movers, right? And also, one of the things is you need to, for instance, if you go to an office and you go to the parking lot and there's the turnstile, does that thing dot PQ? If we want to upgrade that, do we need to replace the whole thing? I mean, is it worth it? Do we really care if someone with a quantum computer can have free parking?

• 23:28Speaker 01

  It's fascinating. It reminds me of the whole Y2K scare, except we have orders and orders and orders of magnitude more deployed software and hardware at this point.

• 23:40Speaker 02

  And also the cryptography, we've had 50 years to put cryptography basically everywhere. And usually we hide it. And once cryptography is there, you don't want to touch it, right?

• 23:50Speaker 01

  Yeah, it's working.

• 23:51Speaker 02

  It's working, it's fine. Unless it's really broken, people don't really touch software, right? Cryptography, software, of course, with crypto, yeah.

• 23:59Speaker 01

  So, okay, interesting. So let's dive a little bit more. So imagine you're in a world where you own some of this software, right? The 80%, 90%, I'm just deploying new software. I don't, I'm not building the software. It's somebody else's job to make this accept two certificates, whatever. I just need to roll out updates. But now let's step back and say, okay, we're a bunch of software developers. Probably some of us have software where this is actually relevant. So what do we need to do then? Is this like just dropping in some new libraries? Or there are bigger changes, other performance considerations? Like, what does this look like?

• 24:31Speaker 02

  So the big things are common best practices, right? So already mentioned, keep software libraries up to date. Be able to install two certificates, do certificate automation if you can do it. So those are generally good advice that you can do today. On internal PKS, you can already use it. If your software library supports it, then you can already use and deploy Post Quantum certificates. So you can already do that today for internal networks. For public CA's, you have to wait until 2027. Now, on the things that can go wrong, Post Quantum signatures are larger. Elliptic curve signatures, they're only 64 bytes. And because they were so small and fast, we use them basically everywhere. If we had a problem, we solved it with an extra signature.

• 25:11Speaker 02

  So when you make a TLS connection, there's typically six signatures that the server sends to the client. So now they're not small anymore. An MLD SA44, which seems to be the most commonly used Post Quantum signature. If I'm reading the T-leafs correctly, that is two and a half kilobytes.

• 25:29Speaker 01

  Sending it six times per connection, wow, yeah, okay.

• 25:33Speaker 02

  So we're looking at about 15 kilobytes from server to client on the handshake. If you go to YouTube, that doesn't really matter, right? If you go to YouTube. But it does matter in some other cases. So there are two reasons. Performance. If you look at all the connections that are made with Cloudflare over Quick, so that's mostly browsers, about half of them transfer less than eight kilobytes. So if you just do a drop-in there, then it means that we're adding like...

• 26:00Speaker 01

  We've tripled the payload, yeah.

• 26:02Speaker 02

  Yeah, it means that half of the connections transfer, three quarters of that would just be certificates instead of data. The actual impact is also still, and user impact is also a question, but it doesn't look good, right? Because we want to turn this stuff on by default. And if there's potential for performance degradation, we don't want complaints.

• 26:20Speaker 01

  Yeah.

• 26:21Speaker 02

  To be able to turn it on by default, we need to have that no one can complain about the performance. We do have tricks here, so what we're doing is we're redesigning the way certificates work, but doing batch signing, which is called Merkle certificates. But this is all kind of cool stuff that we can dive into, but for the end, it doesn't matter. It's still as kind of a certificate that you need to install and your Lard needs to update. But all in all, that's what as a software developer you need to do, doesn't really change there. But then there's performance, but then there's also the second thing, which is protocol ossification. Which is that even though that TLS has been designed to be flexible, to allow multiple signatures, to allow small keys, large keys. In practice, when the flexibility in the protocol is not used, the joint ossifies, so to say.

• 27:05Speaker 02

  So we saw this actually with the migration to post quantum key agreement, which is already running now. That's also larger, it's one kilobyte instead of 32 bytes. And so the first flight in the TLS connection, you always used to be just one packet, and now it's two packets. And 99% of the cases, that is completely fine, but we found that in 1% of the cases, it just wouldn't work, it would break. And the causes would vary, it's some middle boxes, some firewalls, like firewalls. Also some load balancers couldn't do it, so it's very bit. So it took, the path here was just slowly roll it out until somebody complains.

• 27:47Speaker 01

  Yeah, yeah.

• 27:48Speaker 02

  Now we, Jen, hold it, ramp it up some more, and in the end, we got there. So that's another problem, protocol ossification. But the funny thing there is, is that I think it was a while back where Chrome was at 10%. So we, at Cloudflare, we enabled it for all zones, and Chrome was at 10%, everything was looking good. And then they ramped up to 100%. So 10% of all Chrome clients were running. Using key agreement, key key agreement, all the time, then they ramped up to 100%. You would think that if you have an organization where 10% of the users with Chrome doesn't work for a reason, that they would report it. But no, ramping of 10% to 100%, there were a bunch of new bug reports of organizations where only until literally everybody's Chrome was not working,

• 28:33Speaker 02

  then only a complaint came in.

• 28:35Speaker 01

  I'm guessing a lot of this is that, well, it works for me, Chris, right? Somebody might have experienced it, filed it to their IT, their IT is like, hey, it's working for me, it's fine.

• 28:43Speaker 02

  With this, I don't want people to take away that there could be problems, because these problems are actually rare. So that's one. But another thing is, you only figure out these problems by trying it.

• 28:54Speaker 01

  Absolutely, yeah.

• 28:55Speaker 02

  It's really hard to predict. Just try it and see.

• 28:58Speaker 01

  Before we move on from this, one quick question about on the performance side. So we talked about the increased size of the keys, thinking particularly about places where we embed cryptography in small devices. What's the computational requirement look like? Is it substantially more overhead there?

• 29:14Speaker 02

  So that's actually a funny thing. So you think big key means slow, but that's actually not the case. I mean, if the network is the bottleneck, then key is a problem. But computationally, it's actually very light. The computations involved in network-based cryptography are actually typically faster than elliptic curves, which are already known for their speed.

• 29:33Speaker 01

  Interesting. Okay.

• 29:34Speaker 02

  Yeah. With embedded devices, though, there is the thing that gets them is not necessarily the computation, but it's the memory requirement.

• 29:42Speaker 01

  Yeah.

• 29:42Speaker 02

  So for elliptic curves, you only need something like not more than 200 bytes of RAM to compute with them. But with ML-CAM, which is the Post Quantum Key Agreement, you do need about 5 kilobytes of RAM, which is for some devices a problem, for some devices.

• 29:59Speaker 01

  Yeah, for sure. Not usually an issue over in our web world on laptops. But yeah, I've been playing with embedded recently and suddenly all these limitations are real again.

• 30:08Speaker 02

  Definitely, yeah.

• 30:09Speaker 01

  Okay, so let's talk a little bit more about timelines and roadmaps. My impression is we'd all been sort of operating under the assumption that Q-Day was far away and we were mostly worried about the harvest now, decrypt later. What does the timelines look now? Because we've seen, it was, Google was the big one that caught my eye, but I think there have been a flurry of shifts in terms of projections of when Q-Day is going to happen. And so like, yeah, what are we looking at and what is the roadmap to being ready?

• 30:40Speaker 02

  So ever since I started working in this field, it always felt far away. And it was always like, yeah, probably somewhere after 2035. And one thing to understand is that there's not one approach to quantum computing. There are multiple different approaches. You have the silicon-based, the transmon, ion trap-based, neutral atom-based, photonics, all kinds of different approaches. And each of these approaches, they have their own list of challenges. 10 years ago, the list of challenges was so far, the question was, is even one of them going to make it, right? Then over the, over the years, they, each of them, they, they, none of them fell away.

• 31:22Speaker 02

  They all kept hanging around and most of them put also on the frontier. But still, everyone, the, yeah, 2035, yeah, yeah, seems, it became a kind of a magic number. And also, a lot of regulators started to standardize on, with deadlines between 2030 and 2035, or typically 2030 was for the, for the more critical things and 2035. But there's a mix between 2030 and 2035 on regulatory deadlines. So for that fault, I'll still reasonably comfortable. That is until just the last few months. What happened is that, to understand progress on quantum computing, it's actually three

• 32:05Speaker 02

  layers, it's three fronts where progress compounds. So you have the hardware, how far along is the actual physical device that runs it? But these physical devices, these are all analog, they are like noisy. So each quantum bit, each qubit, it's, it's not perfect in an actual device. Some approaches have them inherently better than other approaches, but still, none of them are perfect. And for any real computation, you need to do what is called quantum error correction. And that's the, the second layer, the second front on which progress can be made is Which error correcting codes do you have and can you use on your quantum computer? And the third front of advances that can be made is on the algorithm itself.

• 32:49Speaker 02

  I mean, you know that if you do a first attempt at implementing some algorithm, might not be the fastest way to get to some, and if you have a three expert that does something in assembler, it can be quite a bit faster. Again, so with quantum computers. So what we've seen, so when we originally started, we thought we would need about 200 million physical superconducting qubits to break RSA 2048, 200 million. Then over the years, it was whittled down to 20 million. Now 1 million with just a superconducting qubits. And then there came out a paper, just recent leaf of Google, which said, oh, actually, these elliptic curves, these can also be cracked very efficiently.

• 33:32Speaker 02

  They only require on superconducting only about 200,000. And then that's, so that was one, we have a, there's a much more efficient way to attack elliptic curves, which makes it a lot smaller. But then another thing is, is that, so that was a Google's paper where the salient thing is, is that they didn't publish the algorithm. The only thing that they did, this is starting to get dangerous. We're not publishing the algorithm. We're only publishing a, what is called a zero knowledge proof, that we actually know the algorithm.

• 34:01Speaker 01

  Fascinating, yeah.

• 34:03Speaker 02

  I'm happy they told us they made improvements.

• 34:06Speaker 01

  It's honestly reminiscent of what's going on in the AI space too, where it's like, we're not going to make our newest models public. We're just going to crack all sorts of security issues and bring people in on that. Similarly here, it's like, oh yeah, we have the ability now. You better get ready. We're not going to make that available because somebody will use it, but here you go.

• 34:26Speaker 02

  So that's on the algorithm side. But then there's also the

• 34:28Speaker 01

  The middle there, yeah.

• 34:30Speaker 02

  So the top is already shrinking a lot. The middle is the error correcting codes. And there has been tremendous progress there as well. And in particular of a startup called Oratomic. They show that if you have a particular kind of quantum computer, it doesn't work with everyone. It works with neutral atoms. It works with ion trap, what they call reconfigurable. It's where you can move qubits around. So with silicon, they're basically locked in place. You can only do neighboring interactions. Whereas with the reconfigurable, with the neutral atoms, you can move them around. And if you can move them around, you can do non-local error correcting codes. There they show that you only need 10,000 physical qubits to break P256's electron curve.

• 35:10Speaker 01

  Whoa, whoa, whoa. So if I'm hearing you correctly, they got a 20x improvement of mapping from physical qubits to logical qubits?

• 35:17Speaker 02

  Yeah.

• 35:18Speaker 01

  Wow.

• 35:19Speaker 02

  That's another improvement. Actually, the 10,000 number is a caveat. It needs to run for, to actually run it to break the key, it requires something like a month or so or two. So probably you would require something like 20,000 to do it in a more reasonable time.

• 35:35Speaker 01

  I mean, what's the projected classical time to break one of these keys, right?

• 35:39Speaker 02

  Practically infinite, right? I mean.

• 35:40Speaker 01

  Right. So a month is pretty good, but yeah.

• 35:45Speaker 02

  And then the hardware side, where if you look at each of these approaches, they're hammering away at their challenges, right? And each of them still has their big engineering challenges to solve. But at the moment, you really have to believe now that every single one of them hits a wall to not believe that it's coming. And especially the neutral atom one, which was a bit of a black sheep. It wasn't really on anyone's radar until recently. Because in the longest time, they didn't even, weren't even able to trap a single neutral atom. Now they have grids of like 6,000 neutral atoms. Not a computer yet. It's 6,000, I mean, 6,000, 10,000, 6,000, 10,000. It's a grid of 6,000 neutral atoms that they can trap.

• 36:29Speaker 02

  But it's not a functioning computer yet. It's not that you can do actually all the operations. But they have shown how to do each of these engineering, how to solve each of these engineering challenges have been solved separately. So now it's about integration. As we know, I mean, the integration is hard work. There's a lot of work there.

• 36:47Speaker 01

  But 2035 is looking a little overly optimistic, is what you're saying.

• 36:52Speaker 02

  We cannot exclude the possibility that we see one in 2030 already, or earlier. 2029 even, maybe 1% chance.

• 37:01Speaker 01

  Google put a date on it, right? They are like, we think that you've got to be ready by 2029.

• 37:06Speaker 02

  Google says, we are going to be ready by 2029. That's our target as well. We are going to be fully post-quantum secure by 2029. Yeah, because it's starting to get incredibly uncomfortable.

• 37:18Speaker 01

  So let's talk then about what it takes to get to that full post-quantum security. What does, we talked about the sort of key exchange piece. You've already got that rolled out quite a bit. We talked about the need for the certificate authority and pieces on that. But like, how are you breaking apart these different pieces and the rollout? Walk me through what it takes to get there by 2029.

• 37:41Speaker 02

  Yeah, so this is a big project, right? It's not like a single push because it's, I mean, there are easy and hard cases, or easy, the straightforward cases. But even the straightforward case is first, you need to make sure that your internal CAS or actual CAS are there. You need to make sure, then you need to provision the new root certificates on the clients. Then you need to provision, of course, you need to update the servers, the software on the server and the clients to understand these new certificates. Then you need to provision the new certificates next to the old certificates on all of the servers. And then you're not done yet because installing post-quantum, adding support for it is not enough. You also need to turn off support for quantum vulnerable crypto. Otherwise, you have a domnet attack. And after that's all said and

• 38:24Speaker 02

  done, you probably also want to rotate all your secrets. So even though this is well understood, the steps here, but it's not one push. It's like maybe three, four pushes. It's a matter of years, not of months. So that's one. But at least there, the things are reasonably well understood. Software support is coming. So open SSL already has support for MLDSA, software support in other libraries certainly coming. That is really, the thing that is important now as well is to bubble up the hard cases, right? So cases where you put a jot into your URL. If that jot is using a post-quantum signature of one and a half kilobyte, that will break your URL, right? That's not going to work. headers, a lot of servers,

• 39:07Speaker 02

  even clients are not happy if your headers are chunky. Hardware dependencies, bespoke protocols. Something like WireGuard. WireGuard really uses that thing fit into single packets.

• 39:19Speaker 02

  That's not an easy upgrade either. There are some suggestions there. So one track is preparing just a straightforward case, and another track is trying to bubble up quickly these hard cases, the things that need actual tough decisions on how to proceed. And then there's a third track, which is dependencies, vendors, right? Because even though you can do anything, all right, if your vendor doesn't upgrade in time, well, what can you do?

• 39:43Speaker 01

  So because I've had to work with vendors before, that immediately puts me down the road of, well, we're not going to make it. What are the consequences? We get to 2029, and maybe you're like most of the way there, but you've got a few vendors that have not updated or something like that. What are the impacts? What are the cascades? What does this look like in the downside case?

• 40:01Speaker 02

  This is actually the exercise you can do tomorrow, right? Just assume we got it all wrong as already quantum computer. What happens? What's the impacts? What do we need to focus on now? That you can do, right? Because actually, usually it's because you can also, I love cryptography. I think we did a great job over the last decade to make encrypted, secure connections the baseline. And I really want to keep that. But to reduce the panic a bit, it's also important to start from what is the actual business continuity impact? If this happens, are there any mitigating circumstances? Can we detect if this happens? How can you solve this in different ways? I can't prescribe it will differ persistent system. Some of them you will discover, oh, I thought that wasn't bad, but it's actually really bad.

• 40:45Speaker 02

  And others you discover, uh, we can do some different things. We can fix things in different ways. We can, it wasn't load bearing, that can be one example. Maybe we can just put in a post quantum VPN or the like. Maybe we do design things. Maybe we replace it anyway, or we accept the risk, right? It's, there's a whole bunch of options. But it's really important to understand this top down, right? Because if you start bottom up, where you just make an Excel sheet of where are the keys? Well, that a key exists doesn't tell you what the key does, right? You need to know the context of what is this product? What is it trying to achieve? You need to have a top down understanding of the risk.

• 41:22Speaker 01

  What keeps you up at night looking at this?

• 41:25Speaker 02

  What doesn't? I like my car. I don't want to replace my car.

• 41:31Speaker 01

  I've long had a habit of calling smart devices surveillance devices because they even in a classical cryptography world, so many of them are so hackable. But cars and software controlled cars sound terrifying in a world where you can hack through them.

• 41:47Speaker 02

  Hopefully they'll just get a software update where they disable the software update or something like this when they shoot. So the thing is, in a way, let me end with a more positive note, right? Because data leaks are not new. Every once in a while, a huge amount of data is leaked. And also adversaries gaining access to systems where they shouldn't and roaming around and extortion. That's also an everyday occurrence. So we know how security teams around the world know how to deal with this. They're trained to deal with this and how to work around it. The only thing is that's really important is that the difference is with quantum, it will come all at once. Right? And in a way, Mythos is like a preview where the rate of explodes is going up.

• 42:30Speaker 02

  Luckily with Mythos, it can only find errors and bugs that were already in the software, right? It's not going to find something errors that are on there. But with quantum, it will come all at once. So it's don't panic, but I mean, at least get started early enough.

• 42:42Speaker 01

  Yeah, for sure. Awesome. Well, we're getting close to the end of our time. Is there anything we haven't talked about that you think would be good to leave our listeners with?

• 42:51Speaker 02

  Just get started with updating your life. I mean, probably the biggest part of the work will be just the usual things. Updating a library that's been, you've been using a library from 2011. Just the basic things and most cases it will be relatively set forward. So.

• 43:07Speaker 01

  If you're in a big bank that's still on mainframes using Cobol.

• 43:12Speaker 02

  Actually, banks, the financial sector is one of the branches that has been very much on top of EQ for a long time. At least the banks I see at conferences. So.

• 43:21Speaker 01

  Yeah.

• 43:21Speaker 02

  And last worry, also does this funny thing where if your system is old, it's hard to upgrade. You're in trouble, but if it's old enough, it uses symmetric cryptography again, which doesn't.

• 43:33Speaker 01

  Right, right.

• 43:34Speaker 02

  There's a sweet spot.

• 43:37Speaker 01

  That's hilarious. Awesome. Well, thank you. Appreciate it. This is super educational for me and it'll be an interesting couple of years.

• 43:45Speaker 02

  Sure will be. Thank you. Great to be in there.