Stefano Gogioso - A full-stack compiler for quantum cryptography

we stay on the track about quantum but I don't know if we have to change some slides uh in the meantime I will introduce the the panel may I

okay of course

thank you so much my queen uh actually we are talking about uh uh the talk focus is about an accessible deep dive into never local full stack we have in the meantime if you want to scan this QR code we are launching a crypto talk show in television soon in se from September. So if you want to follow us, you will we will you will find us on the TV show, on social media, etc., etc. Uh actually she saw the slide. Here we go.

In the meantime, I will introduce you and I suppose you are Stephano. Nice. But and by the way we are talking about an accessible deep dive in in never local full stack development in computers uh in complier right for for quantum cryptography. Stephano, our panelist that we we are going to introduce later, uh will outline how classical uh cryptography protocols and uh are translated into secure quantum implementation uh down to the hardware level. So I think you are going to talk about uh uh you're going to walking in through the uh the design architecture, right?

something like that a little bit introduction highlight how security parameters are optimized and so do you want to introduce our panelists of course

of course you already said his name but I'm going to repeat it so talk a full stack compiler from quantum cryptography please a round of applause for Stephano Goso mathematician and computer scientist

thank you very much

thank you everybody so I presume I'm using this microphone Cool. Yes. Um I will start uh today's presentation. I will actually start by putting uh Yep. There you go.

So I know what time it is and I don't get lost into the details of of quantum things. Uh so yes uh hi I am Stephano. I am from Never Local with Fabitio and Lev who are both there today. Uh we have some other colleagues that are traveling and are not at the conference with us. uh and today I'm going to briefly introduce how the basic principles of quantum cryptography which is as I will discuss different from postquantum cryptography names are similar but very different things and then I'm going to talk about how we plan to make this accessible to classical crypto cryptographers without a quantum background without the quantum specialization by implementing a full stack compiler for it.

Um so first things first a few watts about quantum there's many quantum things and it's good to start by distinguishing between quantum computing which is a different class of computing. It uses large scale quantum systems to perform computations which are hard uh such as breaking elliptic curve cryptography and the public key cryptography that we use uh and that's different from quantum cryptography as we do it and it's different from what Ian talked about in the previous presentation which is postquantum cryptography. So postquantum cryptography is a branch of classical cryptography. It's about developing classical algorithms which are resistant to attack by quantum computers. So it's not using quantum resources.

It's defending against quantum resources. It's the defense side of the business if you will. U what we do uh primarily at Neverlocal is quantum cryptography uh defined as using quantum systems to implement cryptographic primitives that cannot be implemented classically because there are properties about quantum systems that classical systems don't possess. Some of them are useful for computation. Some of them are useful for cryptography.

And this was clearly a sensitive topic and I've been censored. Um, do I need to do anything to make it come back? I can sing a song in the meantime if you want.

Well, I mean, I can just go over the over the next slide by heart. It's a It's a bunch of writing, so it doesn't really matter. Um, so yeah, what we do is quantum cryptography. It's using quantum purely quantum resources specifically a property of quantum systems known as contextuality which is what makes quantum quantum in in a very specific sense to implement new algorithms and new protocols. The when is also very important.

Uh Ian kindly gave some uh deadlines for postquantum cryptography. That's something that we should start doing now because quantum computing is not going to come next year but it's going to come in let's say two years in the worst case scenario five years seven years that's roughly the window. It's not it is coming. It's not something that we can really um ignore right now. It's not 10 20 50 years away.

Uh for quantum cryptography though the interesting thing is we have the equipment today. In fact, the simple protocols that exist such as quantum key distribution are already implemented are already deployed on networks mostly test networks uh and there's businesses that are dedicated to businesses such as marks uh very cloud uh with with whom we we partner are dedicated to making these applications real today. So one of the big differences between quantum computing such as IBM, Google, uh quantinium, Betti and quantum cryptography as we do um and veric cloud does is that quantum cryptography is near-term. It does not require large systems. It only requires precise control.

It requires good equipment uh miniaturized presentation of the equipment and packaging. Fiber optics, no problem. fiber optics, but it's something that we can already do and we will indeed after my presentation will go and finish setting up a small experiment. That's roughly what you need to do for a small protocol. So, it's it's something that uh that you can see and touch right now.

