Podcast | Zero-Trust Post-Quantum Cryptography — with XSOC

Richard Blech: Where there’s critical or sensitive data, it’s going to be relevant. Of course, financial services, banks, insurance companies, where they’re archiving data for decades that’s also getting harvested now, we have some focus there.

Konstantinos Karagiannis: The migration to post-quantum cryptography is about to begin and is necessary to protect against the threats of fault-tolerant quantum computing. However, critical assets like those in military, banking and government environments also require other layers of security and strategies, such as zero trust and increased encryption bit sizes.

Learn about one high-performance encryption solution that provides such defense in-depth today, and will do so after thousands of logical qubits arrive, 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 cofounder and CEO of XSOC, Richard Blech. Welcome to the show.

Richard Blech: Hello. Great to be here. Looking forward to this.

Konstantinos Karagiannis: Our listeners have heard, of course, of the coming NIST standards and the need to migrate away from RSA and other ciphers. This is the post-quantum world, after all — definitely something on people’s minds. But your company handles a lot more than the quantum threat. To start at a high level for listeners, what differentiates your solution from just plugging in new ciphers?

Richard Blech: XSOC is an acronym for “eXtensible Secure Optimised Cryptography.” What we set out to do, back in our founding in 2018, was to think from the classical side of computing. The post-quantum aspect of it came about because of the design and what we’re doing, since our focus is on symmetric cryptography. With that, we’ve been able to design cryptographic systems around key distribution and security and other aspects in an infrastructure where we have optimised cryptography, some of those being building blocks or primitives and standards we’ve put into what is a crypto system.

When I say “crypto system,” we’re not just talking about an algorithm or a cipher. Though there is a cipher, there is more around that. What we’ve done — and this is, again, speaking from the classical compute side — is have this very high-performance cipher core encryption engine that delivers performance, security and a lightweight footprint with symmetric cryptography.

The cryptosystem is a hybrid of a stream cipher like ChaCha-20 and has block cipher characteristics and attributes such as an S-box that help alleviate some of the weaknesses that are inherent with your typical stream ciphers. This has all been through cryptanalysis and, of course, testing and R&D. That’s why it takes the time it takes to put these together. The core of the encryption cipher, by the way, has been put up on GitHub for academic review, but where we put all the muscle into this, where it becomes a differentiator — and why it can be used now while the NIST standards are getting approved, which is an asymmetric side — is that we put various interfaces that handle all the use cases pretty much that the industry could think of or want to deploy.

Those interfaces are in the form of user-accessible, that they would invoke through a command-line interface in the form that it is now, or the original form, which is a Java SDK, small footprint, 235 KB on disk. The entirety of the code base is 4,000 lines of code — very small, tight. You can operate this from a command-line interface in Windows, Linux or Mac, even an ARM processor, cross-platform. With that — with two lines of code from the CLI — you’re up and operating. Then you choose your various functions and use cases and parameters. You can encrypt a string, you can encrypt a stream, or you can encrypt text, voice, whatever that may be. Then you have all kinds of other choices to use that allow for security now in classical compute. Because of the strength of the cryptographic security we built into the key, you have post-quantum security properties as well.

Konstantinos Karagiannis: We’re going to dig in to the different components and how it works. But I thought it’d be fun instead of just continuing on with drilling in to immediately give people an example of how even now, before there’s technically the quantum threat actually happening, although you have harvest now, decrypt later, there are breaches that happen all the time. There are things that go on now in the security world. Take an example of a recent high-profile breach, and then walk us through how there could have been a different outcome if something like the XSOC solution was in the mix.

Richard Blech: There are a few. One that’s not as recent, but not that far back is, of course, SolarWinds. That affected everybody. There would be impact there for sure. There were things that we would do from the access-control side — the XSOC key, where there’s a real differentiator, has MFA credential capability within the encryption key.

There’s enough space in the XSOC key that allows for the knowledge factor, the possession factor: the CAC card, the PIV card, the YubiKey — whatever it may be — biometric- and machine-inherent CPU ID or some other device ID to be integrated into the encryption key itself, meaning there’s one key without reliance on PKI or other asymmetric standards — that you would have an MFA-enabled key. That means the decryption could only occur to the authorised, authenticated, validated party. Thereby, I believe that would not have occurred, or certainly would have mitigated a significant level of that breach. A more current one, Cencora, was a similar circumstance, and that was a big one.

