Preparing for Q-Day

Most of the cryptography securing the internet today rests on mathematical problems that classical computers cannot solve in any reasonable time frame. 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 Vesterbon 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 Balz 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 Bal, or K-Ball, 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 and 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. Boss, welcome to the show. Hey Kevin, nice to be here. 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? It's quite a whammy road.

I always liked security and cryptography at high school. I started to go study physics and mathematics, because I thought that would be more challenging. It didn't end up being very good at the physics, so I stuck with mathematics, at least I mean, the physicists didn't know how to bend the rules, right? And I don't know how to do that.

I did mathematics, then I did a PhD, going back to physics a little bit in 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, so as the people doing post-contem cryptographies there and the science is symmetric, so I kind of learned by Osmosis just during the coffee breaks and stuff after that I went for a post-doc to London. London has expanded itself, maybe I can find an internship or something, already some crypto engineering, so I via via ended up with an internship at Klassler and enjoyed that so much doing crypto engineering there that after Covid, I can't invite it to join full time in the Netherlands and I've been there ever since the beginning for the last few years, our efforts in migrating to post-contem cryptography. That's awesome, I actually also started in physics, I studied physics as an undergraduate and got away from it and then 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 this because 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 what are the problems that quantum computers create for cryptography? Yes, quantum computers, it's quite an old concept, even earlier than the 90s, rich at 5 on the famous physicists and some other folks proposed that you can use quantum computers to more efficiently simulate 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 emptinence, which is inefficient, but then they realize if you use quantum mechanics itself, the full power of it to actually do computations instead of just using 0s and 1s, you can actually compute them more efficiently, so that's all well and good, the physicist's toy with hopefully amazing applications in material science and stuff, but it's so positive until in 94, Peter Schor, mathematician, you 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 is 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. 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.

So it is two big groups of cryptography, symmetric cryptography which is a yes, shutout, that's mostly about jumbling bits, right, mix things up against so that they are become unpredictable, that's in a way it's a bit of a messy thing, but it's well understood that 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, not a course of a magical to make it work, and in the case of elliptic girls that's discrete logarithms and in case of rz 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 quantum computers is pretty easy and the problem is if you can sort a problem, if you can do a factor or a number easily, then you can also break the public key and from the public key to write a property, and maybe you 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. So if you make a connection and you do a deal a 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 other elliptic girls of rz and if that's broken then people who recorded the encrypted conversation can retroactively decrypt it and see data, so that's the famous harvest now decrypt letter, people can record encrypted sessions today and if they're not using post-ponded cryptography, cryptography designed to be secure against attack for the readers, then they can be decrypted in the future. So that's one. Yeah, and just to like even put it in broad terms, like that's every connection we have today, especially now everything's using HTTPS, if you're on the web, you're going and logging into Google, so you're banked to what have you, all of those at the root are doing TLS handshake, share 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. 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, we use a modern browser Chrome or Safari or Firefox, then that already tries to make a connection using post-quanted cryptography that is that's secure set against harvest now decrypt letter.

So that is good to dig into. So actually, first, what does it mean to be post-quantum cryptography? What is that? Yeah, so post-quanted cryptography is cryptography that's designed or we believe is secure against attack upon the computer.

So the funny thing is, this cryptography is typically already quite all so lattices, which is the front runner, I mean, there are many different types of post-quanted cryptography, hash-based cryptography, logistic cryptography, and the very best 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 attack upon computers, believe that sounds to be, 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, but let's discover if we secure an attack upon computers.

And if you use that, that's a best cryptography, then you're secure against this threat. So let's maybe really quickly talk about what that actually is because I think it's, I'm joking out on this, right? So we've talked about the two examples where you've got elliptic curves and computing things there using algorithms, 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? Yeah, so what is a lattice? So a simple example of a lattice, it's a simplified example of it. It's a thing 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 a thing about a parallelogram and then it just 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 a 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 getting a point that's very far away, 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 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. 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 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. Yes. Also, when they're close together, it's really hard to see how well things cancel out if you start adding and subtracting them. But actually, on the plane, you can only have something to run algorithm for it if you like, it's actually pretty easy to clear this out in the plane, right?

