Preparing for Q-Day

Summary

Podcast Summary: "Preparing for Q-Day"

Show: Software Engineering Daily
Date: June 16, 2026
Host: Kevin Ball
Guest: Bas Festerbahn (Cryptography Engineer, Cloudflare)

---

Episode Overview

This episode dives into the looming threat posed by quantum computers to internet cryptography, the race to transition to post-quantum algorithms before a "Q-Day" when quantum computers can break current encryption, and practical advice for software engineers preparing for this seismic shift. Bas Festerbahn, who leads Cloudflare’s post-quantum migration, explains the math and mechanics behind post-quantum cryptography, discusses recent advances that have compressed threat timelines, and outlines actionable steps and roadmaps for organizations and individual engineers.

---

Key Discussion Points and Insights

1. The Quantum Threat to Cryptography

• Quantum computers leverage superposition and entanglement, giving them the potential to solve certain problems—like factoring large numbers—much more efficiently than classical computers.
  • “If a quantum computer is actually built that's big and powerful enough, then most of the cryptography falls away.” (Bas, 04:30)
• Peter Shor’s algorithm (1994) showed that quantum computers could solve factoring and discrete logarithms efficiently—core assumptions behind RSA and Elliptic Curve Cryptography.

2. Symmetric vs. Asymmetric Cryptography

• Symmetric cryptography (e.g., AES, SHA-2): Still secure against quantum attacks.
• Asymmetric/public key cryptography (e.g., RSA, Elliptic Curves): Vulnerable due to quantum computers’ ability to efficiently solve the problems they rely on.

3. What Is at Stake: Harvest Now, Decrypt Later

• Harvest Now, Decrypt Later: Attackers can capture encrypted traffic today and decrypt it in the future when quantum computers arrive, especially if the handshake (key agreement) wasn’t quantum safe.
  • “If they're not protected using post quantum cryptography...they can be decrypted in the future.” (Bas, 06:31)
• Critical Use Cases: TLS handshakes, banking, confidential conversations, software supply chain and updates.

4. Modern Protections and Post-Quantum Cryptography

• Migration in Progress: Modern browsers (Chrome, Firefox, Safari) already attempt post-quantum key agreements in web traffic.
  • "By default, if you use a modern browser...that already tries to make a connection using post quantum cryptography." (Bas, 07:52)
• Post-Quantum Cryptography: Cryptographic algorithms believed to be secure against quantum attacks.
  • Lattice-based cryptography is the front-runner due to lack of known efficient quantum attacks against it.

5. Lattice-Based Cryptography Explained

• Lattices involve multi-dimensional grids. The cryptographic challenge relies on the computational infeasibility of finding the closest vector in a high-dimensional lattice (the "bad basis" problem).
  • “In a space that has a thousand dimensions... this becomes computationally very, very hard. And that's the basis of lattice based cryptography.” (Bas, 10:58)
• Comparable to Diffie-Hellman: Both parties share public information and secret information to derive a shared secret, but with added noise and higher-dimensional math.
  • For a more detailed explanation, Bas recommends Chris Patton's and Peter Schwabe’s blog post. (13:53)

6. Gaps in Current Coverage

• Key agreement (handshake): Many clients already use post-quantum, but not all.
  • "More than 65% already are protected." (Bas, 18:36)
• Authentication and Certificates: No deployment yet of post-quantum certificates; classical certificates remain a vulnerability until Q-Day.

7. The Q-Day Scenario

• Q-Day: The day a quantum computer can break real-world cryptographic keys.
• Main concern: If certificate authorities (CAs) get compromised, attackers could forge certificates and impersonate services, enable man-in-the-middle attacks, or push malicious software updates.
  • “Quantum computer just has to crack one of them and it then can create a certificate trusted by basically any browser...” (Bas, 16:26)

8. Roadmap & Timelines

