Transcript | Protecting Critical Data Before Post-Quantum Cryptography— with Qrypt

It’s the 11th hour, as we approach 2024 and the release of NIST’s post-quantum cryptography standards. Is it possible to start protecting some critical assets today? Find out how a few applications already do so in this episode of The Post-Quantum World. I’m your host, Konstantinos Karagiannis. I lead Quantum Computing Services at Protiviti, where we’re helping companies prepare for the benefits and threats of this exploding field. I hope you’ll join each episode as we explore the technology and business impacts of this post-quantum era.

Our guest today is the CTO and cofounder of Qrypt, Denis Mandich. Welcome back to the show.

Thank you so much for having me again.

You were on over two years ago. It’s crazy to say that — and with some of the things going on in PQC today, I thought it would be a good time to have you back on. I expect we’ll cover a lot of ground, but can you give a quick refresher or introduction for those who didn’t catch episode seven about yourself and your company.

Qrypt was founded a little over five years ago with the intention of bringing post-quantum-safe and quantum-secure systems to commercial users that were available in the government. I’m a physicist by background, but I worked for the intelligence community for 20 years, as did my cofounder, and we saw the theft of IP as being unsustainable for the next 10 years, if not less than five years, and we wanted to do something about it. To do that, we want to bring types of secure systems we used in the government that are very expensive to deploy and cumbersome to use and make them easy for commercial industry.

That’s terrific, and very relevant for what’s going on. I expect next year to be huge, and we’ll get into some of that. First, what are you hearing these days with regard to NIST? We know that next year, we’re expecting the finalists. Do you think that’s going to happen?

I’m fairly certain it will happen, from everything they’ve said in the last few months. We had a conference a few months ago where everyone in the industry got together, got to hear where they stood on it, objections, interest in the actual date, which they have provided, but we’re pretty sure that’s in the next few months — as early as January, or maybe even sooner.

That is truly a ticking clock. As I’ve talked about on the show before, once that comes out, federal agencies have to take action pretty quickly, and then we expect the private sector to follow suit. Are private-sector companies knocking on your door right now and asking about how it might impact them?

They’re coming to the realisation that this will take a long time, and that if they don’t start now, and if something like a cryptographically relevant quantum computer comes online sooner than they expected, they just won’t have time to transition. Even if you’re looking at the 10- to 15-year horizon for most of these large enterprise systems, many legacy networks just need to be replaced. They can’t be updated; they can’t be upgraded. They’re reaching end of life.

One of the immediate short-term concerns is that any equipment, especially hardware systems they’re buying now, if they’re obsolete before the lifetime of those systems — their expiration date is five years away — they don’t want to invest in it now. They want to be sure that if they have to upgrade to these post-quantum systems for compliance industries, like the government, healthcare, finance, and so on, they’re not buying something they have to replace pretty quickly.

That makes sense. We do a lot of cryptographic agility assessments of things, and the basic guidance is to prepare for the future, and then there are all these steps you’re going to have to take. But every once in a while, someone has something super critical they want to start protecting now. In a little while, we’re going to talk about some of the stopgaps — the little things you could do for the critical data paths. But when it’s not a company, there are a lot of people concerned about their own safety, and messaging in the world. One app that comes to mind is Signal. When we talk safety, the security for Signal users could mean literally their life, depending on what country they’re in. There’s all sorts of instability in the world, and people who want to try and stay in touch during it. Can you explain to our listeners what happened recently with Signal?

Signal was one of the first messaging services to upgrade to these new post-quantum algorithms, but also to layer it on the existing algorithms we have out there — RSA and optical curves. That’s a good bet. If one of them should fail, at least the other one will be in place to provide some level of security. Even if a big quantum computer comes online tomorrow, it can break the RSA, elliptical-curve side of the application. At least you’ll have Kyber layered on top of it to give you that protection, or at least some level of quantum safety, but, again, we’re not sure.

The real issue most people see in the headlines today is, of course, harvest now and decrypt later. We have to talk about that in every one of these calls. The safety issue in many countries is extreme. It’s potentially execution in some of these denied areas — Iran, North Korea — if you’re using something like that, or the loss of all your privacy, your systems becoming public all of a sudden, and that might happen even without quantum computers. That happens with flaws and implementations of software — the randomness-generation mechanism, which we’ve talked about before, when you’re generating keys that are not actually random, and so on. There are a lot of ways they can fail. Signal is the go-to application because everyone’s kicked the tires on it. Everyone understands how the crypto works. There are other ones out there, like Telegram. They roll their own crypto, which is, of course, a violation of the golden rule in this.

