Podcast with Steve Orrin, Chief Technology Officer for Intel Federal

Key takeaways

• Federal deadlines run in stages: PQC must be usable by 2030-2031, all legacy crypto must be removed by 2035, and new national security system acquisitions must require PQC starting January 1, 2027
• A standard Windows laptop can contain around 20,000 crypto assets (roughly 5,000 unique packages), but only the ones an organization actually relies on for security, not unused features like Telnet or the HDCP video anti-piracy protocol, need to meet the deadlines
• Harvest now, decrypt later attacks are already happening, so any sensitive data encrypted today with legacy algorithms is already at risk once a capable quantum computer exists
• Intel has been embedding PQC capabilities like XMSS and LMS firmware signing into silicon for five chip generations because hardware has a five-year lead time and cannot be patched into existence overnight, unlike software
• Crypto agility matters as much as picking an algorithm, since chosen PQC algorithms could later fail to new cryptanalysis, and most crypto inventories miss the firmware layer beneath the OS and networked peripherals like printers

Transcript

Yuval Boger: Hello, Steve. Thank you for joining me today.

Steve Orrin: Thank you for having me today, Yuval.

Yuval: So who are you and what do you do?

Steve: I’m the Federal Chief Technologist for Intel Corporation, and in that role, I help the federal government and the larger public sector adopt and deploy technologies at scale, both from Intel and from our ecosystem. I help them understand what’s available today and what’s coming in the future. But I also take their requirements, their mission environment and enterprise needs, and bring that back to our business units so that we can continually build better products to meet where the government is at and where they’re going to be.

So working that bidirectionally to make sure that our products meet the expectations and the future needs, and that the government is getting the best out of their acquisitions and procurements today.

Yuval: And if I were to venture a guess, quantum is taking a just slightly bigger chunk of your time these days?

Steve: It is a hot topic. Getting ready for the mandates and the deployments that are necessary to support the executive orders and the NSM memorandum around getting the federal government, public sector, and critical infrastructure ready for that post-quantum migration. And I think it’s important to know that while we don’t yet have a cryptographically relevant post-quantum computer to worry about, it’s not some future risk that’s way out in the future that I have to deal with after my today risks.

There are risks already happening today, and I think that’s what’s driving a lot of the rapid visibility into post-quantum — understanding that data that is encrypted today will be at risk in the future. And so you have to start thinking about it. Really, you had to have already started thinking about it. It’s not a future problem, it’s a today problem.

Yuval: Could you give us a quick overview of the deadlines? What needs to be secure by when?

Steve: It’s a great question, Yuval, and it’s not a simple one. There are multiple deadlines, and it depends on the kinds of systems. And the most recent executive order that just came out also put some light onto additional systems that are affected.

So let’s start with the basic deadlines. In some of the early executive orders and the national security memorandum, they put some hard dates in the future around being migrated to post-quantum algorithms. 2030 and 2031 being the most significant, where all of the critical infrastructure within the federal government, within the national security systems, need to have migrated for encryption, for digital signatures, and for the technologies that use those to be moved to post-quantum algorithms.

So those are the overarching mandates. And then there’s another date, which is 2035, and that’s when any legacy cryptography has to be removed from the environment. So first, you’ve got to have post-quantum algorithms available to be used and start using them in 2030 and 2031. And then by 2035, anything that isn’t post-quantum or that has other algorithms available has to be pulled out.

But there’s another interesting nuance to that, which goes to the acquisition cycles. You can’t flip a switch and say, “Okay, yesterday I was not post-quantum, today I’m post-quantum.” There’s a whole process of migrating, of identifying, and of testing and evaluating, and a buying cycle that has to be budgeted for.

One of the first deadlines came out in the CNSA 2.0, and it was actually unfortunately buried in the FAQ. It wasn’t in the actual memorandum. But in the FAQ, when it highlighted the timeframe, one of the key points — and this came out in December of 2024 — is that for national security systems, new acquisitions, new procurements starting January 1, 2027 must require post-quantum as part of that acquisition.

So if you’re going to buy a new firewall, a new web server, a new security appliance, a new server, a new cloud server, any new contracts that are acquired starting on January 1st will have a requirement for post-quantum. So that puts a starting point deadline on when you have to start buying those.

And it’s important because that was the first line in the sand to understand that if I’m going to make a 2031 deadline, I need to start buying stuff years in advance to have it vetted, tested, deployed, trained, and operational. There’s a lag between the actual acquisition and fully operational in these large-scale systems. And it’s not really just government that has that kind of lag. Large enterprises take time to acquire, deploy, train, and fully validate before going into large-scale production.