• Timeline advances: Recent breakthroughs in quantum hardware, error correction and algorithms have massively reduced estimates of the qubit count needed to break commonly used public keys.
  • "When we originally started, we thought we would need about 200 million physical superconducting qubits to break RSA2048... now... only 10,000 physical qubits to break P256 elliptic curve." (Bas, 35:59, 37:26)
• Updated Industry Target:
  • “Google says we are going to be ready by 2029. That's our target as well.” (Bas, 39:22)
• Immediate Steps:
  • Standardization and deployment of post-quantum certificates begin Q1 2027 (Chrome’s timeline).

9. What Software Engineers Should Do

• Actionable Steps:
  • Upgrade libraries and keep software up to date.
  • Automate certificate management (ACME clients, etc).
  • Check that servers can handle two certificates (traditional and post-quantum).
  • Start auditing dependencies and assets, especially for cryptography baked into hardware, old/legacy systems, and bespoke protocols.
  • "You can do certificate automation today." (Bas, 24:18)
  • "Check whether your application server can actually install two certificates." (Bas, 24:44)
• Performance/Resource Concerns:
  • Post-quantum signatures/certificates are much larger (2.5 KB vs 64 bytes for ECC); could potentially slow handshakes, bloat network payloads.
  • Embedded devices may not have enough RAM (5kB needed for some operations vs 200 bytes for ECC).
• Protocol Ossification Risks:
  • Some networking elements (firewalls, proxies, load balancers) may break with larger payloads.
  • Only discoverable by real-world testing and rollout.
  • “You only figure out these problems by trying it. It's really hard to predict. Just try it and see.” (Bas, 30:58)
• Hard Cases: Old hardware, supply chain, legacy systems, and protocols with size assumptions (e.g., Wireguard, JWT-in-URL) require special attention.

10. Business Continuity and Risk Assessment

• Top-down approach: Analyze real-world business impact if a quantum-break happens; understand which systems are truly at risk and prioritize updates accordingly.
  • “It's really important to understand this top down, right? Because if you start bottom up... you need to know the context of what is this product, what is it trying to achieve?” (Bas, 43:04)
• Pragmatism: For some old systems, symmetric cryptography may already be in use, which is less threatened.

---

Notable Quotes & Memorable Moments

• On new urgency:
  • “It always felt far away. And then just the last few months...ten years ago, the list of challenges was so far...now it's about integration.” (Bas, 32:56-38:07)
• On bad upgrades:
  • “I don't want people to take away that there could be problems because these problems are actually rare...but another thing is you only figure out these problems by trying it.” (Bas, 30:58)
• On the reality of rollout:
  • “We can't have the slow movers hold back the fast movers.” (Bas, 25:19)

---

Timestamps for Key Segments

| Timestamp | Segment & Topic | |----------------|---------------------------------------------------------------------------------------------------------------------------| | 03:48 – 05:09 | How quantum computers threaten asymmetric cryptography | | 07:20 – 08:14 | Impact on web security; “Harvest now, decrypt later” explained | | 09:08 – 12:02 | Lattice-based cryptography and Diffie-Hellman analogy | | 14:22 – 18:33 | Partial protection via browsers; authentication and post-quantum certificates lagging | | 23:08 – 25:09 | Roadmap: Dual certificates and deployment logistics | | 26:47 – 32:16 | What software engineers need to do; performance and protocol ossification challenges | | 32:56 – 39:08 | Advances in quantum algorithms and hardware; timeline update; skepticism on 2035 as Q-Day | | 39:56 – 41:59 | Steps to full post-quantum security; understanding hard problems and dependencies | | 43:38 – 45:07 | Business continuity and assessing real risk; advice for practical preparation | | 45:27 – 45:54 | Banks, mainframes, and the (sometimes lucky) quirks of old cryptographic deployments |

---

Final Takeaways