Again, it’s all access control. Encryption does so much. There are reasons you don’t encrypt, which are inexcusable from an XSOC perspective, but a lot of it ends up being implementation detail and human errors, why these breaches occur. We built something that’s a little bit easier to deploy and use, which is a big factor — and then, adding the MFA credentialing in, which is where a lot of these breaches occur, is getting through access controls and getting to where the data is residing, and that’s where the compromise occurs. We think we’ve developed a solution that at least can mitigate much of that.

Konstantinos Karagiannis: In many ways, this solution solves a lot of the things you worry about in security and tightens security in, let’s say, an organisation, because you’re not going to use this to shop at Amazon probably. This is going to be something a company would roll out. It would strengthen security, and it also happens to be post-quantum-safe as well.

Richard Blech: That is correct, and it’s because, again, with symmetric cryptography, it’s not prime factorisation, computationally based. It’s about key length. The known attack against that is Grover’s algorithm, and the quantum computer would half the key size. The standard out there now is that the key length must end up being 256 bits of security. That could change too because we don’t know what we don’t know yet. We started at 512, and we did it at 512 because we’re efficient — we’re faster than AES. Even with the hardware acceleration AES enjoys, we have a software solution that outperforms AES even at large key lengths with large files — significantly, eight to 10 times faster. Because of that, we can go with these large key sizes, and that has that post-quantum security because of that. There are other factors too, but that is the main one.

Konstantinos Karagiannis: I want to dig into how you handle keys because it’s interesting. We’ll focus on that. To help listeners understand the approach behind this type of defense in-depth, maybe we can go through it in layers as a guide to what’s coming. I’m thinking of it as data at rest, data in transit and data in use — they’re all different pieces here. Can you walk us through that — how it starts, how each is impacted?

Richard Blech: Again, it’s a crypto system that is meant to have the tools available. You can work on all the different data types: in flight, at rest and of course, in use. That is, again, set by the parameters you decide, what you want to set out for your particular use case or in your environment. The first way, right off the bat, is all about the entropy. Entropy is a key ingredient to strong encryption, of course. That software, it’s CSPRNG. That is a standard that’s available from the Java library. We’ve also adapted the cryptosystem to intake entropy from any quantum source for QRNG. It could be a diode laser light, whatever that may be, that provides that randomness.

From there, we get strong entropy. We’re starting off right away before anything else happens. Then we initialise the encryption job in less than a millisecond. That’s why we have a big step up in performance, because the initialisation is so rapid. Then, on the actual encryption, there’s only a few cycles per byte, so everything is moving efficiently.

If we work on data at rest, that’s just a choice. You choose your parameters and you’re going to pick a large key. Our key sizing goes 100 increments up — not because it needs the strength to go up there, but so you can have choices and you can set parameters and you can have more randomness or variableness to your choices. That means 51,200 as a full key-space size. The key is static — it stays static, 23 KB on disk. Regardless of the strength inside, it’s dynamic inside the key.

Inside the key, there’s a delimiter algorithm so that when you move the key size up, there’s more secure key material and less padding. If, at the 512 bits of cryptographic key strength, you have that in the key, the remainder of the key space is filled with padding and obfuscation. An adversary does not know where the secure key material starts and ends and the padding starts and ends. Even if they did, they would have that security strength to deal with. This is just an additional factor, another point of difficulty for an attacker to go at.

We can also modulate the key as well, but that’s for the second part of the use case, just to finish on data at rest. You could choose a size of, say, 2048 or 16,400, and that’s your data-at-rest key. For archival use cases, or you’re an insurance company or a financial service — you’re storing data for 40, 50 years. It’s all going to be usable data. There’s data harvesting going on now. You want encryption strength in there that you don’t have to pull down in 10 years and have to re-encrypt everything, because that’s quite a job. Nobody wants to do that, and you may have to do that by mandate or regulation. Let’s start off right away and encrypt these large key lengths because it doesn’t affect your performance. You’re going to be able to decrypt just as rapidly as you could if it were a smaller key. It affects nothing on the performance for that.

That’s that use case, then the data in flight, because it is part of a streaming cipher, we can encrypt a video or a voice stream or whatever at every packet of data. If you chose to rekey at every packet, you could do that. We could rekey every nanosecond with a different key size, a different unique key, and you could change the strength as it goes down the stream. One of the important factors of the streaming encryption that is real-time is that it has a self-healing feature, or what we call spin forward: It has 100% reliability, and there’s no packet loss, because the crypto system knows to catch up wherever there are drop packets.