That’s a little scary. You should never do that, in my opinion.

Signal, to our knowledge, has done everything right. There are still issues with any app, like Signal, for example. If you have Signal on your desktop, you’ve got it on your phone, you’ve got it on your laptop, and so on — your iPad — if you can see multiple versions of the same conversation on multiple devices at the same time, that’s an opening for big intelligence services to have one version of your conversation, your communiques, on their own devices they could read. There’s a level of security we enjoy with Signal simply because they’ve transitioned to post-quantum cryptography already. But there are still things that need to be fixed for all these secure systems to have some level of guarantee that no one else can be listening in. There’s only one version that ever exists between you and me in a call, and that version dies when we hang up.

You have to keep track of all those devices you haven’t installed on — are there updates or vulnerabilities that have nothing to do with cryptography as well? If you have a vulnerable version of Signal on one machine and not another, you forget, and then your messages are potentially exposed.

That goes to the heart of harvest now, decrypt later. Twenty years ago, it required the services of a huge cyber research industry like the NSA or the CIA and so on to figure out where these flaws were in the software. Now, you have run-of-the-mill researchers right out of college, or even in grad school, finding these flaws in these systems. Once they’re found, everyone knows what they are and how to exploit them. Those tools are out there pretty quickly now, Again, we look at harvest now, decrypt later as a thing on the horizon because of quantum fears. But the reality is, it happens to all these applications regularly. We may not see all of them. We might find out about the patch, not realising how many times they were exploited before those patches came out.

When you talk about an approach like Signal, that’s typically what I call hybrid post-quantum cryptography. We’re starting to see that rollout. Of course, the newest version of Chrome supports this kind of approach. AWS supports it within its own infrastructure there. It’s one of those times I like to say that being on the cloud is more secure than not as you approach this quantum era. But there are still either custom-written things or other paths that can’t be protected by these kinds of means. That would be where you start to look at custom solutions. We should roll into a few of the things your company does today while you’re waiting. Then I have a follow-up question based on the White House memorandum and some guidance. But we’ll start with basically what you provide companies today that want to start securing certain critical paths.

High-value data, high-value links. We provide a mechanism that’s very similar to what quantum key distribution does, where we simultaneously generate the keys at the end points rather than distributing them, which is the way most of these asymmetric algorithms work today. If you look at the history of why we deployed those, it was an error when a single copper wire and a handful of switches connected to users. We don’t live in that world today. We should never rely on a single point of failure, a single path, a single mechanism that couples the data and the encryption key distribution mechanism all in one package, making it very easy to exploit.

Again, going back to harvest now, decrypt later, that’s why that’s even possible. It’s very hard to get all that data assembled again if it’s coming through different paths and the keys are decoupled from the data itself. What Qrypt does is take quantum random number generators, which we’ve codeveloped with the national labs — Los Alamos and Oak Ridge National Lab. We’ve flipped the QKD model, inverted it a bit and put those into cloud data centers. We’ve made those available by simple API calls so you can access as many of them as you want in the cloud.

Instead of using the key exchange or key encapsulation mechanisms — these asymmetric algorithms we’re transitioning to for distributing keys — we use it to exchange a small amount of metadata. That metadata tells you which one of those cloud access points you have access to through these API calls. You’re in an authenticated channel. You download quantum random numbers from these physical appliances in the cloud to each end point. Then the last piece of metadata only known between the communicators in this party, Alice and Bob, is how you apply cryptographic extractors, the parameters for that session and that session only.

Then you can distill keys at the end point. Those keys are symmetric keys of any variety — any flavor of AES — which gets you to quantum-safe all the way up to a full onetime-pad-based system, which, of course, is very expensive. You can pay in data transfer and bandwidth, but what you get is quantum-secure. It’s provably unbreakable even by quantum computers. We believe that’s true for AES, but we don’t know for sure — certainly for AES 256. We’re confident in that. That’s the differentiation that Qrypt brings — that we leverage modern cloud infrastructure, redundant and resilient networks, to generate those keys rather than, again, this architecture we inherited from the 1970s, which is key distribution.

