 All right. Hi everybody. I'm Alessandra and it's a joint work with Payman and Mike, Payman from Visa Research and Mike from Oregon State University. So in this work we are interested in zero knowledge proofs for run programs and we are interested in specific properties and I'm going to try to motivate this property with, I'm going to start with an example. So say that you have some server who has some interesting data. It does not have to be medical data, it can be any kind of data, demographic or any kind of data. Until you have customers who are willing to pay to query this data. So we can, we are looking at any kind of query so we model the query as any kind of program, so any kind of run program. So the client can query, ask a query, get an answer and can do it many times. In fact we envision to have even many customers. Now of course naturally the client gets the answer and the client wants to make sure that the answer is correct and in particular that all the answers are computed on the same data. Now this proof has to be zero knowledge because here we are trying to protect the data of the server because the server is trying to sell this data so we cannot just give the data away so this proof has to be zero knowledge. This is not a delegation problem. Now for this kind of problem what can we say about this proof, this zero knowledge proof. So we want the following property. The first one is an efficiency requirement. The work, the work to compute this proof should be only dependent on the running time of the program. So from the customer point of view the customer is paying for a certain program so it does not want to pay more to get this proof. From a server point of view the server is paid only to run this program so it's not in its interest to kind of do some additional overhead, some additional computation for this money. So we really want to make sure that this proof has to only be proportional to the running time of the program itself. The other requirement we have is a security requirement. We are looking for kind of the strongest security we can achieve which is composability. Now, well, also we have other requirements like cost around. We only want a number around that is constant which is, I'm not going to stress on it, it's going to be implicit throughout the talk. So now for those of you who know zero knowledge you are thinking first I've seen this problem already and second I thought we'd solve this problem by now. So this is indeed a problem which goes under the umbrella of sublinear zero knowledge and we do know from the 90s that there is a long line of work which is trying to make proofs which are as short as possible. So in this line of work we really care about very fire running time. So these proofs are so short that these days you can also, you can have only constant number of bits set for a proof. The problem here is that the work of the prover is always proportional at least to the input size. And this is kind of against our efficiency requirement because we want that the prover should only work as much as the, as much as it's required by the program, by the run program. So, and in particular in this line of work the main problem is that this is kind of a circuit based approach. So every time you have a circuit based approach you have to work at very least as much as the input size. So now the next natural question is well again we have solved this already. Instead of looking at circuit can we consider the RAM model of computation. So can we look at ORAM solutions where, so if you guys are not familiar with ORAM, ORAM just means that instead gives us a way that, so that instead of working with the entire circuit and so with the entire input we can do computation which depends only on the running time up to a logarithmic factor. And indeed there exists a work which is called sublinear amortized zero knowledge which is based on ORAM. And this was, this is by who, Mohastel and Roslick. It was shown in Kripper 2015. And they, so they achieve zero knowledge, sublinear zero knowledge. So the idea, their proof works in two phases. First there is a setup phase where the verifier and the prover do some computation to preprocess the data. And then after that each proof it's very short in the sense that it's only proportional to the running time. So the idea here is that every time there is a proof involved, the verifier, every time the, the prover has to prove that the computation was correct, the verifier is going to compute a bunch of garbled circuit, it's going to send the garbled circuit to the prover and the prover is going to compute this garbled circuit on its own data. And this gives, gives the verifier a guarantee that the output is correct because the garbled circuits are coming from the verifier. Now the positive side of this construction is that in each proof both the verifier and the prover only have to compute this T garbled circuit. But the downside of this solution is that we still have to deal with a very expensive setup phase. There is no need, there is no reason why the verifier needs to work so hard in the setup phase. So in this work we are trying to, to avoid that. So we are trying to make sure that only work of the verifier is only proportional to the running time. I would like to mention that there are other works of zero knowledge for the specific, for specific programs like zero knowledge sets or other kind of specific queries. These works are very, very efficient. But in our case we are looking at more general equation, we are looking at run programs. All right, so this is the state of the art. So what do we do in this paper? We are actually achieving what, what we promised. So we, we provide the first kind of zero knowledge program programs and the work is only proportional to the running time. The setup phase is succinct, it's independent on the input size. And it uses a cure. And the nice thing is that it's only based on what we call efficient, the theoretical cryptographer say efficient. So garbled circuit or Dickey Boo, which is a new way to implement zero knowledge proofs. Now before we move on to the technique, I want to stress what UC secure means in this setting. What it means to have, to have a protocol which is UC security. So this means that we have to implement the ideal functionality, the zero knowledge ideal functionality. And in this setting, the ideal functionality is modeled as follows. So there is an initial phase where the prover has to commit to the entire data set. And this is done once and for all. And later on, every time the prover needs to prove some statement, the functionality will run the statement for, well, we run the program for, on the committed data, we'll update the data and give the output to the verifier. Now, the challenge here in at UC security is that we have the simulator, at some point we'll have to give this data to the ideal functionality, but I'm requiring that the transcript should not depend on the input size. So somehow we have to work a little bit harder to extract this input from the prover. In particular, it's not that we have to work harder, we have to restrict the kind of assumption we can make. This kind, we need some extractability assumption that is given either by tamper proof hardware, which we are not using, or by random oracle. And we are, in fact, using, in this paper, we are using non-programmable random oracle to extract the input of the prover. All right. So that's our goal. So let's see what is our technique. Our starting point is indeed the sublinear protocol by Huero. Because as I said, it is a very, very nice property, especially in terms of primitive use. So it's only using very efficient one-way function and garbled circuit. So let's now find out why they need the setup phase and how we can get rid of it. So the setup phase in this paper consists, it's a phase where the prover and the verifier needs to encode the input, needs to commit the input. So the way it works is that there is a two-party protocol where the prover participates with this input. And the verifier participates with garbled information, so with randomness to encrypt the input. Then during the protocol, the input is first transformed in order of four. And second is garbled. At the end of the protocol, the prover gets the garbled version of the memory, of the data. And the verifier does not get anything except the guarantee that now the data is committed and is encrypted under the randomness that was chosen by the verifier. Now why does this help? This helps because later on when the prover has to prove, for example, the output of program RI, the prover will run the program in his head, will send the access pattern to the verifier. And now the verifier can prepare the garbled circuit that have to access to those locations. And the verifier can prepare this garbled circuit because he knows that the memory was encrypted using the randomness provided by the verifier. So it's kind of, the verifier can already prepare this garbled circuit so that the prover can directly evaluate them by just looking at the data. So the prover is going to take just the encoded memory, plug it in the garbled circuit, evaluate the garbled circuit, and here it goes the output. And now the verifier can check the output and is guaranteed that the output is coming from the encrypted database, the committed database. Now after this evaluation, the verifier and the prover needs to replace the garbling that have been used. And this is basically the description of the entire product. Now one thing we have to observe crucially, the soundness here is kind of based on the fact that the verifier controls all the garbled. So the verifier controls the encoding of the data. And this is why the business setup fails. Because the verifier has to encode the entire data. Now in this work we want to get rid of it. So we want to say the verifier should do nothing. That's nice, but of course we are going to run into soundness problems. And so the main contribution here is to figure out how can we fix all the soundness problems once you don't have the help of the verifier to encode the data at the beginning. So how do we do it? So that's what we want. We want that at the very beginning there's a setup base which is short. And basically all the encoding must happen in the head of the prover. So the prover will be in charge of taking the data, constructing the ORAM, encode, and clip the ORAM, and finally we'll just commit to all this value using the Merkle Tree. The only thing that the verifier sees is the tree of Merkle Tree. Once we change, once we have this approach, what is going to happen is that now whenever the prover needs to evaluate the Garble Circuit, first of all the verifier does not know the inputs that are used by the prover. So the prover is going to have to ask for labels by OT. And the prover is going to give an input to the Garble Circuit, some information that was never processed by the verifier. Alright, in this new model we are following the challenge. First of all, how does the verifier know that the input that the prover is providing to the Garble Circuit is actually consistent with the hash, the tree root that the verifier has. So that's the first challenge. And importantly we have to prove this consistency in a black box manner because we are going to deal with random oracle and you cannot use the code on the random oracle. Besides, it's also very efficient to have no black box inputs. So that's the first problem. The second problem is we have to make sure that the way the encoding works is such that any simulator can extract the actual data. And so we have to come up with a commitment scheme which is extractable and critical of course you see, but crucially it has to be non-interactive. Because all the commitment has to happen in the head of the prover. We don't want the prover to interact with the verifier in order to commit. So that's important. The last problem we are going to encounter is actually has to do with ORAM. Even once we extracted the entire, even if the simulator extracted the entire input which is committed, this input is in ORAM form. Now the question is once I have the ORAM form of the input, is it easy, is it trivial to reconstruct the original version of the input? We will think yes, but it turns out that the prover, so the ORAM schemes are made to be used by honest people. We never think of a client of ORAM being dishonest. So we have to be careful because the prover can cheat in the ORAM in a subtle way and create states which are ambiguous, such that the simulator does not really know what is the actual input that the prover intends to use. So these are the three challenges we are going to deal with. I'm going to go over the first one more in details and the other three I'm going to go very, very quickly. All right, so how do we prove, how do we allow the prover to prove that the input given to Carlos Shippwith are the same as the ones that are committed in the medical treatment? In order to solve this problem, we are going to use techniques that have been developed already in SOC 2014 and TCC 2014 for another problem, but the idea is that when you want to provide a black box proof of a commitment value, one idea is that if you are committing the value right away, you will first encode the commitment using an encoding scheme like in itself and then you commit each share independently. So you first have this preprocessing of your data and then you compute the medical treatment. If the data is committed in this way, then the prover is able to actually show the verifier which is being honest without revealing too much. How does this work? So now the prover is going to feed the Galbo circuit with the code word of a value, instead of the value directly. The Galbo circuit will check that everything is okay and will compute the new encoding and later it will output for the verifier to see, it will output some values of the code word, not all of them, only some of them. And these are just for the verifier to see. So now the verifier receives this partial information from the Galbo circuit. The next step is to connect this partial information with the committed route. How to do that? This is simple. We just ask the prover to open the path that corresponds to the location which was given an input to the Galbo circuit. So now the verifier sees the code word that the Galbo circuit saw and at the same time he obtains the code word from the partial code word from the commitment. He can check the two things and if they are indeed the same, the verifier is convinced that the prover is computing over the input and is committed at the beginning. So there is a proof of consistency and the nice thing is that the verifier does not have to do anything about it. It's just checking. We generalize, this idea can be generalized, you don't really need Galbo circuits or you don't necessarily need Galbo circuits. All we need is to compute this F check functionality and you can implement this functionality in any way, in particular you don't need any kind of team, you can use other techniques like Tiki Boo that I was mentioning before. All right, so that's the first challenge. The second challenge was just a commitment scheme but we have no time for the second challenge. I just wanted to go very briefly to... Well, the second challenge was just, okay, let's come up with a commitment scheme which is UC and non-interactive. If you have a question, you can ask the leader. Now, the third challenge is what happens even after the simulator was able to decrypt everything to extract all the information, is it possible that the simulator gets confused? Is it possible that the prover can commit to an ambiguous ORAM, which is still correct? To give you an example why this is possible, consider the following ORAM states. This is a path ORAM state, so you have a position map and you have the ORAM tree. The position map tells you how to map the real blocks with the physical blocks, so the logical block with the physical blocks. Now, in this case, for example, the position map tells us that if you want the block 4, you have to look at path 1. But if you go to path 1, you'll see there are two blocks which are indexed by 4. So now the simulator that sees this, so this is not illegal. Path ORAM will allow you to do that. Well, the client will not do that, but this is illegal. But now the simulator, by seeing this information, will not be able to actually understand what is the actual block that you should commit. So this is just a very subtle issue and we define a new property for ORAM that we need which is called extractability. All it says is that you have to make sure that from the state of the ORAM, there should be a unique database, a unique memory that you can extract. All right. So in conclusion, putting everything together, we provide this new way to do our RAM proofs for program, zero-nudge proofs for RAM programs. And the interesting fact, I guess, that it's based on various efficient primitives, it's UC secure, and the work depends only on the RAM design. Thank you.