Now, in a voice call or video, that’s not that important because you’re not going to notice that, but in data at rest, if you have one packet missing so that the whole file is corrupted, you won’t be able to use it. We need to have that reliability. That was thought out, and we put that in. That’s streaming video, live video. We have fidelity across. There’s no effect on the video quality and a real-time stream until you get way into the upper bounds of the strength — then there could be a little jiggle. But we’ve tested all the way up to 16,400-bit strength, and there is 100% fidelity with the video quality and sound quality.

For data in use, that’s always the tricky one because there’s a lot of marketing hype around homomorphic encryption. I’ve used the term pseudo-homomorphic when I’ve discussed data in use. We have a database solution too, where we have a mode that is a headerless mode. That allows us to encrypt in database — SQL vector database for AI — where we’re not appending any header that adds any overhead or encumbrance to the data that’s being encrypted.

We can encrypt at the column, row and cell level of a database. However, there’s metadata that’s still existing. With that metadata, we’re able to query the database. Say you have all the data in an S3 bucket, for example, in AWS. You can then query that database from a backup file from somebody’s workstation at your facility from three years ago. You need to just pull a file down. Rather than decrypting at the database level or pulling a whole bucket down, you’re just pulling the file down, encrypted, and then you’re decrypting it to work on. That’s why I say “pseudo-homomorphic,” because you can query it and find it and get it and retrieve it and bring it to you. But when you actually have to work on it — like, write text — you’re not writing it while it’s in an encrypted state. Unless you’ve got eyes that can read cipher text, you’re encrypting at some point.

Konstantinos Karagiannis: It’s important because obviously, that brings in discussions about roles too, like role-based security — you shouldn’t have everything. Depending on what your role is, you might just need one kind of file that we have access to decrypt and read. How does this work with something like AI vector embeddings? What’s the security threat you’re fixing there?

Richard Blech: With the convergence of quantum computing coming, put those two together and maybe you have something that’s not even thought of. You know how the world and the market has changed. It’s always evolving with technology. It was just a few years ago that quantum computing was 15 years away. Now it could be right on the horizon, or just a few short years away.

Even then, a few years ago, no one was talking about AI as much, working with quantum computing. Now, things are changing. This is what happens all the time. The threat on the vector database level, that’s the core of everything that’s going to be AI. It’s great to have ChatGPT, and you go in and you can ask questions and it can write some things for you. But now, with AI going to be involved in daily lives of everything and all these military operations and drone technology — something we’re working on extensively — these are going to be personalities that are going to be out there functioning in the world, and we, as a society, are going to rely, in some cases, on emergency services, on what AI determines.

If that gets poisoned or corrupted or interfered with in any way, even with split-second timing, this could be not only catastrophic, it could also be cataclysmic because of the chain reaction of events that could occur. Think, on a large scale, what could happen if you start disrupting AI in its objectives of what it’s supposed to do and you change what it was going to do. It’s like the butterfly effect. Protecting it at its core, where you can encrypt, and it takes complete lack of latency to interfere because everything is about timing, or any encumbrances — you want all integrity and fidelity at all levels.

With what we’ve developed with our crypto system and our ability to deliver keys efficiently, that allows us to be encrypting at that level. We believe we can be an anchor core, securing the vector database and its embeddings, storage level, storage layer, application layer, and that will significantly enhance the security posture for AI. That’s what our position is.

Konstantinos Karagiannis: People can visit your site from the show notes and see if they want to get a visual sense of what this looks like.

Richard Blech: Not only do we have the pictures, but we also have a bunch of blog posts that explain, what is this technology? What are bosonic codes? Where are the microphoton stores? These kinds of questions as well.

Konstantinos Karagiannis: If you’re doing something critical with AI, like piloting automated drones or something, maybe you don’t want a good look at what that looks like. Maybe you don’t want to offer that to the world. It could get literally deadly. It’s pretty scary. I can see the benefit in that.

