 Hey everyone and welcome to my talk for crypto 2020 on Fiat Shamir for repeated squaring with applications to p-pad hardness and bds I'm Alex. This is joint work with the node and our paper is publicly available on eprint at the link on the slide The talk is going to be about Fiat Shamir So let's start by defining it So the Fiat Shamir transform is a heuristic mechanism for converting public coin interactive protocols for some task Into a non interactive protocol for the same task So in more detail we start with an interactive protocol between a prover and verifier as on the left and we assume that every Verifier message all these betas are uniformly random strings Fiat Shamir then converts this into a non interactive protocol in the following way The prover and verifier both have access to some publicly computable hash function h and The prover is going to use h to generate an entire Verifier transcripts for the interactive protocol in one message and the way that this can be done is by iteratively computing a prover message alpha I and then computing the response beta I to be hash of all of the messages so far and So this will allow the prover to generate an entire transcript The verifier can compute all of these same hashes itself and then check whether the overall transcripts that the alphas Indicates along with the hash function would be accepting and if so the verifier for the non interactive protocol will accept So syntactically this makes sense But it's unclear whether the soundness of the protocol is preserved by this transformation So the the question is whether it's still difficult for the prover of the non interactive protocol To come up with a proof of a false statement that the verifier will accept. That's the question So the question of whether Fiat Shamir is sent Despite the fact that this transformation has been ubiquitous in cryptography for decades on the theory side relatively little is known actually about the security of this transformation So on the one hand, we know that if you model the hash function as a random oracle you can show in fairly high generality that the transformation is sound But on the other hand It's also known that there are strong counter examples to doing this in the standard model So there are some interactive protocols such that no matter what's efficiently computable hash function or family of hash functions You use for Fiat Shamir the resulting non interactive protocol will be unsound So there's a setting where random oracles and real hash functions seem to be really different So given this in more detail the question is For which protocols can we actually instantiate Fiat Shamir using an actual hash function? And what assumption do you need to make about the hash function that's sufficient to guarantee the soundness of the Fiat Shamir protocol? So For quite a long time basically nothing or very little was known about this question on the theory side But over the last few years there's been a sequence of works that finally began to make some progress on this question And this talk is about one of these works So let me walk you all through the state of the art on Fiat Shamir before this paper So we knew that Fiat Shamir could be provably instantiated in the following situations So first of all we always restrict ourselves for for the rest of this talk To the setting where the interactive protocol is statistically sound So we assume that the interactive protocol is sound against unbounded cheating provas Uh more so subject to this and subject to the number of rounds being not too large It's actually known that under a sufficiently strong assumption about the hash function Uh Fiat Shamir will be sound. Uh, it's not a standard assumption it's an incredibly strong assumption that you really don't want to make but Theoretically Fiat Shamir could be sound this and this is evidence on the theory side for that fact Second of all in some later works. We were able to show that for a very special class Of interactive proofs You can actually show that Fiat Shamir has sound for a particular hash function family Under standard cryptographic assumptions in this case lwe Then finally there is an intermediate case in the state of the art A classic protocols, which is not quite so narrow as the second line, but it's not nearly as broad as the first line Where under a slightly weaker assumption than the general results You can show soundness and the assumption for the third line is still very strong But it's in some sense or morally falsifiable As opposed to the first line, which is an assumption which is not efficiently checkable So that's the state of the art A little bit more on why the first and third lines are making non-standard assumptions the kind of assumption they have to make is Is what's called an optimal hardness assumption Which says that there's some search problem that you can't efficiently solve much better than brute force This is is very far from the kind of assumptions that we're used to making encrypted So one barrier an important barrier In this state of the art was being able to do Fiat Shamir for a succinct interactive proof That is some interactive proof whose communication complexity was logarithmic in the amount of time t it takes to decide the language Again or we're thinking about just proofs for deterministic computation in that case But yeah, so we don't Know how to how to do Fiat Shamir for any succinct interactive proof as of this state of the art And this is very related. It turns out to questions of p-pad hardness. We'll see later why this is the case So we'll be focusing on the second line of results In this talk and we'll be extending it Beyond what was known before and in particular to some interactive. So it comes to synced interactive proof So in this talk, we'll be talking about the problem of iterated squaring So let me define that as well So the iterated squaring problem Is is the is a problem in which you're given an rsa modulus So you're given a number n which is a product of two primes. You don't know the factorization You're given some group elements in z and star and some number of iterations t and you want to square the group element g t times So you want to compute g to the 2 to the t mod n which can be done by doing t iterated squaring So there is a hard problem Based on based on iterated squaring namely It's believed that it takes at least that it takes very close to time t to solve this problem And in fact it's it's a Stronger claim, which is that even if you give Your adversary a large amount of parallelism It's still believed to to require about sequential time t even given super polynomial parallelism So this is the hard problem underlying the rfw time mock puzzle And we're going to be interested in a protocol for This language the the language of g comma h you given this fixed modulus n So As I just said we're now going to think about making this problem verifiable So instead of just computing g to the 2 to the t we want to think about computing this answer Along with a proof that this group element h is actually a g to the 2 to the t And so pieterzac gave a succinct interactive proof For this computation a couple of years ago, and so we're interested in in compiling this protocol So let me quickly describe to you how the protocol works. So here we have the prover and verifier So what the prover does the prover is going to run in time t and the verifier is going to hopefully run in time log t That's that that's what we want So first the prover computes the halfway point of the computation going from g to h So h is t iterated squareings of g so the prover first computes t over 2 iterated squareings of g and sends this midway point to the verifier So this group element u is implicitly making two claims One is that u is actually g to the 2 to the t over 2 And second that h is u to the 2 to the t over 2 That that's the claim that u is the midway point between g and h So so this message u generates two claims About iterated squareings of size t over 2 that the verifier wants to be convinced of But instead of asking the prover to prove both of these claims The verifier does a random two to one self reduction So the verifier picks a random r thinking of r as an exponent And then the prover and verifier given this r can compute a random combination of the two claims that I just said So we get a new group element g prime which is u times g to the r and answer h prime which is h times u to the r And now the prover is supposed to show That h prime is equal to g prime to the 2 to the t over 2 So this this gives you a recursion and so after Log depth of this recursion. We'll get to a trivial statement the verifier can check on it So it turns out that this protocol can be made very efficient So the prover it turns out has to do very little work beyond just computing the answer And the verifier is working in time polylog t and and and the group and log the group says So this is great. I haven't explained why this is sound, but we'll we'll talk about it later when we're talking about the etching here but this is the protocol So When this was originally written down pieter zak said well We can take this interactive protocol and at least theoristically make it non interactive using a random oracle by applying the etching So in this work So what that means is instead of sampling r at random The prover can compute r to be a hash of all of the relevant information in each of these reduction steps So in this work, we're asking whether we can do this compilation in the standard model and not just using a random oracle So now let me tell you our results the the the short answer is you can So what we show is that if the learning with errors problem lwe is sufficiently hard Then fiat jamir for this protocol can be instantiated and we have a few quantitative variants of the result so first of all If lwe is 2 to the minus n to the 1 minus epsilon part. So in other words, it's a strong sub exponential assumption about lwe Then you can do fiat jamir for this protocol where the verifier runs in time 2 to the security parameter to the epsilon so some small sub exponential time verification under a strong sub exponential assumption Uh in general, there's a quantitative trade-off. So under stronger lwe assumptions you can get faster verification But I just want to emphasize that all of the assumptions being made in all of these results Are much much much weaker than the optimal security assumption That was implicit in in in the in some of the prior work So even the strongest assumption we make here this q to the minus Like 0.01 n hardness is uh is way left is way weaker than the optimal hardest assumption Which is more like a q to the minus n assumption in particular All of the lwe assumptions that we make in this work actually follow from worst case hardness via the worst case to average case reduction Um, but the first of these results. I think is the most illustrative So under a strong sub exponential assumption you can get a compiler with small sub exponential verification time and uh So the the points of these of these stronger assumptions is to get a larger gap between the amount of time It takes to compute namely t and the amount of time it takes to verify But all of them have a have a large gap So from from this fiat-jamir compiler, we get two cool applications. So let me quickly walk you through them So first of all, we get a verifiable delay function in the standard model I don't want to get into the technical definitions But a verifiable delay function is a proof of sequential work So a way to prove that you've done some amount of work sequentially with a unique output That's why it's a function and with close to optimal efficiency Which means that the amount of time it takes to generate the proof Is uh is very close to the amount of time that the verifier is convinced that you've worked for So this is very nice The primitive that was introduced recently Inspired by some application like many applications in sort of large-scale publicly verifiable protocols think like blockchain as an example um And so what pieters ex said When he wrote down the protocol that I just showed you is that if you can do fiat-jamir for that interactive proof Then you get a verifiable delay function. So you get one in the random work model So that's the first consequence that's going to come out of our work The second is about hardness in the complexity class keypad. This is based on some really cool works from last year So p-pad is a complexity class that captures the hardness of finding Nash equilibria in game theory And it's known based on works from last year That if repeated squaring is a hard problem And you can do fiat-jamir for the protocol I just described in the standard model Then you get hardness of p-pad on average. So just plugging those two applications into our fiat-jamir results We get that's if repeated squaring and lwe are both sub-exponentially hard Squaring slightly sub-exponentially hard and lwe very sub-exponentially hard Then you get hardness in the complexity class keypad and second of all We get vdfs in the standard model with some small sub-exponential evaluation time from the first of our results and uh, and even less evaluation time under the stronger lwe assumptions Uh, and it's a vdf assuming that squaring is also sequentially hard, which of course you need to have a delay So what I like about these results is that we're making you know in the lwe case maybe somewhat strong But still sub-exponential time assumptions about two well-studied problems and getting these fiat-jamir compilers It's closer to the stand like it's a It's closer to the second category of fiat-jamir results that I showed you before instead of the first in the third and From these assumptions We get a succinct non interactive argument for a very non trivial language in particular a language That enables these two cool applications So just before I get into the results anymore. Let me just quickly show you what was known What is known about ppad hardness based on cryptography? So there are three results worth mentioning One is that we know ppad is hard under obfuscation like assumptions That was the first result we knew about ppad hardness based on cryptography And second of all there there's this line of work from last year. That's fiat-jamir for certain succinct interactive proofs is enough To get ppad hardness But last year we didn't have any concrete instanti or any instantiations based on standard assumptions of this of this approach and then and then concurrent to this paper Kali Panathanyang Gave a different construction of a hard ppad instance based on a falsifiable assumption on bilinear maps And you can see Lisa giving a talk on this work in the same conference Okay, so those are the results. So for the rest of the talk, I just want to Go over a bit about how we prove the results. So here's the overview the rest of the talk I'll first describe the general paradigm that we know for provably instantiating fiat-jamir in the standard model Is based on one of the works from last year Uh, we'll then see why the methodology as of last year wasn't enough to compile this protocol that we're talking about in this paper What that what that problem was and then I'll show you how to extend the paradigm for compiling for doing fiat-jamir Beyond what we could do last year and in particular enough like how to capture the protocol that we're trying to compile today So the main tool for Compiling fiat-jamir in the standard model are is correlation and tractability Which is a security property of a hash function originally introduced actually for negative results in cacophony but In our restricted setting we say that a hash function family h is correlation and tractable for a function f If it's hard to find f correlations in the hash function that is it's hard to find an input x such that hash of x equals f of x So as of last year, we know how to construct correlation and tractable hash functions for all efficiently computable functions f or More more accurately for every time bound t We can write down a hash function family, which is correlation and tractable for time t computable functions Where the evaluation time for the hash function is about t and This this t dependence is important and sort of explains why some of the previous attempts to do these p-pad hardness results were weren't able to work So now let's see How these hash functions are useful for fiat-jamir So let's think about just for a second compiling three message protocols Using a correlation and tractable hash function I claim that for some interactive proofs for some for a certain class of interactive proofs The security property on the previous slide should be enough should be a enough to guarantee the soundness of the non interactive protocol So we start with this protocol with messages alpha beta gamma And in the non interactive version beta instead of being sampled at random is instead hash of alpha and possibly x as well So we'd like to argue that this protocol is sound So here's here's how we do it. Let's assume that the three message protocol has a strong soundness property Namely that for every false statement and every first message the prover could send There is at most one challenge beta Such that the prover has any way of cheating such that there exists a third message gamma that would make the verifier except So many protocols of course don't satisfy such a strong soundness property, but some protocols do So I claim that in this case Correlation and tractability for functions is enough to compile the protocol. And so so here's why so If this soundness property holds we can define a function f Which maps the false statement x and a first message alpha To this one bad challenge that would enable the prover to cheat we can define this function And then I claim that if the hash function family is correlation and tractable for this function f Then the resulting non-interactive protocol is sound and this just sort of falls out immediately or syntactically If the prover is successfully cheating for the non-interactive protocol Then in particular the prover is produced in accepting transcript alpha beta gamma But the assumption is that for every false x and first message alpha There is only one beta such that this is possible at all And so it must mean that the hash value beta is also equal to this function value f of x comma So this is the paradigm for doing the action here Shows that correlation and tractability for functions is enough to compile certain protocols But there's a big problem with what I've said so far Which is that for essentially any interesting protocol any protocol at all Doing anything not not silly the function f is actually going to be hard to compute not easy It's it's going to take super polynomial time to compute f and in some sense like You should expect this if if f were easy to compute it means the verifier could somehow already know What challenges were good or bad and and then interaction wouldn't be necessary anymore So so this is bad and the work around so far the way that we actually accomplished anything was by supposing or constructing protocols where f might be hard to compute in reality But it's easy to compute in our heads in the security proof using a trap door a trap door that the verifier in particular doesn't have access to So that's how we got interesting results before And already what we're going to be using in this work is that you get an interesting Compiled protocol as long as it's easier to compute f using the trap door than it is to decide the language As long as that's the case you might have super polynomial time verification using using the hash function But it'll be less than the time it takes it aside the language and therefore it'll be a non-trivial protocol You know in the end we're going to have small sub exponential time verification as it turns out So let's try to apply this now this paradigm to peter zack's protocol So there are there are two problems Uh with what I just said One is that peter zack protocol is not three messages It's actually you know logarithmic number of messages. So it's not clear how to adapt first of all And second of all, you know if we can if we can freeze the soundness of this protocol in terms of a bad challenge function We then need to come up with an efficient representation of the function so that we can use correlation and tractability for efficient functions So the first of these problems is something that has been thought about before and there is a way for handling it There's a way to assign a bad challenge function to peter zack's protocol Even though it's not three messages And the idea is that you're going to have or rather you're going to have one bad challenge function for each reduction step sequentially So, you know here's one reduction step as I described it and the soundness analysis is going to say That if the statement is false that is if h is not the correct answer Then no matter what first message the prover sends There's going to be at most one choice of second message r Making the recursive call Uh on a true statement instead of on a false statement, you know So if the recursive call was made to a false statement, then you could keep going and say everything is fine Uh, the the argument is going to be that it's rare to ever go from a false statement to a true statement As long as you stay on a false statement, then at the end the verifier will reject Okay, so that's that's good. And so this will give us a bad challenge function for each Each round reduction Okay, so so that's good Uh, and as I just said, uh, this the statement will give us a bad challenge function for each reduction step And so again Based on what I just said if we can come up with a hash function, which is correlation intractable for this bad challenge function Then we'll get soundness of the resulting non interactive protocol and and for reduction Okay, so so that's all well and good the uh The real question is, you know, can we show that f is in some sense efficiently computable? Perhaps given some tractor. So so let's see, you know, what what is this function f? So I'll spare you spare you the details So it it turns out that if you think about things in terms of discrete logs instead of the group elements that's The bad challenge function are there the bad challenge are associated to the statement and first message you Is the solution to a linear equation in the exponent of the group where the coefficients of the equation are Where the coefficients of the equation depend on these discrete logarithms So, you know, this is the linear equation. Don't worry about it too much. Um, but Let me at least argue to you guys that uh, that this is not easy to compute even given the tractor So how how would you how would you find this bad challenge are? So it's a linear equation in the exponent So what you could do is compute the coefficients and then solve the equation So to do that you need to do the following things you need to compute the uh order of the group, which is this b of n That's as hard as factoring in but this is not really a problem Because if you have the factorization of n as a trapdoor then this is easy. So that that's fine Uh, we can then we then want to compute these coefficients of the linear equation So one of these is uh, is easy to compute given again the factorization, but We also need to compute these discrete logarithms the discrete logarithm of uh In particular the discrete logarithm of u in base g uh is an important one. Um, and this seems very difficult u is something that prover produces you can't just pre-process this discrete logarithm away Uh, and moreover the factorization of n doesn't seem to help in computing this discrete logarithm at all Like the problem of whether groups have trapdoors for computing discrete log is well studied and we have no Like there's no indication that this is the case. It appears that discrete logarithms are hard given given trapdoors as well Uh, so this is bad. Uh We're we're currently stuck The the approach that I've described so far can't capture bad challenge functions which require computing discrete logarithms in hard discrete log groups And so our our solution in this paper is that it might be the case that f is really hard to compute But we still get something If it's easy to compute with some small probability that is we're going to compute f via a randomized fast randomized algorithm That works with inverse sub exponential non-trivial probability So it turns out that the discrete logarithms can be computed efficiently in this model So I'm sweeping some details onto the rug But rough, but there's some pre-processing that also needs to be done But roughly speaking you can compute discrete logs in small sub exponential time with large inverse sub exponential probability Uh, and there are other trade-offs and each of these trade-offs ends up giving us a different theorem statement So this is just the standard index calculus algorithm But it's uh with different parameter choices. So that's you know, the discrete log is not actually computed exactly um So so this is the fact that we're going to use to get a fiat Shamir compiler And the idea is that if the hash function family is very quantitatively correlation intractable That is correlation intractable even against small probability adversities then uh That is if it's if it's if it's that ci For efficient functions Then it should also be correlation intractable for inefficient functions that you can compute efficiently with small probability So this f in particular will get correlation intractability for this f even though it's hard to compute Uh by appealing to a sufficiently Quantitatively strong form of correlation intractability So this follows from a fairly simple lemma Which says that if you're some epsilon correlation intractable for efficient functions And f is computable efficiently with probability epsilon Then the hash family will also be correlation intractable for f The reduction is there the proof is exactly as you would expect The point is that if you're breaking correlation intractability for f Then you'll also break correlation intractability for this efficient function g with some small probability So this idea is enough that this high level idea is enough in the end to get us the result we want So let me just sketch the overall analysis Uh, as I said before for each reduction step if the if the current claim is false Then no matter what the prover sends as its next message There is at most one Response r that that will make the next claim accidentally true So as long as we can avoid these Then then we have soundness So this allows us to define a bag challenge function for this reduction step And if we have correlation intractability for this function f then we get soundness of the whole protocol And by what what what I just argued if you have a quantitatively stronger form of correlation intractability for Sub-exponentially efficient functions Then you also get plain correlation intractability for this function f Which gives us soundness of the whole protocol So this is why we need to make a two to the minus lambda to the 0.99 say assumption about lwe In order to get a fiat-jamir compiler for this protocol So that's that's our main result Uh, let me just recap what we just saw So in this work we extend the bad challenge function paradigm for fiat-jamir To protocols that cannot be characterized by efficiently computable bad challenge functions They're characterized by bad challenge functions that are not efficient And the way we do it Is by considering a model In which the bad challenge function is efficiently computable and the model is you know That you only have to be able to compute the function with sub exponential inverse sub exponential probability And it turns out that this is that's a Reasonable sub exponential assumptions on the hash function are still enough to guarantee fiat-jamir soundness in this case And the punchline is that we get these two cool applications p-pad hardness and verifiable delay function in the standard model From sub exponential hardness of two well-studied problems Uh, so just you know one one takeaway that you might want to get from this paper Is that you can now do fiat-jamir For protocols that are characterized by bad challenge functions that are efficient Modulo some discrete log computations that are of course inefficient and this says you can You can replace these computations by low success probability efficient algorithms and then argue fiat-jamir sounds Thanks for listening