So what the government recognizes is that we need to start buying things earlier. That January 1, 2027 deadline really kicks the ball in motion as far as starting to buy things that help you achieve those goals.

In the most recent executive order that came out, it broadened the scope beyond just national security systems — which is Department of Defense and intelligence community and some of the other intelligence agencies across the government — to all of federal government and the defense industrial base. What it basically highlighted is any high-value assets, or HVAs, and that’s really mission-critical systems.

So the applications and systems and infrastructure that support the critical functions of the enterprise of the agency will also now have that 2030, 2031 deadline. That really helped, because there was some confusion about the rest of the government, and that executive order laid the line saying it’s not just the Department of Defense and Intelligence, it’s whole of government and the key industries that are supporting the government.

So that’s the defense industrial base, the system integrators, the platform builders, the ones that build the planes, that build the systems that are on contract to the federal government — they are now also covered under that executive order. They need to get their post-quantum cryptography migration and plans kickstarted and moving to meet those 2030, 2031 deadlines.

Yuval: So a federal agency wants to buy a PC, hypothetically. And a PC has a screen, which may not be an issue. It has a processor, it has a Wi-Fi chip, it has very many components from quite a few manufacturers. How does all of that happen that the PC becomes certifiable for these security standards?

Steve: It’s a really good question, and you’ve hit on a key point there. Let’s take something simple — and it’s not, but something like a laptop. There are a variety of components. There’s hardware and software and firmware from a variety of vendors that all go into that finished product.

When you buy a laptop, you have obviously the CPU, you have the wireless card, you have a trusted platform module, you have USB hubs, power regulators, you have graphics engines, video capabilities. Then you have the BIOS and firmware that run those things, and then the operating system and drivers and software stacks that get loaded on top of that. So when you end up with a laptop and you boot it up and Windows comes up and all the other software, all of that has to be orchestrated.

And that is an industry-wide effort that requires collaboration between the component manufacturers, the CPU manufacturer like Intel, the OEM in the case of Dell or HP or Lenovo, the operating system vendor in the case of Microsoft or the Linux environment or whatever other software up the stack. You’re going to put Adobe on there. You’re going to put an antivirus program. All of those need to be post-quantum.

So there are a couple of nuances to how we accomplish this goal. First and foremost, it goes back to the things that you rely on. This was one of the key messages coming out of CNSA and out of NIST — you’ve got to be able to say that these are the things that I rely on for my security posture, my security assurance, and these are the things that are going to be post-quantum.

There was a great example given by some folks from one of the agencies working on this. If I have Windows running on my system, with Windows comes a whole lot of software, and one of those pieces of software is Telnet. But we’re never going to use that Telnet application. It’s not part of our security posture. It’s not enabled in our organization. Does it need to be post-quantum when I buy that laptop?

And the answer comes back: do you rely on the cryptography inside that Telnet application for your security assurance, for your data protection? If the answer is no, then it doesn’t have to be post-quantum ready by 2030, 2031. By 2035, because it still uses legacy crypto even though you’re not using it, the requirement is to remove that or have it post-quantum. But the deadlines are really for the things you rely on for your security assurance — your data, network, and application security. Those things need to be post-quantum.

There’s another good example when you look at the hardware. Inside of everyone’s client systems, laptops and desktops, there is an encryption protocol that goes on between the CPU and the video output to HDMI. It’s an encryption protocol that was put in place many years ago for anti-piracy so that you can download a movie from Disney and watch it, and no one has to worry about someone stealing those bits and creating a copy of the movie.

It’s called the HDCP protocol, and it’s an encrypted protocol to protect the IP of the movie creators and the movie distributors. You as a user of that platform aren’t relying on that security. It’s not providing security for your data. It’s benefiting the IP of that content creator.

So in that same idea, it doesn’t need to be post-quantum for the 2030, 2031 deadlines because it’s not protecting your data. You have no way of using that encryption protocol to protect your screen. If you want to protect your screen, there are other protocols you would use. So in that similar case, it’s identifying the critical components — the critical hardware, software, and firmware that are applied to your security assurance — that are the things you need to make post-quantum.

And that goes to one of the first things that needs to happen in any of these exercises: discovery. You can’t secure what you don’t know. You can’t migrate what you don’t know. A strong cryptographic inventory of all the different cryptographic assets that are part of your organization that you rely on, and using that inventory to drive your migration strategy and your migration priority.