I want to dig a little bit into symmetric encryption and how you handle key distribution. Let’s give an example from the QKD world: You set up your BB84 protocol or whatever, you have your photons of light, and through the establishment of a classical channel, you agree to build up key data in QKD. You transmit these photons and you end up with a key. It’s a onetime pad, but it’s small, it’s slow. You take that and you use that to send what’s going to be the key to the symmetric encryption, which will then be what you transfer. That’s how you do it with light. How do you handle key distribution in a secure way with this setup, when there is nothing like a light channel that will detect quantum weirdness happening and you have to throw away the key? This is just basic bits running over a wire. How do you handle the key distribution?

Richard Blech: There are a couple methods. There is a key distribution system solution, and then there is without that. I’ll explain the first without that, because then it’s just a matter of however you want to deliver the key. That is the key I was explaining previously with the MFA enablement. If you have enabled the XSOC key and you have injected those three factors of authentication into the key — and, by the way, the key is large enough that you could have multiple parties using the key and reusing the key — your MFA credentials can be in there, mine and others, and you could share that key with those parties. Decryption can only occur when you are on the device, have the physical factor and have the knowledge factor. You don’t even need an HSM, and you can just deliver the key.

Yes, it’s an extra step. Yes, there’s enrolling. But you can do that and not have to involve any additional secure key distribution system. For those that don’t do that, a solution for delivering symmetric key — and this could be any symmetric key, not just an XSOC key; that’s how we built it — it defaults to XSOC. But we can take in any symmetric key. In our system — it’s called SOCKET — it contorts that key into a 3D object. We get geometry involved here. That key then spins at a certain speed, variably different each time, and it pitches and it yaws.

The calculus of that is put on a primer. The primer goes with the cipher text, and the key is basically exploded into shards. Those random shards are distributed around an RF, for example, an ad hoc, air-gapped environment — doesn’t matter — LAN environment. We’ve used this on Raspberry Pi’s, even, so, low-power, low-compute. There’s no storage of any key shards. They’re just pinging around an RF mesh network and then get recombined. All this happens in milliseconds at the endpoint, which is authorised and authenticated with those three factors because it has to go to an endpoint, and the endpoint needs to be authorised.

That’s how we securely deliver a key in a LAN environment. Because we built in a protocol called Encrypted Broadcast, which has a UDP backbone, we are able to unicast, multicast and broadcast that key in that network. If we’re going to use the internet, that same model can be exposed on a global basis using DHT hash tables in a peer-to-peer environment, meaning anonymous nodes get that key material and ping it around the globe — all, again, in milliseconds — then it goes to its various endpoints for authenticated decryption.

Konstantinos Karagiannis: In many ways, there’s not much you can do with those shards if you’re not one of those devices anyway.

Richard Blech: It’s a zero-point failure solution. There’s nothing you could do with it. You have to be on the machine, on the device, and have those factors there. You can think much more secure, or n tier. Kerberos is the way some have looked at this, but it is much more efficient, of course, too.

Konstantinos Karagiannis: How does that approach affect performance? It sounds like it doesn’t.

Richard Blech: It’s built to move as fast as the internet. If you’re using the global one in a mesh network, you’re right at the network speed, whatever the network is we’re working at.

Konstantinos Karagiannis: What types of companies and sectors would benefit from this?

Richard Blech: Whether it’s critical or sensitive data, it’s going to be relevant — of course, financial services, banks, insurance companies, where they’re archiving data for decades, and it’s also getting harvested. We have some focus there. Military, government, of course. There’s been a significant uptick and focus on drone technologies, drone operating system, AI, involvement in drones. Now, for drone communications, this is the way the new warfare is going to be going: less human, boots-on-the-ground involvement, more autonomous machinery involved: drones, ground vehicles, whatever that may be. This is all just like our automobiles now — they're all computers. Where there’s computers or sensitive data that’s moving to, that needs to be secured at a high level. That’s a big factor. Of course, telecom is there, technology and SaaS providers.

Then, of course, one of the bigger ones is critical infrastructure, where, certainly, we’re able to get into SCADA environments where we can be a bump in the wire, encrypting right off a PLC with sensor data going to an HMI. We can do this in the very low threshold of relay time, which is only four milliseconds. We’re well within that threshold to encrypt, decrypt. We can do it with the same schema I just discussed.

Konstantinos Karagiannis: Yeah, SCADA is a good point, because that somehow falls off. People don’t talk about that enough when it comes to quantum cryptography. You heard it a lot when it was the IoT buzz, but then it got quiet again. But people have to remember that there are all these devices you’re forgetting about there. Once the post-quantum poop hits the fan, what’s going to happen?