Onetime-pad is secure as long as you don’t do things like repeat messages to your dictator or something. As we’ve learned in history, it’s probably not the way to go. When you’re using this tool, it sounds like there are multiple vectors someone would have to attack. They’d have to be able to attack that metadata. They’d have to be able to attack its communication with the cloud server to get the key established and then have to attack that communication with, let’s say, symmetric keys. You’re introducing multiple points that would have to be exploited — a total kill chain of insanity that would have to be achieved. That definitely makes sense as a different approach.

Now, that is a customised setup. Is this something you would then only, like we said before, assign to high-value data? You wouldn’t imagine doing this to go shopping. You wouldn’t do all this to go to Amazon to buy a book.

We’ve demonstrated on those high-value data links, we’ve already, in the way you would use it, similarly for QKD for two end points, which largely can’t be scaled because you’re distance-limited. We don’t have quantum repeaters and quantum memory yet. We showed the same way to get that level of security from two sites in Washington, DC, all the way to Sydney, Australia, where now you’re operating under the assumption that the adversary controls all the infrastructure between those two points. We don’t care at that point, because we generated the keys at the end points. We’ve decoupled that from the data. The keys are not correlated with the data. They may be indexed at the end points — I use this key, use that key and so on — but they’re not tied to the data. The mechanism for breaking into that data is not tied to it at all.

It’s fairly inexpensive to do now. It was expensive to do this on the government side, of course, because when you have to communicate from the embassy in Moscow to Langley, Virginia, someone has to hand-carry those keys over. Some diplomatic courier with a box with terabytes of key material does the same thing. We do all that digitally, and we make that very easy for anyone to consume in any application. Of course, it’s not free like the mechanisms we use today. But, again, you enjoy a much higher level of security and privacy.

The actual communications done with the metadata toward the end points, is that communication post-quantum-safe? In a weird way, it doesn’t have to be yet. This isn’t information that will be useful even in one minute, let alone in 10 to 15 years. Is it just standard like TLS for now, for that communication?

It doesn’t matter what you use, like you said. But why not use PQC, which is what we’ll do once the final version of the PQ standard comes out, because we don’t have the final version yet. We think we do, but when that happens, you’re breaking multiple different links at the same time. Even if you had some godlike access, super user access, of course, then, they’re probably on your end point. That’s the real answer.

That’s a whole different problem. That’s not a quantum problem anymore.

But what people discuss in public now is, what if the Chinese are harvesting everything from your router in your house? They’re not saving that data for a quantum computer in the future. They’ll just hack into your end point. They’ll see everything clear. What we’re talking about here is these big choke points on the internet — big collection sites. That’s where this stuff is filtered and collected for later exploitation. That’s what we need to fix — and solving that big-picture problem, including that metadata exchange, which is simple TLS — a PQC version of TLS — is just fine. It’s only useful for a very short amount of time. Again, nobody’s going to waste quantum computing resources on that. They’re going to waste it on the easier target — the soft, white underbelly. We always talk about how fast you have to run to outrun a bear — just faster than the guy next to you.

It’s fun because, in a way, this is one of the first times you’re using something quantum to generate post-quantum cryptography. In this case, what are you using to generate the keys?

Generating the keys is critical because, again, just years ago, it was very hard for people to find flaws in the key-generation mechanism, the entropy sources we usually find in processors. Again, 20 years ago, this was dark arts figuring that out. Now, I read articles on the archive where people are, like, “All I have to do is heat up the processor, and that causes this nonrandom effect for the key generator” — simple things like that.

Then there are flaws. Software developers, even enormous companies, make catastrophic errors in this space. We saw the Samsung Galaxy phones that had a flaw in the initialisation vector for 100 million phones. Everyone knows what that is. Those keys were generating secure private keys for crypto wallets. I’m not saying this is what happened. I’m just saying that anyone who had one of those phones only has to go generate as many keys as they want and go test them on data they’re interested in. In many cases, people are using it to steal cryptocurrencies.

What we did was look at how the government did it, and they have very sophisticated, super-expensive sources no one will ever pay for in industry. We had to take them from a giant light table in a big box and reduce them into something that fits in an appliance in a data center. Those physical sources are based on photon bunching. When particles of light photons come out of an optical amplifier — when you excite a small number of modes in that device — you’ll see them come out in clumps or bunches, unlike a normal stream of light that would come out from a regular light source. The timing between the arrivals of those bunches at a photo detector is truly quantum unknowable.