• Start now: Begin the migration and auditing process early; the long tail of old hardware, legacy software, and fossilized protocols will take time to flush out.
• Most organizations: Keeping software/libraries up to date and automating certificates will cover the vast majority of cases.
• For edge cases: Deep dives and vendor engagement are needed.
• Overall message: Don’t panic, but don’t delay—serious, actionable preparation for the quantum transition is essential.

---

“Just get started with updating your life...most cases it will be relatively straightforward.”
— Bas Festerbahn [45:07]

Transcript

[Narrator]

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. Bas Festerbahn is a cryptography engineer at Cloudflare, 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, 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 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.

[Kevin Ball]

Bas, welcome to the show.

[Bas Festerbahn]

Hey Kevin, nice to be here.

[Kevin Ball]

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?

[Bas Festerbahn]

It's quite a windy road. I always liked security and cryptography at high school. Decided to go study physics and mathem because I thought that would be more challenging. Didn't end up being very good at the physics so I stuck with the mathematics at least. I mean the 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 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 there's the, there's people doing post quantum cryptography there and designs of symmetric cryptography. So I kind of learned by osmosis just during the. 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.

[Kevin Ball]

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. So let's talk a little bit about quantum security, quantum cryptography and all of 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 like, what are the problems that quantum computers create for cryptography?

[Bas Festerbahn]

Yeah, so quantum computers, it's quite an old concept, even earlier than the 90s, Richard Feynman, the famous physicist and some other fol post 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 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 computed more efficiently. So that's all well and good. The physicist toy with hopefully amazing applications in material science and stuff. But so it was all positive until in 94, Peter Shor, a 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.

[Kevin Ball]

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.

[Bas Festerbahn]

So you have these two big groups of cryptography Symmetric cryptography, which is AES shatu, 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, something 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. 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 derived private key. 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 Tila's 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 ellipticals 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 letter. People can record encrypted sessions today. And if they're 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, yeah.

[Kevin Ball]

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 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.

[Bas Festerbahn]

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.

[Kevin Ball]

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

[Bas Festerbahn]

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 lattices, which is the front runner, I mean there are many different types of post quantum cryptography. You have hash based cryptograph, lattice based cryptography, Sogny based cryptography, multivariate 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 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.

[Kevin Ball]

So let's maybe really quickly talk about what that actually is because I think 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?

[Bas Festerbahn]

Yeah, so what is a lattice? So a simple example of a lattice, it's simplified example of a 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 and then 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 the 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, 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.

[Kevin Ball]

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.

[Bas Festerbahn]

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 lightning a speedup, 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 let's based cryptography.

[Kevin Ball]

So I'm going to use the example the multiplication and factoring, because that one I understand personally more than I understand the elliptic curve1. 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?

[Bas Festerbahn]

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

[Kevin Ball]

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

[Bas Festerbahn]

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 the clock. I have a secret B, you have a secret K. Right, for Karen and boss and you 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 2 to the K and you send 2 to the K to me. And I send 2 to the B to you. Going from 2 to the B, figuring out, I mean, if it's normal numbers, it's easy to take a logarithm. If you see 2 to the B to then see what is B. But if you do this modular prime, this is actually hard. 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. My public key 2 to the K is your public key. Now you've got my public key two 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 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. Right. So we both got the same shared number which we can use as a secret to then do AES. So this is called diffie Helman. And with lattices you kind of do the same, but then with adding a lot of noise. So it's like a noisy version of

[Kevin Ball]

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.

[Bas Festerbahn]

My colleague Chris Patton, he wrote together with Peter Schaber, 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.

[Kevin Ball]

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 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.

[Bas Festerbahn]

That's bad news.

[Narrator]

Almost.

[Bas Festerbahn]

Okay, we're protected against harvest now decrypt.

[Kevin Ball]

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.

[Bas Festerbahn]

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, gkup 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, you get later. But we don't just need to fix the harvest, decrypt 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 as 2 to the B to the K, which we can then use for AES. But we did this exchange. But how do I know that I'm actually talking to you, right?

[Kevin Ball]

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

[Bas Festerbahn]