So yes, a laptop that you buy from a vendor is going to have a lot of cryptographic assets. I think one company did a scan recently of a standard Windows platform at bring-up and found 20,000 crypto assets on the platform. And that includes certificates, crypto algorithms, key stores across the entire thing. There’s a lot of cryptography that goes into protecting a given system.

When you dial that back and look, there’s a lot of repetitive stuff because every driver probably uses some of the same crypto engines, but it’s still around 5,000 crypto packages. Do all of those need to be post-quantum? The ones that you rely on do, and that’s hard for an organization to truly get to the gory details.

So this is where the OEMs and the infrastructure providers are taking the effort to provide the information to the customer to say, “Here’s what is post-quantum ready in our platforms or in our cloud service infrastructure or for our software.” Ultimately, it’s going to require a dance, if you will, with the OEMs and the software and the ecosystem providers and the acquiring agencies and their procurement agencies and their assurance folks to align what are the needs and what are the capabilities. And that’s going to require coordination, and that’s already happening.

Yuval: Let’s dive into the Telnet example, because I’m trying to understand who needs to certify and who’s responsible for meeting or not meeting these. So if you look at a large agency — if you look at DOD, they’ve got so many different assets, and maybe 99.9% of them don’t rely on Telnet, but maybe there’s a small few that do.

Does that mean that the entire DOD needs to have this? And then when Dell ships a new laptop, do they sort of have an asterisk that says, “Well, this includes Telnet that’s not crypto certified”?

Steve: I think I’m going to start with one word that you’re using. There is no certification process, so it’s not like you’re going to get a stamp from some government agency that blesses your system. They haven’t created that kind of regulation. It’s really about whether you’re going to meet the PQC standards as required for information assurance.

The other thing is that it’s going to be an acquisition or organization or program-specific process. So you take DOD — it’s a huge entity. There are four or five main services: Navy, Marines, Air Force, Army, Space Force. And within those, hundreds if not thousands of organizations.

Each one of them, in your example of the 99% — when they do their assessment and say, “Here are the things we care about, here are the things that need to be post-quantum” — they’re going to go through and check, “When I buy this platform, does it meet the requirement?” And it’s their people doing that exercise.

That one organization that happened to be using Microsoft Telnet — if Microsoft doesn’t make it post-quantum (and they may), then they need to find an alternate application to provide Telnet services that is post-quantum. But it will be a decision at the programmatic or acquisition level. There’s not going to be an agency-wide acquisition. There are agency-wide mandates.

The way it’s working is that the agency heads will drive their migration strategy down to the programs, collect what the different programs are doing, and bubble that up into the reports. But the ultimate onus for verifying the PQC readiness to meet the requirements of that particular mission goes to that mission.

Because as you said, a person working in the Pentagon is going to use one set of applications. An army fighter out in the field may be using a completely different set of applications, even though they’re on the same kind of Dell laptop. So you’ve got to do the assessment locally to understand what you’re using and what the PQC requirements are.

And again, there isn’t a certification — it’s information assurance, supply chain risk management. You do an assessment, a supply chain risk management assessment starting with inventory and mapping. Does my inventory of the critical components that I’m relying on show they are PQC? And there’s an investigation that has to happen.

This is why the OEMs and the infrastructure providers, the component providers, and the software providers are going to be proactive in providing that information. Now, there are mechanisms — think about SBOM, the software bill of materials that came out a number of years ago. We’ve already got standards being put in place for a CBOM, cryptographic bill of materials. So there will be technologies and artifacts that will become available from various vendors that will help automate some of this.

But I think we’re still in the early days here, and there’s going to be a lot of manual investigation as this picks up. There are also companies that have been stood up in the last five years to help organizations do that cryptographic inventory, identify crypto assets, and then monitor them as new assets come in or updates arrive — going from red to green because something got the update with the post-quantum algorithms.

Yuval: Do you think that 2030, 2031 deadline is too aggressive, too lax? How do you think about the date?

Steve: I’ll start with saying this is my personal opinion, does not represent my corporation or what I think the federal government should do. In my personal opinion, I think that from a risk perspective, 2030, 2031 is the right target. If we could do it earlier, we should, because the harvest now, decrypt later threat is already a risk.

It’s already happening, and it has been happening. Every encrypted piece of data that’s been pulled off the net and waiting in some large database for when the quantum computer comes online — if you want that data to be protected after that, you need to have started post-quantum encrypting back when you created that data.