Because that's just two dimensions. It turns out that you do this in a space that has a thousand dimensions, it's not just x or y, but a thousand different directions. And this becomes computationally very, very hard. And that's the basis of less viscatory.

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 route, 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? So actually, do you know about Diffie-Hellman? The clock thing's only somewhat, why don't you explain it and then we can go with it. Diffie-Hellman is a classical, one that's basically a block where each of us starts with a secret number, A and B.

And we do this using modular earth netting. So it's like time on the clock. I have a secret B, you have a secret K, right? For government boss.

And you both agree on that 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. And you said two to the K to me, and I said 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 modulo prime, this is actually hard. This is called the discrete logarithm problem. Well, hard for us now with our puny classical computers with the quantum computer, it's easy.

Okay, so that's a public key to the B. It might be a key to the K, your public key. Now, you've got my public key to the B, and what you can do is you can exponentiate in your K. So you can do two to the B to the K, and I can do two to the K and I can exponent in B.

So two to the K to the B. And what we end up with is both of us end up with two to the B times K. So we both got the same shared number which we can use as a secret to then do a yes. So this is called the Fihamam.

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. 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. My colleague Chris Button, he wrote together a bit of travel of the desires, which can be brought down nice blog posts with this analogy explaining it's a work.

I really don't do it justice in fact. It's moving to another link to it. 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. That's bad news.

Okay. We're protected against harvest now. That's where I was going to 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. Yeah, so QDay. QDay is a day that we expect there will be a cryptographically relevant quantum computer.

One that's powerful enough to actually crack real keys, use the production. And if you think that QDay is far away, that is really about the harvest now, we get later on. That'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 QDay is far away, it's the half an hundred-click later, but we don't just need to fix the harvest under the glitter bit of it. We also need to fix the authentication, the certificates bit of it. Because just as we explained, we had this year's secret, it's two to the B to the K, which we can then use for a yes.

But we did this exchange. But how do I know that I'm actually talking to you, right? Yeah, yeah. How do you know that you're sending your secret to actual Kevin and not someone else?

Yeah, it might be someone in the middle who does this dance with me and with you separately and and then re-encrypts everything, right, that 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 send me a certificate signed by a certificate authority, which says, I'm Kevin, I am with your personal website. When you deal with it, the CA says, you can trust this public key for doing connections with this particular domain.

So key agreements ensure that you have a secure connection, you don't know with whom, and the certificates make sure that you're talking to the right person. Now, there's no deployment of post-quantum certificates today. It's all classical certificates. Which is fine.

Until QDay. Until QDay, right? Because QDay is not just about an active attack, right? Because QDay 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 stands, so it's hundreds authorities that trust it. A quantum computer just has to crack one of them and then can 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.

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. Well, not just men in the middle because that surely can be a man in the middle, but they don't need to be in the middle. They can just, if I crack a C-A key, I can create my answer different. I don't necessarily have to be in the middle.

It depends on what it is, right? I can, if I'm on a network, I don't even have to talk to an 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 tool. If you have a Tesla or some other car that does over the wire updates or other things. Yeah.

So last year, I bought a new second-hand car, which is new enough that it has a remote unlock and all this kind of jazz with all the other, you probably won't get any close quantum updates. I don't want to buy a new car, so that's probably, that's all, 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 zero.

Every software update mechanism becomes a remote code execution for quantum attackers. So what do we do? You mentioned for fighting against decryption for this by now, or harvests now decurplator. We have alternate approaches that we know work, that we've been deploying out through at least critical pieces of stuff, or browsers and things like that.

Do we know the answer? What does post quantum authentication look like? 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.

That's pretty good. Yeah, we want, of course we want higher, one 95%. 100%. I never get 100%.

95 would be nice. It's pretty good. Yeah. But that's, we turn it on in 2022 and it took until now to get to 65%.

But 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. Amazing what threats will do, right? Things move fast.

I mean, people start working when the deadline is near anyway, right? They'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 use and bad use here. I think like a lot of software development, there's a 90-10 world here, where in the vast majority of cases, it will not be a very difficult update. 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.

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 surface breach makes it hard and also buy it to start looking to even know what the deal is.