Yeah, it might be someone in the middle who does this dance with me and with you separately and then re encrypts everything. Right. The 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 what's your personal website in tls? The CA says you can trust this public key for doing connections with this particular domain. So key agreements ensures 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.

[Kevin Ball]

Yeah.

[Bas Festerbahn]

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

[Kevin Ball]

Until Q day.

[Bas Festerbahn]

Yeah, until Q day.

[Kevin Ball]

Right.

[Bas Festerbahn]

Because commqday is not just about an active attack. Right. Because commqday 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 it 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.

[Kevin Ball]

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.

[Bas Festerbahn]

Not just men in the middle, because 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. 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.

[Kevin Ball]

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

[Bas Festerbahn]

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. 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 zero day. Every software update mechanism becomes a remote code execution for quantum attackers.

[Kevin Ball]

So what do we do? You mentioned for fighting against decryption for this buy now or 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?

[Bas Festerbahn]

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 are protected. I mean that's, that's pretty good. Yeah, of course we want higher. We want 95%, 100%. Ideally we never get to 100%. 95 would be nice, but it's pretty good. Yeah, but we turned that on in 2022 and it took until now to get to 65%. 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.

[Kevin Ball]

Amazing what threats will do, right? Yeah, yeah, yeah, yeah, yeah, yeah.

[Bas Festerbahn]

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, and 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 9010 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. 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, which makes it hard and also by its urgent to start looking to even know what the deal is. But luckily, probably if you just use modern stuff tls, it will probably be reasonably straightforward.

[Narrator]

Every AI team eventually hits the same wall. The models are solid, the infra is solid, but the data coming in is hours old because the pipeline is batch when it should be streaming and nobody's had time to fix it. That's not a modeling problem, that's a pipeline problem. Estuary gives you CDC batch and streaming in one platform. 200 connectors live in hours, not weeks. Your AI is only as good as your pipeline. Estuary.dev you know fidelity is a financial services leader, but did you know that inside Fidelity is a community of technologists working together to shape the future of finance and tech. Fidelity is always investing in tomorrow. From emerging tech to cutting edge tools that will transform what comes next. Their technologists are encouraged to keep learning so they can expand their skill sets, explore new ground and stay ahead of this rapidly evolving industry. And right now, Fidelity is hiring technologists to join their team. Fidelity technologists get the best of both worlds. Startup energy that's grounded in the stability of a financial institution. That means support, resources and amazing benefits. Bring your skills to a culture where you're empowered to dream big and build the tech that drives an organization and makes a real impact on people's lives. Find out [e-mail] that's tech.fidelitycareers.com Fidelity is an equal opportunity employer.

[Kevin Ball]

If you're running Postgres in production, you've probably felt the moment analytical queries start fighting your transactional workload. Most teams end up adding a second database and all the pipeline complexity that comes with it. Tiger Data, creators of TimescaleDB, takes a different approach. We extend Postgres with hybrid row and columnar storage. So one table handles both writes and analytical scans. Native compression cuts storage costs up to 95%. Continuous aggregates keep dashboards live without bash jobs, and it scales to petabytes without you re architecting. Companies like Cloudflare, Octave Energy, Schneider, Axpo and Flowco run production workloads on Tiger Data today. No stale data, no second system to operate, just Postgres managed for you. Ready for the workload you're building toward. Try it [e-mail] so let's start with the straightforward ones and then we can like dig our way down into the deeper one One. 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.

[Bas Festerbahn]

Yeah, so Chrome already announced their roadmap on when they will accept post quantum certificate authorities and they will start accepting them in 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 day, 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. So on the server side that means that a server needs to be able to install both a traditional RRSA or an ECC certificate, but also a post quantum certificate.

[Kevin Ball]

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.

[Bas Festerbahn]

Yeah, yeah, of course it makes sense,

[Kevin Ball]

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.

[Bas Festerbahn]

