 Hey everyone, today I'm going to talk about public coin statistical zero-knowledge batteryification against malicious verifiers. It is a joint work with Ron Rottenblum and Prashan Vasudevan. So as you all probably know, zero-knowledge proofs are an amazing idea. A zero-knowledge proof lets a prover to convince a verifier of the validity of some statement without repeating any additional information. In this talk, we focus on statistical zero knowledge for which both the zero-knowledge and the soundness are information theoretic. So a protocol is statistical zero-knowledge if it has the usual completeness and soundness properties where the soundness is also against an unbounded prover. And the zero-knowledge requirement is that for every poly-time verifier there exists a poly-time simulator such that the output of the simulator on some yes instance is distributed really closely to the distribution of the messages being sent by the prover and the verifier. Now let's say that the verifier wants to check that k different statements are all true, meaning to accept if all the statements are yes instances and to reject if at least one of the instances is no instance. The naive solution is just to perform the basic protocol k times one time for each instance. Let's say that verifying one instance takes m communication bits. So the naive solution will take m times k communication bits. The question is if we can do better. So let's discuss few prior works. So using the ip equals p space theorem we can actually show batching for every problem in ip however with inefficient prover. The line of work of Rottenbloom, Rottenbloom and Rheingold show batching for up which is a surplus of np with communication of poly-m low k where m is the written length. The special property about this protocol is that the prover is efficient and there is also another line of works showing batching with computational soundness however some under crypto assumptions and with really small communication complexity. So our main question is suppose that some problem is in azk can we verify that k instances are all yes instances in zero knowledge and with no trivial communication. We think it is a natural problem and it can also be used for batch verification of signatures and public keys. In previous work with Ronin Proshant and also with Guy Rottenbloom and Adam Silphon we showed that every problem that is in nizk is a non-sverifier sdk batch verification protocol with k plus poly-m communication. However it was left open if we can get a protocol also again malicious verifier. So our main result is that every problem in nizk has a public coin statistical zero knowledge batch verification protocol with k plus poly-m communication. So we improved the previous result in two ways. The first we show a protocol that is also against malicious verifier and secondly we show the protocol that is public coin. Let's recall the non-interactive statistical zero knowledge model. So in this model we have a CRS a shared uniform string that both the prover and the verifier gets at the beginning of the protocol. Then the prover based on this CRS and on the yes instance generates a proof and pi and send it to the verifier and then verify based on this proof and the CRS and the instance decides if to accept or to reject. So we showed our result in two steps. In the first step we showed the public or non-sverifier statistical zero knowledge batch verification protocol which is also nice in some particular sense we will soon discuss. In the second step we show that for every such nice protocol there is a efficient transformation from public coin on this verifier statistical zero knowledge to public coin statistical zero knowledge. So let's start with the warm-up. The input is length preserving circuits. The yes cases are circuits that define permutation and the no cases would be circuits that are far from being permutation in the sense that every image has at least two pre-images. So the way we think about k instances of this problem is as a composition. So let's go over the public coins on this verifier statistical zero knowledge batching protocol. First the verifier samples some yk and sends it to the prover. Then the prover calculates some x1 such that the composition of the circuits on this x1 equals to this yk and sends this x1 to the verifier. The verifier checks that indeed this yk is the output of the composition of the circuits on x1 and accepts or rejects accordingly. So let's consider the yes cases all the circuits are permutations and permutations are invertible. So because permutation is not invertible this x1 must be exist and the prover can send it. For zero knowledge consider the simulator that first sample x1 and then compute the composition of the circuits on this x1. Since all the circuits are permutations this yk is distributed uniformly as in the real interaction between the honest verifier and the prover and therefore we get the zero knowledge. So let's continue to the no cases. In this case let's consider the last no instance. So let's assume ci is the last no instance meaning that ci plus 1 to ck are all yes instances and therefore permutations. Okay so since the circuit ck is a permutation and yk is uniform then xk is also uniform. We can continue with argument from ck down to ci plus 1 and therefore yi is also uniform. But now let's take a closer look at the circuit ci which is a no instance. Since it's a no instance every image in ci has at least two pre-images. That means that the image size of ci is of size at most 2 to the n minus 1 and the probability that yi has no pre-images is at least half. In this case it doesn't matter which x1 the prover would say it just won't yield this yi since it doesn't have pre-images in the circuit ci and therefore the verifier would reject. So now let's consider the approximate injectivity problem. So in this problem the input is a circuit from input size n to output size m and we think of m as the poly of n. So for the yes cases all the delta fraction of the inputs are mapped injectively by c. So for the 1 minus delta fraction of the input they are mapped injectively and for the delta fraction we can't really tell anything and it may also be the case where all the inputs in the delta fraction are mapped to the same image and for the no cases at most delta fraction of the inputs are mapped injectively. So for the 1 minus delta fraction of the inputs we know they are not mapped injectively meaning every pre-image has at least one other pre-image that is mapped to the same image and for the delta fraction again we can't tell anything. It was shown that this problem is actually n i is the k hard and therefore it is enough for us to show a public coin statistical zero knowledge protocol for this problem. For the simplicity of this talk we focus on the case where delta equals zero and it is not known to be n i is the k hard but it captures most of our main ideas so our goal is actually to distinguish circuits that are injective from those which every image has at least two pre-images. The difficulty here compared to our example is that the output size is not the same as the input size and therefore we cannot directly compose. So we solve it by using a hash function that would map the ci's output size which is of size m to the next circuit input which is of size n. Notice that we have to hash the last circuit too. So if this function was perfectly injective on the set of images of each circuit to the next circuit input we were actually be done but it seems hard to construct this kind of function. So at the moment we think of g as a random function although we cannot really afford it by an eventual protocol so we'll have to de-randomize it. However we have few issues with this approach. First let's consider a yes instance meaning all the circuits are yes instances they are injective and let's take a look at the last circuit ck. So ck maps xk to yk which is then mapped to xk plus 1 by g. Now let's take a look at the image size of ck although ck has output size of m it has an image size of only 2 to the n since it's input sizes of size n and the ck is injective and the point here is that we don't really care about the instances that are not in the image of ck. So we don't care about the instances of 0 1 to m that are not in the image of ck and the reason for that is that they are not relevant for us they have no pre-images under ck and they cannot be used by the prover in this protocol. So with this in mind let's think of g. g actually here hashes 2 to the n instances relevant instances 2 to the n output instances and in this case a constant fraction of the output instances has no pre-image under g and therefore if the prover select one of these instances it doesn't have pre-image under g and therefore the verify won't be able to be satisfied and would reject. So also let's take a look at this error is actually being accumulated across those k circuits and we cannot afford that so we don't have actually completeness here. Know that we cannot afford amplifying it in the sense of communication complexity and also in the sense of zero knowledge. So the solution for that is to add short auxiliary input to g. So we add some auxiliary input of a size polylogarithmic and then the g actually now would map the y's and in addition there is some z i. Okay so as I said auxiliary input is of size polylogarithmic and this auxiliary input actually guarantees to us that each xi has roughly the same number of pre-images and this fact would also help us in the next analysis. So this was the first issue now let's see another issue. What's happened here that constant fraction of the xi also have more than one pre-image under g more than one relevant pre-image under g. So what's the issues here? Since a constant fraction of the xi's has more than one pre-images let's assume that the first circuit is a no-circuit and the rest of the circuits are yes circuits. So when we are coming to analyze the first circuit there are many many x2's that are consistent with the protocol meaning there is a pass from them to the eventual xk plus one. So in this case it's really easy for the prover although it is a no case since there are many x2's to choose from the prover can with high probability find some x1 that will be mapped to yi that then will be mapped to x2 just because it has many options to choose from. So this thing is even worse when we add the auxiliary input we just talked about. So our solution for that would be to use interaction. This interaction would ensure us that when we process yes circuits in every iteration there is a unique xi that is consistent with the protocol. So we do this commitment with pairwise independent hash functions. So let's see what happens when we process the first no instance from the right. Let's say it's the ci circuit the first no instance from the right. So when you get to the round i we can actually assume that the xi plus one is uniquely determined. So let's see how we can use it. So let's see differences between the yes circuits and the no circuits. For ci it is a yes circuits meaning injective. Every image is exactly one pre-image so the image size of ci is 2 to the n. However when let's say ci is a no instance every image is at least two pre-images so the image of ci is at most 2 to the n minus 1. So now let's combine the auxiliary input which is of size d. So if we have a yes circuit for each xi plus one we have about 2 to the d pairs yi zi such that first of all g of yi zi is mapped to this xi plus one and also the yi is in the image of ci. However for the no instances since the image is smaller we have about 2 to the d minus one such pairs. So now we can use a set lower bound to distinguish between the yes cases and the no cases and that's what we are doing. Now let's go back for the adding interaction part. So some of you might have noticed but we have a subtle issue here and the issue is that the indeed the prover commits to an xi in each round but she has the freedom to choose on which xi she commits to and therefore the prover can choose xi which would benefit her in the upcoming no circuits and therefore we cannot assume that the xi's are random. So in this talk we ignore this issue but please feel free to contact me if you're curious about the way we eventually solved it. This concludes our public coin on the Sverifier statistical zero knowledge protocol. However we still need to transform it to a protocol against malicious verifier so let's do it. Goldreich, Sahay and Wadhan show the transformation from public coin on Sverifier SDK protocol to public coin SDK protocol but this transformation is too expensive for us in terms of communication overhead. So we modify this transformation to reduce this communication overhead. This communication overhead actually was originated by amplification of the underlying protocol k times to decrease the soundness. So our transformation is actually applicable only if the protocol has the property of round by round soundness introduced by Kanati et al. So we indeed show that our on Sverifier SDK batching protocol has this round by round property. Okay so let's summarize this talk. In this talk we showed the basic ideas used to show our theorem that every problem in NISDK has a public coin SDK batch verification protocol with k plus poly and communication. We have some open problems that we thought of. First batch verification for all SDK not only for the subclass NISDK. Second a polylogarithmic dependence on k. Next a constant number of rounds. Our protocol has k iterations so it can be interesting to find a protocol that only takes constant number of rounds. And lastly an efficient prover. So there is this work that showed that for some subset of SDK there is a protocol with an efficient prover. However we cannot really use this protocol because it has a polynomial overhead so we won't have this communication if you use this protocol. Okay so that that's it. Thank you everyone who listened and if you have any question please feel free to contact me.