We can use that to generate zeros and ones that are truly random and unpredictable. And by random here, we have to make a strong differentiation between what’s used in information theory — which even NIST has cautioned is not something you should be doing using statistical testing for cryptographic key generation to prove that your keys are random, because that’s impossible to do with a test on just some numbers — we’re talking about physical quantum-based randomness, which is unknowable, meaning we can set up a test, we can perform an experiment on it, and with perfect information and knowledge about how we set it up in the initial conditions, we cannot prove the outcome will be a zero or one. It’s impossible.

The second effect is using vacuum noise from shot noise in-system, where we differentiate across multiple detectors. We take out all thermal electronic noise. What’s left over is truly detection of light sources, the shot noise from interactions with the vacuum. 
We have two others. One is phase diffusion. That’s where you have the quantum unknowable: Here is the phase of a laser when it’s switched on. Then you combine two laser pulses at a photo detector with a path that’s different by a single pulse. When you combine them at the end point, it’s just like waves in the ocean. Sometimes they destructively interfere, and there’s no wave. Sometimes they constructively interfere, and you have a giant wave. We measure that by the pulse amplitude at the photo detector. We can do that very fast at gigabits per second.

The last one is SPAD arrays. These are single-photon avalanche diodes where there are thousands of them on a chip. We can measure the on/offs for those across multiple pixels. We can combine them, and then that’s another quantum unknowable. We can never predict when a single photon triggers an avalanche.

There is no quantum computer being used to generate random numbers. You’re just doing the quantum processes and diodes and things.

You could use a quantum computer — super inefficient. We’re generating tens of gigabits per second, which is far beyond the hope of a quantum computer.

Right now, you would never have the access. That’s good.

We support the people doing that. You can actually get a true quantum random number by running a random circuit on a quantum computer. That is a valid way to do it. But of course, you’ll never generate a key or two a day — not very useful.

The follow-up I wanted to talk about with this approach is, you have this custom approach, and it’s for critical data. In the NSM-10 memorandum — the White House memorandum — they talk about not buying post-quantum solutions until after NIST publishes its standards. But it’s OK to buy them to test, but not implement them. How does that kind of thing implement if you want to work with a government agency? Do they do the small testing phase with you as a result of that decree?

The versions out there now will tell you a lot about which systems are completely incompatible, that will just not work. They will fail. A lot of the legacy systems we see today, especially some of the smaller systems on critical infrastructure, OT systems, they just won’t work. They have to be replaced. At the very least, you will learn what will work — the performance hit you will take, and maybe the latency you get hit with for running applications with, let’s say, this hybrid version of Kyber and RSA or something like that.

I’m not an advocate for that, only because we should have the final version and only use that, because we know RSA is quantum-broken. It’s something that would never have been implemented if we knew about this earlier. It predated Shor’s algorithm. We’re only looking at solutions where we absolutely know they’re secure or we know there’s no easy way to break them. That theory in itself has been tested in the last year, as you know, with Rainbow and Psych.

But even with Psych, it was brute force. That was one of the two finalists in the NIST competition. The point from NSM-8, NSM-10 and the executive orders is that we don’t know what the final version is yet. You can learn a lot by testing with them. But Psych was a hard lesson learned that Kyber may fail. I’m an advocate for it. I’m not suggesting we should not transition to it. We absolutely should transition off RSA, but there’s no proof of hardness — that it will last and be durable — which is the whole idea behind crypto-agility.

Psych had excellent security parameters, we thought, only to be broken by a laptop computer that was 10 years old. That means we need something better architecturally. We can’t rely on this mechanism again — this single point of failure from these older architectures we had to deal with in the ’70s and ’80s. We need to move on past that, which is what Qrypt advocates for: Switch everything to Kyber — we’re calling it ML-KEM now — and then everything else will fall into place.

With the hybrid approach, though, you’re technically allowed to roll it out in a private company, if someone wanted to, just like AWS has their hybrid approach, so they exist. I was getting a lot of questions after the big CRYSTALS-Kyber “hack” — I never viewed it as a hack. When you write the implementation of the code and then hack it, that’s not very exciting. Do you want to talk about CRYSTALS-Kyber and why it’s still basically safe? That was just a proof of concept of an attack, technically.