Yeah. So hopefully a lot of people do certificate automation, Right. So you don't do this certificate installer yourself. You get Acme, some kind of ACME client to do it for you. So hopefully that's easy.

[Kevin Ball]

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 hosting servers are already using like Acme. I don't know.

[Bas Festerbahn]

I mean, it's something you can do today, right? So even though there are no post quantum certificates today, you can at least do certificate automation today.

[Kevin Ball]

Yeah.

[Bas Festerbahn]

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.

[Kevin Ball]

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.

[Bas Festerbahn]

Oh, for sure, for sure. That's the reality, right? We can't have the slow movers hold back the fast movers.

[Narrator]

Right.

[Bas Festerbahn]

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 talk 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?

[Kevin Ball]

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

[Bas Festerbahn]

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 working. It's fine. Unless it's really broken. People don't really touch software, right? Cryptography software. Of course, with cryptography, yeah.

[Kevin Ball]

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 or 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 are there bigger changes, other performance considerations, like what does this look like?

[Bas Festerbahn]

So the big things are common best practices. Right. So I already mentioned keeps 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. And you can do Today on internal PKIs, 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 CAs, 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 there we had a problem, we solved it with an extra 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. An MLDSA44, which seems to be the most commonly used post quantum signature, if I'm reading the tea leaves correctly, that is two and a half kilobytes sending

[Kevin Ball]

it six times per connection. Wow. Yeah.

[Bas Festerbahn]

Okay, 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 two reasons. Performance. If you look at all the connections that are made with cloudflare over quic, so that's mostly browsers. About half of them transfer less than 8 kilobytes. So if you just do a drop in there, then it means that we're adding like we've tripled the payload. Yeah, 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 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. So 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 are redesigning the way certificates work. We're doing batch signing, which is called Merkle, to certificates. But there's all kind of cool stuff that we can dive into. But for the Edge it doesn't matter. It's still a kind of a certificate that you need to install and you need 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. 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. Some middle boxes, some firewalls like firewalls also some load balancers couldn't deal with it. So it's very bit. So the path here was just slowly roll it out until somebody complains loudly. Jen, hold it, ramp it up some more. And in the end we got there. So that's another problem, protocol authentication. 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 follow zones and chrome was at 10%. Everything was looking good. And then they ramped up to 100%. So 10% of all Chrome clients were already using PQ 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 that, but no, ramping up from 10% 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.

[Kevin Ball]

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

[Bas Festerbahn]

It's fine 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. It's really hard to predict. Just try it and see.

[Kevin Ball]

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?

[Bas Festerbahn]

So that's actually a funny thing. So you think big key means slow? 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 and native based cryptography are actually typically faster than elliptic curves, which are already known for their speed.

[Kevin Ball]

Interesting.

[Bas Festerbahn]

Okay. With embedded devices though, there is the thing that gets them is not necessarily the computation, but it's the memory requirement. So for elliptic curve, you only need something like not more than 200 bytes of RAM to compute with them. But with MLChem, 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, yeah, for sure.

[Kevin Ball]

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.

[Bas Festerbahn]

Definitely. Yeah.

[Kevin Ball]

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 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?

[Bas Festerbahn]

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 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. Ten 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 years, each of them, none of them fell away. They all kept hanging around and most of them put also on the frontier, but still everyone 2035. Yeah, yeah. 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 in 2035. But there's a mix between 2030 and 2035 on regulatory deadlines. So far that fault all still reasonably comfortable. That is until just the last few months. What happened is that to understand progress in 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, these are all analog, they are like noisy. So each quantum bit, each qubit, 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 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. I mean, you know that if you do a first attempt at implementing some algorithm might not be the fastest way to get to something. 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 superconducting qubits. And then there came out a paper just recently of Google which said, oh, actually these elliptic curves, these can also be correct very efficiently. They only require on superconducting only 200,000. And then that. So that was one. There's a much more efficient way to attack elliptic curves, which makes it a lot smaller. But then another thing 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.