So, what is it that makes quantum useful for cryptographic purposes? Um quantum computing, quantum mechanics, quantum information is fairly complicated overall. But luckily, the resource that's useful for um cryptographic purposes is fairly simple to describe and it doesn't really require you to know about the quantum systems themselves. It only requires you to know about what they do when you measure them. H and that's very useful.

Uh it has a very interesting consequence. But the first simplest example that anybody in quantum information introduces is something like the Bell experiment where you have an entangled state between two parties, let's call them Alice and Bob. They perform some measurements on their cubits. They have each of them has a quantum system on their end. They can do one of two measurements.

They select these measurements very carefully. Um there's two very specific bases that they have to pick. They do so randomly. So they use a little bit of local randomness which is easy to generate uh to decide which measurement to perform and what they get out of the system out of this local randomness is correlated randomness instead. So a quantum experiment a quantum cryptographic protocol is in simple terms a way to turn coin flips which you can do securely in your own home into something which is harder to achieve which is randomness that is shared between parties.

Uh why is randomness important? Uh well randomness means in a certain sense security as long as it is not just random to you but it is random to the attackers then it could be used to provide security and correlation is useful because otherwise you just have local bits that have nothing to do with each other. For the bell experiment the bits that you get are not perfectly correlated but almost perfectly correlated. And so they could with a little bit of modification be used to do something like key distribution. In fact, this particular experiment with some additional subtlety, a very minor modification is what's used to do quantum key distribution in its simplest form.

The important part uh is that you can prove exactly how much actually up to how much of this randomness could be predicted by any attacker. So this is not just an attacker who has understood the protocol. This is any attacker who is bound by the laws of relativity. As long as they cannot send any signal faster than the speed of light, which we believe to be physically impossible, and that's a caveat, you have to uh make that clear. Uh only 58% of these randomness can be predicted.

The remaining roughly 42% of randomness can be distilled and used potentially to implement some uh early version of quantum key distribution. So this is the simplest example of security that could be guaranteed just by the laws of physics. You do an experiment, the laws of quantum mechanics allow you to get these correlations and the laws of relativity stop any attacker from gaining information or limit the amount of information that an attacker can get. And the caveat is that the randomness you get may or may not be useful. If you find interesting applications then this is an example of contextuality a purely quantum resource turning into security of cryptographic protocols.

So this example requires some refinement to become quantum key distribution but there's a very simple generalization that is immediately out of the box perfect for cryptographic application which is merin's experiment. It's just the next the next stage instead of having two people you have three people instead of having a bell state you have what's known as a GHz state. But the principle is the same. They each measure in one of two possible bases flipping a coin locally. Uh which is easy to do.

And again they get a bunch of potential outcomes. So depending on whether they picked uh xxx basis xy yxy yx they get different bits with different probabilities. And the fact that these are random is important. Uh because if they're not random then there is no security to be had. Uh but the important part for applications is that they have a very specific very strict property.

They always have a deterministic sore. Either they all sort to zero or they all sort to one. They're random uniformly so but their sore is deterministic. And so you think if you're a classical cryptographer, you think what kind of protocol do I know that could use this kind of randomness? And the answer is secret sharing.

Secret sharing is a classic example of a protocol where you want individual bits between parties to be completely random. But when they all get put together because the parties agree to reveal their secret then they have a deterministic sum which unlocks whatever shared secret they had. This is the basic idea. The protocol itself is a bit uh I mean it's not very long literally they measure things. Alice uses the her bit to secure the secret.

Let's say Alice is the dealer of the secret right here. And then Bob and Charlie have to agree to reveal their secret bits in order for the secret to be decrypted. And so in the decryption, all they do is just exor the secret of Alice, the secret of Bob, the secret of Charlie, and the secret bit. And the original encoded plain text gets revealed. It's a simple protocol that comes just from knowing that you have some randomness that has a specific property.