So every day we generate new data, that data is going to be at risk in the future. Now, if it’s information that has a short timeframe on its classification or sensitivity, great. But as you know, the government has long-lived secrets. Your personal information, your financial information is relevant to you for your life. Your banking account information is going to be important to you for the next twenty, thirty, forty, fifty years, not just the next four.

So the timing is important because we are seeing already advancements in quantum capabilities. Not as much in the number of qubits we can get — that’s a slow progress — but I see the real innovations happening in algorithmic tuning and in some of the crowdsourcing efforts to pull together resources across many organizations to target keys. And we do know today we have large-scale cloud infrastructure along with large-scale AI infrastructure that’s really tackling this problem.

So the deadlines are there for a good reason. The biggest challenge is whether we can actually meet them. One of the real problems with executive orders and mandates is that they’re not connected to funding. It’s going to cost money to do this migration. You’re going to have to buy new systems, buy new licenses, refresh legacy platforms — many that have been there for years and don’t have the ability to be updated with just a software patch for post-quantum. There’s going to be training and infrastructure necessary to vet the environment.

So there’s a lot of organizational and financial structure that needs to come in place to help facilitate this rapid migration, and there have been several people who have said this is probably the largest migration we’ve seen across the world in our lifetimes. If you think about some of the last big shifts in infrastructure, you go back to Y2K. That was a big one. There was a lot of money and effort put into making sure all those mainframe systems could handle the date change. Thankfully, not too much went wrong, but that was also a time — we’re thinking back to the year 2000 — where we didn’t have the sheer scale of infrastructure and devices and software that we do today.

There was another transition when the government moved from Triple DES to AES. Again, it was a major shift, didn’t have the same kind of hard deadlines, but we also had fewer systems and less infrastructure. Now we have a monumental shift because it’s both the encryption and digital signing and firmware signing and in some cases asymmetric crypto that’s still using legacy or smaller key sizes, all happening across a much larger scale infrastructure in a shorter timeframe.

So I think there’s going to be a lot of challenge for the government and critical industry and the private sector to try to get to those deadlines. One of the benefits we have as an industry is that in the past, everything was disconnected and in its own silos.

Cloud is going to be a big benefit here because the cloud providers can deploy a migration and then scale it to everybody. If they update the core infrastructure that provides post-quantum services, everyone gets that in that cloud environment. So there’s some scaling that’s going to help on the cloud side. But for the on-prem, for the desktop, for the DOD and IC where they have tightly controlled air-gapped environments, it’s going to take a lot of work to migrate all of those systems.

Yuval: So unlike Y2K, this is an ongoing issue, right? With Y2K, if I’m a year later after the deadline and systems are working fine, then whatever, I’m behind it. You’re good. But here, that’s not the case, right?

Steve: Yes, that is. And there’s a not-as-much-talked-about issue with post-quantum, which is crypto agility, which is sort of paired with this. We’ve picked these algorithms based on about 10 years of research, but we know that algorithms fail. It happens. New algorithmic tuning comes out, new research into cryptanalytic attacks. It is possible that some of those algorithms may not succeed or may not be long-lived.

NIST is continually updating and doing research to put more algorithms onto the approved list. One thing at this moment in time is we also have to start thinking about not just moving to any post-quantum algorithm, but moving to the ability to have crypto agility so that I can have multiple post-quantum algorithms and be able to change them out without requiring a massive shift.

A lot of folks are taking a more strategic look at their infrastructure. A lot of the OEMs, a lot of the software providers are looking at how they’re building their crypto packages and crypto systems — not just to update the suite with another algorithm, but how do I build into the system the ability to be agile for future algorithmic changes?

And so that’s going to help with the long term: we did the transition and we’re safe for the future, not because the algorithm is the best, but because we can shift to a better algorithm when and if necessary.

Yuval: I want to understand the Intel angle on two sides. One, there must be a lead time issue, right? I mean, you could finish a piece of software a day before the deadline, but you can’t finish the design of a new chip a day before the deadline. It takes time to build it and integrate it and so on. And the second part is, beyond making hardware and software components, how does Intel help the agencies that are impacted or under mandate with PQC?

Steve: It’s a really good question, and you hit it on the head. Software you can do — with an AI factory, you can build software in minutes. Hardware has a very long lead time. If I were to come up with a new design or a new feature for an Intel platform processor, five years from now it would come to market. There’s a five-year cycle.