[Kevin Ball]

Fascinating.

[Bas Festerbahn]

Yeah, I'm happy they told us they made the improvement on this, it's honestly

[Kevin Ball]

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.

[Bas Festerbahn]

So that's on the algorithm side, but then there's also the middle there. Yeah, 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 R Atomic. 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 and can only do near neighbor interactions, whereas with the reconfigure one 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 elliptic curve.

[Kevin Ball]

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

[Bas Festerbahn]

Yeah.

[Kevin Ball]

Wow.

[Bas Festerbahn]

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 so or two. So probably you would require something like 20,000 to do it in a more reasonable time.

[Kevin Ball]

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

[Bas Festerbahn]

Practically infinite. Right.

[Kevin Ball]

I mean, so a month is pretty good, but yeah.

[Bas Festerbahn]

And then the hardware side, where if you look at each of these approaches, they are hammering away at their challenges.

[Kevin Ball]

Right.

[Bas Festerbahn]

And each of them still has their big engineering challenge 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 1, 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 6000 neutral atoms. Not a computer yet. It's 6000. I mean, 6000-100006-00010,000. It's a grid of 6000 neutral atoms that they 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, 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.

[Kevin Ball]

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

[Bas Festerbahn]

We cannot exclude the possibility that we see one in 2030 already it's or earlier 2029. Even with maybe, maybe 1% chance, Google

[Kevin Ball]

put a date on it. Right. They were like, we think that you've got to be ready by 2029.

[Bas Festerbahn]

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.

[Kevin Ball]

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 the 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.

[Bas Festerbahn]

Yeah, so this is a big project, right? It's not like a single push because it's. I mean they're easy in the hard cases or easy the straightforward cases. But even the straightforward case is first you need to make sure that your internal cas or the 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 editing support for it is not enough. You also need to turn off support for quantum vulnerable crypto, otherwise you have a downgrade attack. And after that's all said and 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 OpenSSL already has support for MLDSA software support and other libraries certainly coming. That is reasonable. The thing that is important now as well is to bubble up the hard cases, right? So cases where you put a JWT into your URL, if that JWT is using a post quoting signature of 1.5 kilobytes, that will break your URL, right? That's not going to work. Headers a lot of servers, even 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 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 needs 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?

[Kevin Ball]

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

[Bas Festerbahn]

downside case, this is actually the exercise you can do tomorrow, right? Just assume we got it all wrong. There's already a quantum computer. What happens? What's the impact? 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 of 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 we solve this in different ways? I can't prescribe it will differ persistent system. Some of them you will discover. Oh, I thought it wasn't bad, but it's actually really bad. And others you discover 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? 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 key exists, doesn't tell you what the key does. 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.

[Kevin Ball]

What keeps you up at night looking

[Bas Festerbahn]

at this, what doesn't. I like my car. I don't want to replace my car.

[Kevin Ball]

I've long had a habit of calling smart devices surveillance devices because 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.

[Bas Festerbahn]

Hopefully they'll just get a software update where they disable the software update or something like this. I mean, they should. 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. In a way, Mythos is like a preview where the rate of exploits is going up. Luckily, with Mythos it can only find errors and bugs that were already in the software.

[Kevin Ball]

Right.

[Bas Festerbahn]

It's not going to find something errors that are on there. But with Quantum it will come all at once. So don't panic. But I mean, at least get started early enough.

[Kevin Ball]

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?

[Bas Festerbahn]

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

[Kevin Ball]

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

[Bas Festerbahn]

Actually banks, the financial sector is one of the branches that has been very much on top of PQ for a long time. At least the banks I see at conferences so nest worry there. Also, there's 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 Torphy again, which doesn't.

[Kevin Ball]

Right. Right.

[Bas Festerbahn]

There's a sweet spot. That's hilarious.

[Kevin Ball]

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

[Bas Festerbahn]

Sure will be. Thank you. Great to be here. To have been.