Nothing else. And that's quite important. It's the key of designing this class of quantum cryptographic protocols. uh for this particular example we get a lot better than for experiment exactly 0% of the randomness in the ideal case when there is no noise but that's the important idealized situation can be predicted unless you break the laws of relativity again so this is an example of a maximally contextual protocol so a protocol where an attacker cannot really extract any information except through noise so this will be a um a theme that will recur. Noise in quantum cryptography is always universally adversarial.

Noise means opportunity for attack. You do not know if the device is just badly fabricated or if the device was tampered with by an attacker to make it reveal some of the randomness by not performing exactly the protocol you wanted. But you don't care. The important point is the particular way that these protocols work. You look at the noise.

If it's below a certain threshold, you get a certain amount of security. So, as long as you want more security, you just lower the noise threshold. Worst case scenario, the manufacturer cannot produce a device that can meet that threshold, in which case your protocol fails. But in which case, there is no technological way for you to achieve that level of security yet. But it's an engineering challenge, not a mathematical one.

Um, so it's a good starting point. And indeed in this case if we can implement this to sufficiently high precision this does give us security guarantees for this particular protocol for secret sharing guarantees that come solely from the laws of physics. There is no other assumption. It's not uh until somebody finds a loophole until somebody breaks it. If you implemented the protocol wrong sure but other than that the laws of physics are what guarantee the security here.

And so we have two examples that kind of meet the same shape. And this is the secret to understanding how quantum cryptographic protocols of this class and many other classes in fact work which is that you need two ingredients. You have a random part which is where the potential for security comes. If it's not random then where is the security? The attacker can know beforehand what the bits will be and this has gone somewhere else.

uh but I have fixed it and I think I've done something with the random remote and then you have uh deterministic part which is what you use to implement the actual protocol. So the randomness guarantees you the security and the deterministic part is a property that you can use to implement some nice cryptographic protocols such as key distribution or secret sharing. And the shape if you just look at deterministic shape don't think about the randomness because that's just for security purposes. All you need to do to ensure that the protocol runs correctly is test whether it meets that shape. The property that you are guaranteed that's a test.

If you get if you picked xxx, you look at the three bits. Some of these rounds you use as test rounds. You just reveal them publicly. They always have to sort to zero. If they don't, you count it as an error.

If you picked any of the other three combinations of measurements, they always have to sort to one. If they don't, you count it as an error. And then you go to the end and you estimate what your error rate is. You just randomly pick the rounds. If the error rate is lower than your desired threshold, done.

The protocol has passed. If it's higher, you fail. Worst case scenario, you've refused to do secret sharing, but you cannot be tricked into revealing a secret where an attacker already has the information. So, worst case scenario, these protocols fail, but that's the same as saying somebody cut the internet wire to your home. There's no difference there, right?

Availability is never guaranteed. There is no way to really guarantee it. But the rest uh can be guaranteed in this particular um setup. And so it is a rough relationship that security is proportional to success probability of these tests. The proportionality law is always complicated.

It depends on many factors. There's a there's a power and uh there's a constant that need to be determined protocol by protocol. But none of that you have to do. That's what maths and computers are for. The principle is the higher the success rate, the more secured you get from these protocols.

And a really really important observation is that we don't need to know anything about the implementation of the protocol. None of what I described requires knowledge of how the protocol was implemented by the manufacturer. Uh all I talked about was the exterior boundary, the interface where the quantum system inside the boxes become classical. And so we treat it as a black box. This is a slightly more complicated protocol with four parties uh and some communication in between.

Uh but all you care about is the exterior essentially just the boundary. So you care about the agents, how many people are involved in this protocol, how many devices are being used to perform this protocol. Um that's a B, Alice, Bob, Charlie, and Diane. Let's say uh you care about what the classical inputs to these boxes are. So the coins they flip and they put into the boxes.

Maybe they're biased, but typically they're uniformly random. Um, you talk about the outputs they get, the bits that the protocol generates. In this particular case, one bit per agent, but there could be many. And you talk about rather importantly, the communication structure between the agents. So, some protocols require agents to communicate.

In fact, most protocols in practice do require agents to communicate. Mermmin's example is not one of them. It's very simple. But general protocols do require some communication. But they also require rather importantly some lack of communication.