There are always going to be side-channel attacks, especially when you’ve written the software on a specific piece of hardware you know has certain vulnerabilities in it. With that version of it, we haven’t seen the dust settle on all that yet, so I won’t comment on that yet. But the final version of CRYSTALS-Kyber will have very similar performance characteristics to that one — maybe even better than that one — and then we’ll see what happens. Until you deploy this on millions of processors, millions of laptops, millions of phones, you won’t find all these bugs.

Again, it’s not easy to go from a side-channel attack where you have direct physical access to the hardware to something that can be done remotely. That happens. If that’s possible, that’s something that needs to be fixed before it’s widely deployed because, as you know, people deploy libraries, people deploy systems, and don’t patch — sometimes for years. If we let that happen again, that’s why the government is saying, “Wait” — that’s partially because Psych fell. That’s excellent advice.

The hybrid approach, having RSA in this current version of Kyber is better than nothing. But, again, we have to transition to a world where there’s no RSA inside — it’s just Kyber — and everyone needs to adapt because we want these performance systems to work. We don’t want these hybrid systems that slow everyone down, then they don’t want them — they turn it off somehow, they drop down to an older version of TLS, which has happened before.

Sometimes I feel like it’s just to get a headline — for example, the latest version of Chrome. Like we said, it does have the hybrid solution. But for that to work, it’s got to talk to something on the other end. I don’t know how many websites, I don’t know how many servers, you’re reaching out to are actually going to do that. I would bet the number is incredibly small. I haven’t seen a single thing written about it, honestly. I will have to dig a little deeper, but I haven’t seen anyone say, “On our end, we’re supporting it too,” but it is nice to know it’s there. Whereas with Signal, it’s more of a complete end-to-end. You have the latest version of Signal, you’re good to go. That’s impressive.

Are there any industries that are more excited right now about rolling out this kind of solution you have?

It’s telecoms, banking, critical infrastructure and government, because they can enjoy a higher level of security you can’t get with just a basic transition from one older classical algorithm to a quantum one. People have been testing QKD systems for years. The NSA’s objections seem insurmountable right now — that they will not allow it on federal systems — which is a problem because it has very good characteristics we would like on a network.

Unfortunately, it’s cumbersome to deploy because you need physical hardware at the end point and you still need that authenticated classical channel. That’s the NSA’s main objection. But that doesn’t mean we shouldn’t incorporate it into other hybrid systems that use both PQC and QKD. For us, we see this as the time to figure this out quickly.

Going back to an earlier point, don’t buy systems that will be incompatible. Make sure the version of Signal that has PQC works on some of these devices. That’s a simple, easy way to test it. You’ll see if there’s a performance hit on those systems. Use the version of Chrome that has PQC built into it for some web application you’re using. If you’re both using the same version of Chrome, you will have a PQC connection, and you’ll see what happens. It might not work on an older laptop, but then, at least you know you’ll have to budget for that next year or the year after that.

Those industries, again, where the valuable data is, it’s like Dillinger said: “Attack banks because that’s where the money is.” That’s what hackers do, and nation-states — they go after the banks, they go after government data. That’s why the government is so obsessed with it, forcing this on everyone else. That’s the entire logic behind HR 7535 — every government agency must transition to post-quantum. That means all their vendors: If you want to do business with the government, you have to be quantum-safe. That means all the software and hardware that you integrate with the government — because they don’t build these systems anymore — has to transition over the next 10 years, which is unrealistic. It’s going to be 15 to 20 years.

Have any regulators talked to you on the private side, like X9 or something like that? Anyone who’s expected to start hounding all their constituents in the coming year?

I’m a member of X9, and the quantum group we work with — the larger team with mostly the financial industry, the big banks there — we did a study we finished two years ago that laid everything bare for everyone to understand, “What is quantum?” “What do these algorithms mean?” “What does a quantum computer do that a regular one can’t do?” and so on, to educate the community. Now we’re going on to the next step, which has not come out yet, but there’s a questionnaire where you can ask yourself, your CISO, your network architects and so on to answer these questions. These are simple things to go out and start planning for getting crypto-agile: What does the transition look like? When do I need to budget for this?

It’s starting. Those standards organisations and Addis, again, on the telecom side are all doing something in the space because they want to get aligned. You need all the banks and all the financial payment-card people to be on the same page, or you can’t do transactions. If you’re on a classical certificate-based system and signatures, you can’t do a transaction with a quantum that is insisting that everyone use these post-quantum signatures. These are incompatible things, and that’s a huge problem for that industry. There are things like bridge certificates and so on, which is outside of my domain. But the complexity of transitioning will take a long time simply because the internet was tiny when we did this last time, 20 years ago. The scale of digital networks, the cloud, none of this stuff existed. Now we have to move all that in 10 years. It’s going to be tough.