Richard Blech: It’s been reported pretty widely now: The Chinese have come into this country, and they’ve set up shop, and they’re on our grid, they’re on our critical infrastructure. Whether they’re inside or not, that’s going to be the way they go about fighting wars: shutting things down and interrupting things. Who knows when, but it will occur. They don’t need to fire missiles and shoot bullets when they can shut down the grid or affect the grid. This is not something to be ever taken lightly. We need to do everything we can. That means public- and private-sector collaboration to work for these solutions.

Konstantinos Karagiannis: On the topic of war and all that, I know it’s mainly classified, but what can you tell us about the military-drone contract you received?

Richard Blech: That is a convergence of current drone technology, adapting it for AI personas, that will individualise each drone for whatever their mission or assignment is. There’ll be AI involved. Some of these drones are actual suicide drones — I can say that much about them. They will be dropped from a mother ship — thousands of them, maybe — to go into their missions, and they’ll have AI that will decide various things: whether to retreat or kill itself, and what to shoot or reconnaissance, and whatever it’s doing. Our involvement is at the modular level, where we’ll be involved in the drone operating system itself for security, and then the drone communications: drone to drone, mother ship to drone, drone to ground station — ground station could be just a militarised iPad, for example.

One of the reasons we’re getting this is because the asymmetric use of cryptography is very complicated in that, as you can imagine, just because of the nature of the war theater or the environment. We’re able to use that XSOC key, that large key, as a public key in that respect, as an analogy. The TPM on the drone is the private key. The TPM will have the authorised credentials in there. When the data moves through the drone with the XSOC key and that meets the TPM, it will decrypt again — all no overhead or latency issue. That’s how we’ll have the security level. We’ll be at a modular level and through the military drone architecture.

Konstantinos Karagiannis: You don’t want to give some attacker the ultimate video game experience in the future. These things need to be part of the CIA triad, for sure. With us heading to Q-Day, everyone’s worrying about mass migration. How easy is it to roll something like this out? And how crypto-agile would it be going forward?

Richard Blech: It’s about having scalable architecture, and that’s based on the performance and the ability to integrate and be cross-platform. As long as there is a place where data is ingressing and egressing, we can be placed. We’re in Java now. We’re going to also go to the Rust language, which is going to allow for even more performance, if you can believe it. It’s pretty impressive, and we can even be lighter-weight. That’s what new languages can do. The U.S. government is going to phase out the C language because of its security vulnerabilities, which are now well-known. Rust is one of the acceptable ones, and we’ll be going to that. That becomes interesting. But because of scalability, because we have the performance, it’s very adaptable and has all the agility components built in so we could scale.

Konstantinos Karagiannis: WWe’re going to have the website, obviously, in the show notes.

Are there any kinds of demos available for companies if they want to reach out?

Richard Blech: We are opening up shortly here. In fact, there’ll be a video of our SaaS version of this, where we containerised that Java version, and it will be available in AWS as a SaaS offering. On the website, there’s a couple of videos of demos that are a little techy because it’s a command-line interface, but we do have that. But there are lots of resources on there. We do have some white papers as well — lots of information available. Anyone can reach out and request further information, and we’re always happy to provide a live demo as well.

Konstantinos Karagiannis: If you’re interested and you want to take a look, you can see it and maybe even have something interactive.

Richard, thanks so much for coming on.

Richard Blech: Thank you very much. It was a pleasure.

Konstantinos Karagiannis: 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.

XSOC relies on strong symmetric encryption at its core. Although symmetric approaches are normally thought of as encryption for data at rest, they can also be used for data in transit if keys can be securely sent. XSOC has a fast way to do this, allowing even encryption of streaming 4K video. XSOC uses a hybrid of stream and block cipher techniques with an expandable key space ranging from 512 to 51,200 bits. This allows for high levels of encryption if data has to be stored for decades, for example, without a need to re-encipher in the future. XSOC initialises in less than a millisecond, and the company says its encryption and decryption speeds are 10 times faster than AES 256. Keys are distributed and rotated with a unique zero-trust system. XSOC has FIPS 140-2 certification and was selected for a military-drone classified project.

We all have to migrate to PQC ciphers. I view this solution as an extra layer for critical environments.

That does it for this episode. Thanks to Richard Blech for joining to discuss XSOC, 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.