But luckily, probably if you just use modern stuff, then there will probably be reasonably straightforward. 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 that they're going to use post quantum authentication. 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 stiffness, 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 day, flip the switch. But if you have some kind of serious system, or maybe even just a few different teams in the 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 ability yet. So on the server side, that means that the server needs to be able to install both a traditional RZ or an easy certificate, but also post quantum certificates.

Oh, that's right. So it's not just the root certificate over the authority that needs like this actually needs to get deployed out to anyone with a web server, essentially. Yeah, of course, 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. Yeah, so hopefully a lot of people do certificate automation, right? So you don't do this certificate some of yourself, you get any some kind of client to do it for you.

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

I mean, it's something you can do today, right? Even though they're not post quantum certificates today, you get at least a certificate automation today. Yeah, another thing you can do is check whether your application server can actually install two certificates, a lot of these software is through just the one certificate, but not just one slot. Whereas you really need at least two slots here.

Although if it turns out it's really hard to get application service to move, we might need to define an ugly certificate from every squeeze in two certificates to do one. But let's hope we both need that. How bad would that be? Because I, you know, once again, having been burned before, I suspect there will be a long tale of application servers that are not going to be updating.

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, does that thing talk to you?

If you want to upgrade that, do we need to replace the whole thing? I mean, is it where do we really care if someone with a quantum computer can have free parking? 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.

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? I mean, yeah, it's working. It's fine.

Unless it's really broken, people don't really touch software, right? Cryptography. So, of course, it's good. Yeah.

So, okay, interesting. So let's dive a little bit more. So imagine you're in a world where you own some of the software, right? The 80%, 90%.

I'm just deploying new software. I'm not building the software. It's somebody else's job to make this accept too, 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 their bigger changes or their performance considerations?

Like, what does this look like? So the big things are common best practices, right? So I already mentioned, keep software libraries up to date, be able to start to stiff, get to stiff with automation if you can do it. So that's a general good advice you can do today.

On internal PQAs, you can already use it. If your software library supports it, then you can only use and deploy post-contents. So you can already do that today for internal networks, for public CAs, you have to wait until 2027. Now, the things that can go wrong, post-contents signatures are larger.

Inletive curve signatures, they're only 64 bytes. And because they were so small and fast, they use them basically everywhere. There we had a problem, we solved this next signature. 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. And MLDSA44, which seems to be the most commonly used post-contents signature, is if I'm reading the TLS correctly, that is two and a half kilobytes. Sending it six times per connection. Wow, yeah.

Okay. So we're looking at about 15 kilobytes from server to client on the handshake. As you go to YouTube, that doesn't really matter, right? If you go to YouTube, that doesn't matter in some other cases.

So there are two reasons. Performance, if you look at all the connections that are made with Cloudflare over a 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... We've tripled the payload.

Yeah. It means that half of the connections transfer three quarters of the just certificates instead of data. Actually, impact is also still, and using 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, so to be able to run on by default, we need to have them on complain about performance. We do have tricks here. So what we're doing is we're redesigning the way certificates. We're doing batch signing, which is called local certificates.

But there's all kind of cool stuff we can dive into, but for any other data, it doesn't matter. It's still a certificate that you need to install any large units of dates. But all in all, that's what software development you need to do doesn't really change there. But then it's performance, but then that's also the second thing, which is protocol authentication, which is that even though the TLS has been designed to be flexible to allow multiple signatures, to allow small keys, large keys, in practice, when the flexibility of the protocol is not used, the joint also flies.

So we saw this actually with the migration to post-comparement, which is already running now. That's also larger. It's one kilobytes 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, that we found that in 1% of the cases, it just went in for a break. And the causes would vary. Some middleboxes, some firewalls, like firewalls, also some load balancers could do it. So it's very good.

So the path here was just slowly running out of some body complaints. Now we can hold it, rev it up some more. And in the end, we got that. So that's another protocol authentication.

But the funny thing there is, is that it was a well-begged where Chrome was at 10%. So at the last time, we enabled it to follow zones, and Chrome was at 10%, everything was looking good. And then it ran up to 100%. So 10% of all Chrome clients were already using PQK or with all time, then it ran up to 100%.