It’s an opportunity to start thinking about correcting structural issues from the past too. As we think about a quantum internet one day, can we avoid some of the flaws? In some ways, when you look at internet attacks, they all feel like when you used to click on a phone to get it to dial for free at a pay phone or something, because it was all the same signal path, everything was being sent, trusted, over the same pathway. That’s why your company’s approach is interesting, separating out that key spot, key moment, and then having the transfer occur. I wanted to let our listeners know some of the stopgap post-quantum things that are in the works right now until we get these standards any day now or any month now, but very soon.

I was just in Europe and the U.K. for their big quantum conference there, and you mentioned the quantum internet, which they now object to. They don’t want people thinking we’re going to have some huge QKD network that connects people and moves data around, and they’re trying to get away from that concept. One of the speakers at the conference was from British Telecom. They want to start thinking about this as a longer-term transition from what we do already today, just at a higher level of security, but not that almost-esoteric belief that it’s truly quantum, secured by the laws of physics, which it will never be. Quantum internet will exist. It’ll just connect quantum computers together, not moving around information the way people think. We’re not going to have a quantum handset.

Of course — that’s a key point. Quantum networking in general is something people don’t understand. They don’t get what it is. It is, like you said, more about what we can do and how we can connect computers and get performance gains from that too. Frankly, that’s what we’re hoping to get.

This was a great conversation. Thanks so much for coming on. Maybe we’ll end up talking afterward, on the other side of the NIST standards, and see what happens when everything settles there.

We’re testing. Everyone’s trying it out now. It’s coming fast and furious. Like you said in the beginning of the show, 2024 is going to be an explosive year for this. It’ll be people using companies using this as a differentiator: I have a quantum safe solution. You don’t. My application, my service, my web app, whatever it might be, is quantum-safe, or it’s not. It’s very exciting. We’ll be catching up in probably six months, then.

Now it’s time for Coherence, the quantum executive summary, where I take a moment to highlight some of the business impacts we discussed today in case things got too nerdy at times. Let’s recap.

Qrypt has been working on bringing practical post-quantum cryptography to market for about five years. The company has offerings that will work before the expected standards from NIST. Dennis feels that the NIST target date of 2024 for those new standards is still looking good, by the way. This means all the timelines we’ve discussed on this show in the past are still expected to kick in for federal agencies, and likely for financials and other regulated industries soon after.

Some businesses can expect to have to do cryptographic inventories and create remediation plans relatively quickly. Then, as these companies work toward a remediation deadline of 10 years or so, they’ll have to adapt to the deprecations of ciphers that will occur, and some legacy systems will have to go, as there will be no path forward for them.
All this takes time, but what can you do now to protect critical communications? Signal has already implemented hybrid post-quantum cryptography, which is when you wrap today’s encryption with a post-quantum finalist. Some people rely on Signal to literally save their lives in certain parts of the world, so it was an industry-pushing move for the app to add these protections. Google Chrome’s latest version has hybrid support too, as do certain cloud environments and workloads.

AWS pioneered this internally for their customers, for example. Qrypt offers a solution that creates truly random keys with a quantum device and uses the cloud to send those keys securely to end points. These symmetric keys can then be used by the end points to communicate over standard networks and send data in a way that is safe from harvest-now-decrypt-later attacks. The solution is more flexible than quantum key distribution in that the end points don’t need to be connected with a fiber and face distance limitations. But it is still very much for high-value end points that need to communicate point to point, like QKD. You wouldn’t use this for shopping online.

That does it for this episode. Thanks to Denis Mandich for joining to discuss Qrypt, and thank you for listening. If you enjoyed the show, please subscribe to Protiviti’s The Post-Quantum World and leave a review to help others find us. Be sure to follow me on all socials @KonstantHacker. You’ll find links there to what we’re doing in Quantum Computing Services at Protiviti. You can also DM me questions or suggestions for what you’d like to hear on the show. For more information on our quantum services, check out Protiviti.com, or follow Protiviti Tech on Twitter and LinkedIn. Until next time, be kind, and stay quantum-curious.