So a key component of ensuring security of these protocols is making it so that Diane cannot signal to Charlie and Alice cannot signal to Bob in each round of the protocol. Not necessarily across the protocol, but for every round when the protocol is executed, there should be some kind of no signaling constraint that is imposed on them. How you do it depends on the setup. This is what makes uh this kind of quantum experiments very hard in practice. It it's called a lucal free bell experiment.

H it's taken years to achieve the precision in timing of the operations that guarantees this by just the laws of relativity. So there's just been not enough time between the parties for them to signal while the protocol has been executed. But we don't need to do that. This is practical cryptography. After all, this is a crypto conference.

We care about practical applications. There are many other solutions. There are hashbased solutions that enforce a certain sequencing between the parties unless they can reveal the correct value. They cannot proceed or they cannot prove that their bit was generated fairly. But you can also use more sophisticated uh systems such as enclaves or tees which really like uh to enforce the sequencing to ensure that the communication doesn't happen or you can put your agents into farad cages under a mountain.

I don't know however you do it just ensure that they don't communicate between themselves and that's uh that's the only ingredient uh in guaranteeing the security and because we did this in the blackbox model because we don't care about the actual implementation this security is device independent it's not as device independent security it's a property that is unique to quantum cryptography classical systems cannot achieve it there's no way to do it classicalally uh it literally means you do not need to trust cost the quantum hardware manufacturers which is very good because it's very hard to evaluate quantum hardware in general. It's not something that first of all it's technically challenging. Uh secondly it is you cannot really run it and debug it because the point of quantum systems is that you need to measure them at a specific time. If you look at them while they're running you're going to collapse them and the quantumness will go away. The contextuality will disappear.

And so the lack of trust was considered an important demonstration principle uh in the beginning but actually for security it's it's an incredible property. There is no supply chain attack for these protocols. You can buy the device from the attacker. I don't know pick your favorite intelligence agency that could be against you and as long as the test passes with the high probability that you require for your confidence level then you know that the security is there. you don't care who made it.

They cannot back door it essentially. Um so test two ingredients really the only two things that you take away from this. There's a test which needs to pass that defines sort of the deterministic shape of the cryptography and there are some constraints some communication restrictions that need to be enforced between the parties. However you do so up to you. Um and then security is provable.

It's a mathematical property of these correlations that they cannot be back door. So this is a fairly unique property. That's convenient and nice and interesting. But perhaps you do trust your hardware manufacturer. Perhaps you are the hardware manufacturer.

So why would you care about device independent security in that setup? And um I'm just going to talk about it. So the if you do trust your hardware manufacturer because maybe you manufacture the hardware device independent security still has a lot of implications in terms of protocol implementation and the kind of pain points that that people experience implementing these protocols in real in real life. Uh I can I can tell you Mark can tell you implementing these things is not easy. It takes a lot of uh a lot of compromises and there are a lot of things that can happen between point A and point B.

It's not quite as simple as using the internet. But because you have completely obstructed away the inside of the protocol, you get that you also don't need to trust the network that you send the photons on. Worst case scenario, the network breaks. Worst case scenario, the network changes the polarization of your photons or whatever encoding you use. your protocol fails but the network effects cannot be used cannot be exploited to weaken the security of the protocol.

Um you also don't need to care about fabrication defects. You don't need to know whether the chip was fabricated properly or whether there were some drifts and some imprecisions in the manufacturing. They will manifest as protocol noise. They will just add to the noise level of your protocol when you execute it. As long as that noise level remains low enough again you don't care.

It is part of the blackbox. it is part of the device independent uh setup and similarly if you have network errors and they are rare enough then you can also absorb them into protocol noise worst case you get a slightly higher noise and again all you need to check is whether it's below the required threshold and you're done so this removes a lot of the traditional pain points in protocol development there are a lot of things that people have to check when they implement these things when they execute them that in the device independent approach are not really issues because a device independent approach removes the need for them. Uh it's harder. That's the that's the that's the challenge. Proving device independent security proving doing this sort of contextual cryptographic proofs uh requires some additional subtleties from a theory perspective from a calculation perspective.

It is extremely difficult to do so and it is also gone away. I am going to try this myself. Yeah, I see some lights. There you go. Thank you.