You would think that they have an organization where 10% of the users with Chrome doesn't work for a reason that they would report us. But no, ramping up to 100%, there were a bunch of new bug reports of organizations where only until literally everybody's Chrome was not working, then only a complaint came in. I'm guessing a lot of this is that well, it works for me. Great.

So I experienced it, filed it to their IT. They're IT. It's like, hey, it's working for me. It's fine.

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

It's really hard to put things in. Just try it and see. Before we move on from this one quick question about the performance size, 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? So that's actually a funny thing. So you think making it slow, but that's actually not the case. I mean, if the network is the bottleneck, then the key is a problem.

But computationally, it's actually very light. The computations involved in the network is actually typically faster than the end to curse, which are already known for their speech. Interesting. With embedded devices, though, there is the thing that Gatston is not necessarily in the competition, but it's the memory requirement.

So for a little curve, you only need something like not more than 200 bytes of RAM to compete with them. But with MLK, which is the post-concavion, you do need about five kilobytes of RAM, which is for some devices a problem for some of those. Yeah, for sure. Not usually an issue over in our web world on laptops, but I've been playing with embedded recently.

And suddenly, all these limitations are real again. Yeah. 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 QDay was far away, and we were mostly worried about the harvest now to be a creplator. What does the timelines look now? Because 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 QDay is going to happen. And so, yeah, what are we looking at and what is the roadmap to being ready?

So ever since I started working in this field, I always felt far away. And I was 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 trans one, ion-trapped-based, neutral atom-based, photonics, all kinds of different approaches. And each of these approaches, they have their own list of challenges. Ten years ago, the list of challenges was so far. The question was, is even one of them going to make it right?

None over the years, each of them, none of them fell away. They all kept hanging around, and most of them could also on the frontier. But still, everyone, they were at 2035, yeah, yeah, it 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, but typically 2035 was for the more critical things in 2025.

But it doesn't make between 2030 and 2035 on regulatory deadlines. So that falls also reasonably comfortable. That is, until just the last few months. What happened is that, to understand progress on quantum computing, it's actually three 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, analog, they are noisy. So each quantum bit, each qubit, it's not perfect.

And actually, by 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 second layer, 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. 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 to react for the rest of things and assemble, 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. And over the years, it was down to 20 million, now 1 million, with just a superconducting qubit. And then there came out a paper just recently of Google, which said, Oh, actually, this, it occurs.

These can also be correct very efficiently. They only require a superconducting only 200,000. And then that's what was one we have a there's a much more efficient way to attack electric curves, which makes it a lot smaller. But then another thing is, is that was a Google's paper where the salient thing is, is that they didn't publish the algorithm.

Only thing that they did is starting to get dangerous. We're not publishing algorithm. We're only publishing a what is called zero knowledge proof that we actually know that fascinating. Yeah, I'm happy they told us they made improvements.

It's honestly reminiscent of what's going on in the AI space to where it's like we're not gonna 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. So there's an algorithm. So there's also the middle there. Yeah, the top of these freaking lots.

The middle is the error correcting codes. And there's tremendous progress to there as well. And in particular, of a startup called orthomic, they show that if you have a particular kind of on the computer, it doesn't work with a neutral atom, it works with an iron trap, what they call reconfigurable is where you can move qubits around. So with silicon, they're basically lots of data, and we have different characters, whereas with the reconfigable with the neutral atom, you can move them around.

And if you can move them around, you can do non-local error correcting codes. They only show that you only need 10,000 physical qubits to make p2,5,6 elliptic curve. Whoa, whoa, whoa. So if I'm hearing you correctly, they got a 20x improvement of mapping from physical qubits to logical qubits.

Yeah. Wow. That's another improvement. Actually, the 10,000 number is a caveat.

It needs to run for especially running 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. I mean, what's the projected classical time to break one of these keys, right?