So we start building our chips five years in advance, and about two years before launch, they get locked down because silicon is going to be laid, and there’s a long time between the mask being created and then validation, and getting it into the OEM’s hands.

We’ve been working on post-quantum for many years. We’ve been part of the NIST effort since its beginning, over 10 years ago. And we’ve been building post-quantum support into our platforms starting back five generations ago. Going back five generations, we started putting some of the lowest level capabilities into the platform for signing things like microcode.

For those who aren’t as familiar with the nuances of what’s underneath the covers inside your laptops, there’s a lot of firmware. There’s the BIOS that most people are familiar with, which is what launches the operating system and gets the system up and running. That’s about 20% of the software that’s inside your platform. The other 80% is in ROMs and other componentry deep within the system that when power comes on, those things start to come up before you ever get to the OEM BIOS.

We started putting in digital signing using post-quantum algorithms, and if you look at the CNSA 2.0, they specifically call out XMSS and LMS as two algorithms specifically for firmware signing, because we worked with them in the very early days to get those first algorithms ratified so that we could start building that into silicon.

So we’ve started building those capabilities going out many generations. In every generation of our platforms, we’ve added additional post-quantum algorithms moving up the stack, because like you said, it’s not a switch you flip — it’s really a marathon. We constantly add more and more, and then in our 2027 platform, we really complete the story of an MVP for user-based post-quantum. But that journey started multiple generations ago to get us to where we’ll be ready for these deadlines.

So that’s the work Intel has been doing, both on our client and our server platforms, to make sure that our parts will have the necessary low-level post-quantum capabilities — a lot of it is digital signing of the firmware and of the security engine software — and then extending that up the stack so that the OEM and their BIOS can be signed with the post-quantum key, and then the launch of the operating system. All of that ties together to hardware roots of trust that we’ve been building in for some time. Then the OEMs in their next versions will be adding their signed firmware, and similarly, the operating system vendors will be adding their signed firmware, as well as things like secure communications for hardware components like wireless cards. All of those need to have post-quantum algorithms.

So we started that journey many years ago. What we’re doing for the federal agencies is really three parts. One is education — working with government agencies to help them understand how the platform supports their post-quantum strategy, recognizing that you’re not going to be able to take a 20-year-old laptop and say, “Magic, it’s post-quantum.” You’re going to have to start planning for refresh and planning for mitigations.

Two, we’ve been working with the ecosystem — the OEMs, the software ecosystem, the cloud ecosystem, and the system integrators — to help them adopt the post-quantum capabilities and tie them together into a cohesive story.

And third, we’ve been working with the standards. We have been part of NIST’s post-quantum exercise since its inception, and working with the CNSA folks both on understanding the algorithms and their impact on performance — because there is an impact on performance — but also helping with validation. We’ve been doing validation of the algorithms on Intel processors on both current and future processors using simulation and emulation to give them data as part of their algorithmic evaluation of which ones run best on the broadest amount of commercial infrastructure.

Yuval: It was only a couple of years ago when every time someone said PQC, they also mentioned QKD, quantum key distribution. Is that a component of any migration or security strategy that you’re seeing?

Steve: It’s mostly been focused on the HSM side. In cloud infrastructure, banking, and some of the government agencies where they do key generation as a core function, they’re looking at quantum-based approaches to provide a more robust entropy source. I think the bigger risk right now is the harvest now, decrypt later threat, and looking at encryption and digital signatures.

Quantum key distribution will be interesting. It’s definitely important for those really high-value hardware security modules that are doing key generation. But I don’t think today it’s the number one risk that everyone should focus on. As much as there’s a lot of hype — and I’m not trying to pick on those companies, they’re really good companies doing some interesting things — but if I look at my list of risks as a CIO for a moment, already post-quantum feels like something in the future that I’m being forced to deal with, because I have all the malware and attack bots and AI things killing me today.

Quantum key distribution is much further down the chain as far as things I’m worried about. It’s on the list, but it’s low on the list. Once we get past the PQC transition and start looking at what else may be affected, people will start looking at key distribution.

But there are a lot of other things we can do. If you’re wrapping the keys really well with your post-quantum algorithms, then you’re really worried about attacks back earlier in the process. So again, I think quantum key distribution is not the most pressing.

Where it is interesting is in areas where it’s not core infrastructure servicing another infrastructure, but if you get out to the edge or into uncontrolled environments — drone swarms, edge sensors — where I don’t have guards with guns and locked doors and multiple layers of infrastructure between that hardware security module and the outside world. Then you want to start looking for more robust ways for key generation, because you’re worried about an adversary that may have physical access or may be able to do man-in-the-middle attacks.