Um, so yeah, there's um it's hard to do this for people for humans and there are very few very few people in the world, very few labs in the world that do this extensively. Quantum cryptography is already a fairly niche area. Device independent cryptography is an even more niche area and these kind of approaches are are fairly theoretical and fairly limited mostly because doing the calculations involves very large spaces, very complicated expressions. It's hard to do by hand. But luckily we are computer scientists.

We don't do things by hand. As if we understand the principle, we can usually generalize it quite quickly. And we have computers that are capable of doing very very large calculations very quickly as long as we put them in the right form. And it turns out that these kind of calculations are of known forms. They are linear programs.

They're nonlinear programs. They're differentiable optimization programs. All things that we can tackle with current um with current technology, especially after the GPU um booma computer. Yeah. I mean I did expect some collapse.

Um there you go. Measured and prepared again. So we one of our uh flagship products is a compiler. Uh computer scientists know that if you have some program specification and you need to translate it into something which is less human friendly such as machine language then you can write a program that does so. As long as you know what the rules are, as long as you know what the steps are, you can automate the process to some extent or to the full extent.

And this is a compiler for quantum cryptographic programs. Uh the starting point is what I described at the beginning. It's literally just a classic protocol design. Let's say that you are a classical cryptographer. You know that you want to have some kind of resource with some property to implement your protocol.

You don't know how to translate this into quantum. You don't know whether you can get security from some quantum setup for it. So you start with that you just say that's the property I want to have I want to implement seeker sharing securely can I do it maybe um the first step is can I translate this into contextual randomness can I make a scheme that regardless of whether it can be implemented with quantum systems or not can it in principle be made with some correlations that respect that particular property and could be secure possibly 100% secure in the ideal case maybe close to 100 or high enough for my purposes. And then the next step is to say, oh, okay, well, great. You have a table.

I don't know whether the table is realizable. Some of them aren't. Um, but some of them are. And regardless of whether they are perfectly, I can find a quantum realization for it. I can try to get as close as possible to those probabilities or something that fits the same shape using some ideal quantum setup.

I don't care about the noise. I don't care about how I will implement it for now. I just need to know could I in an idealized world make it with quantum components. The answer is not always yes, but uh often close enough. But then you have this particular protocol.

Yeah, great. That's a that's a diagram on a page. That's not something you can run. You need to run it. And so if you want to run it, you need to generate some kind of hardware blueprint that you can let's say put on a chip or implement with some lab equipment.

And this blueprint is something which you will then need to tune. First of all, you need to generate it. That's not necessarily hard, but you need to then tune and optimize. And there are some hardware constraints and cryptographically those constraints result in noise or drifts deviations from the ideal protocol and those deviations impact security in some cases. So you need to be able to optimize security based on an actual hardware blueprint if you really want to guarantee to the end customer that they have something which they can they can use with confidence and that confidence is really the final step and that's where a lot of the automation helps.

It is ridiculously hard to prove device independent security by hand. But if you have a computer and you have a sort the general mathematical framework which can be translated into some linear programming, you can solve very large linear programs on computers. And you only need to do this once. You don't need to do it online. You can do it offline at generation if it takes a day or even a week because it's a very large computation.

It doesn't matter. Once you've done it, you have this proof. It can be given to the customer together with the hardware and you can say here's the test you need to run. Here is the model that I have of your hardware. Here is the proof associated that this particular protocol I implemented for you is device independent secure.

Run it. If the test fails, I'm sorry. I probably made a mistake manufacturing or I try to trick you. But don't take the bits if they fail the test. But if they pass the test, here is a mathematical proof that that security has been achieved.

And all of these is differentiable. So we need to have a stack which goes from the top to the bottom from classical protocol design all the way to the generation of blueprints. There are a lot of continuous parameters, a lot of discrete parameters in between and we need to be able to go to the back to the bottom. Then we have physical parameters we can tweak and then we need to be able to optimize at the very top. We need to get the maximum amount of security for whatever hardware blueprint we selected in the end.

So there's combinatoral optimization and there's differentiable optimization involved in this. Things that machines are good at, things that humans are not quite so good at. Um, and that's it. That is uh I think I am roughly on time. So thank you very much for your attention.

[Applause]

Yeah. Any questions? Okay, it's on. Vote it.