Practically infinite, right? So a month is pretty good. But yeah. And then the hardware starts where if you look at each of these approaches, they are 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 more believe that it's coming. And especially the neutral atom one, which was a bit of a black sheet that wasn't really on an end-one's radar until recently, because in the longest time, they didn't even weren't able to trap a single moveable atom. Now they have grids of like 6,000, 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, it will atom today can trap. 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 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.

But 2035 is looking a little overly optimistic is what you're saying. We cannot exclude the possibility that we see one in 2030 already. It's or earlier. 2029 even maybe 1% terms.

Google put a date on it, right? They are like, we think that you've got to be ready by 2029. Google says we are going to be ready by 2029. That's our target as well.

We're going to be free for the first column secure by 2029. Yeah, because it's starting to get incredibly uncomfortable. 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 kick 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 walking through what it takes to get there by 2029? Yeah. So this is a big project, right?

It's not like a single push, because it's, I mean, that easy in the hard cases or easy the straightforward case. But even the straightforward case is first, you need to make sure that your internal 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 and the clients to understand this new certificate.

Then you need the provision, the new certificates next to the all certificates on all of the servers. And then you're not done yet, because installing post-content editing sports, right, is not enough. You also need to turn off support of quantum funneling crypto. Otherwise, you have a dominant attack.

And after that's all set and done, you probably also want to build it 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 a month.

So that's one that at least there, the things are reasonably well understood. Software support is coming. So OpenSL already has support for MLDSA, software support and other libraries, certainly coming. That is really the thing that is important now as well.

It's the bubble of the hard cases, right? So cases where you put a jot into your URL, if that jot is using a post-con signature of one of our skill about double-radio URL, right? That's not going to work. Headers, a lot of servers, clients are not happy if your headers are chunky, hardware dependencies, bespoke protocols, something like WireGuard.

WireGuard really uses that things fit into single packets. That's not an easy update 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, right?

The things that need actual tough decisions on how to proceed. And then there's a third track, which is dependencies, with antennas, right? But even though you can do anything, all right? If your phone doesn't, everything time else, what can you do?

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. 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? This is actually the exercise you can do tomorrow, right?

Just assume we got it all wrong. It's already quantum computer. What happens? What's the impact?

What do we need to focus on now? That you can do, right? Because actually, usually, because you can also, I love cryptography. I think we did a great job of the last decade to make encrypted secure connections in the baseline.

And I really want to keep that. But to reduce the panic of it, 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 we solve this in different ways? I can't describe it with a different system. Some of them you will discover, oh, I thought it wasn't bad, but it's actually really bad. And others really discover, we can do some different things.

We can fix things in different ways. We can, it wasn't not bearing that can be one example. Maybe we can just put in a post-pontum VPN or the like, maybe we do design things. Maybe we replace it anyway, or we accept the risk, right?

It's a whole bunch of options. It's really important to understand this stop down, right? Because if you start bottom up, where you just make an excel sheet of where are the keys, the 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 top down understanding of the risk. What keeps you up at night looking at this? What doesn't? I like my car.

I don't want to replace my car. 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. Hopefully they'll just get a software update, very disabled software update or something like this. So the thing is, in a way, let me end with them up positive.

Not bad because data leaks are not new. Everyone's in a while, a huge amount of data is leaked. And also, adversaries gaining access to systems that they should learn and running 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 in once, right? In a way, mythos is like a preview where the rate of excellence is going up, largely with mythos, it can only find errors and bugs that are already in the software, right?

There's not going to find something errors that are done on there, but with quantum it will come all in once. So it's don't panic, but at least we get started early enough. 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? Just get started with updating your life. I mean, probably the biggest part of the work will be just the usual things.

Updating the library that's been using the library from 2011, just the basic things. And most cases it will be relatively central. If you're in a big bank that's still on main frames using Coball, actually banks, the financial sector is one of the branches that has been very much on top of EQ for long time. At least the banks I see at conferences.

So that's very there. Also, there's this funny thing where if your system is all this hot, okay, I'm in trouble, but if it's old enough, it uses some other controls here. Right, right. This is sweet stuff.

That's hilarious. Awesome. Well, thank you. Appreciate it.

This is super educational for me, and it'll be an interesting couple of years. Sure will be. Thank you. Great to be in there.