There will be use cases, even in the shorter timeframe, for quantum key distribution, but those aren’t going to be the big infrastructure. They’re going to be more towards the edge, in my opinion.

Yuval: Is there a supply chain integrity issue? I mean, can I buy an Intel-compatible chip that just doesn’t have the same security as the original Intel part?

Steve: The answer is that you can buy anything with any label. We built in — and all of the major vendors of infrastructure have built in — counterfeit detection or proof of originality and assurance into our platform. If you get a CPU off eBay and someone has written “Intel Panther Lake” on the side of it, there’s a quick and easy way to determine if you’re really getting a Panther Lake, even if it looks like one.

We’ve built hardware roots of trust into systems to be able to verify that this is a legitimate, original part with particular qualities. And what we’re doing with our CPU ID — the identifier for the CPU and its generation and its SKU — is working with the ecosystem to provide mappings to our post-quantum readiness for those parts so that they can report when you’re running on a Dell laptop or an HP laptop with a specific CPU ID, here are the post-quantum algorithms that have been deployed.

Supply chain risk management and supply chain assurance is something we take very seriously. We actually instituted something called Assured Supply Chain across our laptop systems, where you can get a digital certificate for that platform that will tell you what all those components are and where they came from.

This is absolutely something we work on with both the OEMs and the federal government and critical infrastructure, financial services, and others, so that they can get visibility into the supply chain. All the major vendors are different, but AMD, NVIDIA, Qualcomm all have mechanisms to make sure you’re getting legitimate parts, and digital certification through digital certificates or other mechanisms to give you that transparency and ability to assure that you’re not getting counterfeit or gray market parts into your enterprise.

Yuval: As we get close to the end of our conversation today, I’m curious. Let’s assume you’re advising a mid-size agency, and they read on the internet that you should do an inventory of your crypto assets, and they’re starting to do that. But what’s the one thing that most people miss when they go on that journey?

Steve: It’s a really good question, Yuval. I think it comes back to something I’ve said a couple of times over the last year: people often forget about the hardware platforms they’re running on because it’s not something you typically see. You see your Windows, you see your applications, you see your cloud services. You don’t want to forget the PC. You don’t want to forget the servers that are running those systems.

They are involved in the security, and if you’re not running on modern infrastructure or modern systems, you may have gaps in your digital discovery. A lot of the tools, especially some of the free open source ones or even some of the commercial ones, when they do their asset inventory, they basically stop at the OS. They don’t hit the BIOS — and by the way, BIOS is a key component of your security posture — and they definitely don’t often hit what’s underneath that platform.

So I think the one gap is the infrastructure that’s underneath the operating environment and your applications. Same thing with the cloud. You see your VM, but what’s underneath it? Being able to validate or have Amazon, Azure, Google, or IBM give you a report that says, “Yes, you’re running on post-quantum infrastructure” is important. And if you go to their sites, they’ve all committed to having post-quantum for their infrastructure — different dates for different ones, but they’ve all announced it. So this is a whole-of-ecosystem initiative.

The other thing is that oftentimes people just run scans of their enterprise, but they don’t catch everything. One interesting area is that most organizations, even medium-sized and small businesses, have internet-connected or wireless-connected printers. Those too have to be post-quantum because you’re sending your data to that printer over a connection. So making sure that you’re doing an inventory of not just your IT assets in the classic sense — your laptops, your software, your databases — but all the peripherals that are connected to those will also need to have a post-quantum story.

Yuval: And last, a variation of a question I ask most of my guests. It’s a hypothetical. If you could have dinner with one of the quantum or, in your case, crypto greats, dead or alive, who would that be?

Steve: That is a really good question because in my life I have been lucky enough to have dinner with a lot of the cryptographic greats — Bruce Schneier and Ron Rivest, to name a few. But I think if I were to go back, right now I would like to go have dinner with Shor because I want to understand what his thinking was and where he could have gone with that algorithm. He’s now the most popular cryptographer, even though all the others really built the building blocks. Shor’s algorithm is really on everyone’s mind.

So I think I would go and have a nice dinner with Shor. But I had the fortune early in my career to work with many of the cryptographic greats, and so I’ve had that opportunity to meet with many of them over the years.

Yuval: Steve, thank you so much for joining me today.

Steve: My pleasure. Thank you, Yuval.

Yuval Boger is the Chief Commercial Officer of QuEra Computing.

August 31, 2026