 Welcome to my talk on generalized proof-of-knowledge with fully dynamic setup. This is joint work with Christian Badetscher and Wally Maurer. Let me start by giving you a brief recap of interactive proof systems and proof-of-knowledge in particular. An interactive proof system is essentially a protocol between a prover P and a verifier V, where the prover wants to convince the verifier V of some fact. In the case of a proof-of-knowledge, this fact is that for a given relation R and the statement X, the prover knows a witness W that satisfies the given relation. This notion has turned out to be one of the most influential and successful abstraction in cryptography and has a long history of formalization, ultimately with the one by Bellara and Goldreich from 1993, turning out to be the one that's now they accepted. However, throughout the years there have been quite a number of situations where it showed that despite being quite general with having this general relation R, proof-of-knowledge might not be general enough in certain applications, especially it might not be general enough when trying to formalize the goal of higher level applications. Let me give you some examples. For instance, consider password-based authentication. A user wants to prove to a server that they know their password or consider proof-of-ownership that comes from client-side-filed-in application. In a proof-of-ownership, a prover wants to prove to a server that they know the content of a certain file. So in both applications, it sounds like essentially a proof-of-knowledge. The prover wants to prove they know something. Yet, neither of those two applications could just be formalized using the common proof-of-knowledge formalization. Instead, both of those applications come with tailor-made security definitions that are entropy-based typically and often also fairly at home. So let us briefly revisit, like, in which aspect the proof-of-knowledge might be more general and what has been done about this so far. So first, we observe that in a proof-of-knowledge, the statement and witness are essentially rigid objects that are just given as inputs to the various parties. And essentially, the underlying assumption is that if that should not be true, then obviously we can first run some kind of negotiation protocol where we negotiate first on, let's say, the statement and then we run the general proof-of-knowledge. However, it has been observed that there arise non-trivial aspects if you consider such a negotiation phase. First, on a more practical side, if you have a very involved negotiation phase that requires the prover already to do a lot of work and then maybe we can get away later with a more efficient protocol rather than general proof-of-knowledge while still having the verifier convinced that the proof must know a given witness. Then, on a more theoretical point of view, there might also be non-trivial interactions with respect to security guarantees. Maybe as a fairly naive example, let's say you have a zero-knowledge proof-of-knowledge but then throughout this negotiation phase the prover actually reveals their full witness. Then obviously the proof-of-knowledge being zero-knowledge is of no use. So it seems like in the end we really want that the combined protocol is zero-knowledge and not just the proof phase. So to remedy this problem, Kamanish et al. in 2009 actually introduced a generalized proof-of-knowledge notion that reflects this two-stage process where in the first stage parties negotiate the statement and then there's a second phase where they prove the actual knowledge of a witness. Second, the standard proof-of-knowledge notion does not consider set-up. Again, however, having both proven verifier access to set-up might lead to non-trivial effects on many of the fundamental concepts of the proof-of-knowledge, for instance on the notion of revinding as part of the science game. Indeed, in prior work Bernard et al. considered proof-of-knowledge in the random-oracle model and in more recent work Choudhury et al. considered proof-of-knowledge in the blockchain setting where all the parties are assumed to have access to a public blockchain ledger. And in particular in their work they assumed that the extractor cannot rewind them in this public ledger and obviously then leads to many non-trivial effects that might not be reflected in a standard proof-of-knowledge where the extractor is always assumed to be able to rewind the entire world essentially. Then third, also the standard proof-of-knowledge notion considers the proof relation to be static and fixed. So that means that for a proof-of-knowledge protocol first you assume that the relation is fixed and then you design a specific protocol for that fixed relation. And it has been observed very early on by for instance Wichström but also Damgar et al. That in many cases this might be too limiting and they put forward the so-called notion of relation generators that is essentially an algorithm that first generates the relation and then outputs an explicit description of this relation to all the parties. So a given protocol does not just have to work for one specific relation but for some kind of probabilistic relation generation mechanism. However, it's worth noting that in this generalization the relation is still assumed to be a true relation that is some kind of circuit and in particular this relation cannot depend on general dynamic setup. So for instance if your relation depends on some kind of hashing and you need to model this hashing as a random oracle you're still out of luck. Additionally, it's still assumed that this relation is public and everybody in the world can evaluate it once it has been generated. So to summarize there has been quite a number of potential generalization identified and with work tackling those. However each of the work so far essentially tackled a single generalization of a proof of knowledge and in our work we're the first one that tackle all of the generalization at the same time. In particular we're the first one that consider a general setup rather than just one type of specific setup and we're the first one to consider a proof relation that depends on the setup. A bit more concretely in our work we introduce a generalized notion of proof of knowledge that encompasses both dynamic setup and relation as well as this interactive two phase process where one first agrees on the statement and then actually runs the proof. We call our notion agree on proof and we observe that it actually unifies all the existing proof of knowledge generalization and our notion comes with clear semantics of correctness, soundness and obviously zero knowledge. So to demonstrate the usefulness of our notion as a definitional framework for high level applications that have some kind of proof of knowledge flavor to them we then go on and show two applications. First we considered proof of ownership and second we considered two factor entity authentication. I would also like to mention that in recent work Wittig and Tsang also used our agree on proof notion in their work at Eurogroup this year. With that being said now let's actually introduce our agree on proof notion. An agree on proof protocol is essentially a four type of protocols where both the pruer and the verifier are split into two phases. In the first phase the so-called agreement phase the first pruer interacts with the first verifier and at the end of the phase they both output a statement x as well as a state for the second phase. In the second phase the proof phase then they use the state to execute the actual proof and the phase ends with both parties outputting a bit indicating whether the proof has been successful or not. Now as already mentioned we want this to happen in the present of a generalized setup function f so in our notion all the four protocols have oracle access to such a general setup functionality f. Moreover there's also a so-called input generation algorithm i that beforehand interacts with the setup functionality and generates auxiliary inputs for both the pruer and the verifier. It's worth mentioning that the input generation algorithm is not part of a protocol but rather a protocol has to work for any input generation algorithm i. So essentially anything you want to make an assumption on you should model as part of the setup functionality f whereas any part of the prior knowledge or the state of the system you don't want to make an assumption on you can model as part of the input generation algorithm i. Then I should mention that the setup functionality is really some kind of general UC-like functionality that is a stateful probabilistic ITM. In particular when making a query a party actually provides two arguments the first one indicating who they are. So the setup functionality knows whether they're interacting with the pruer, the verifier or the input generation and can provide different interfaces to each of them. So we cannot just model something like a random or a CRS that is the same for all the parties but also more involved setup functionality where maybe the verifier gets additional information compared to the pruer or different information or so on. Okay let us now consider briefly the correctness game. In correctness when an honest pruer interacts with an honest verifier we obviously want that they agree on the statement they want to run the proof on. Additionally we also introduce general agreement condition C that specifies whether a given statement is valid given the state of the system such as the auxiliary inputs as well as the setup functionality. This is mainly there so that somebody who wants to use our framework can rule out trivial protocols in which the protocol would always agree on some kind of dummy statement for which the proof becomes very easy or even trivial. In particular we assume that there is some kind of special statement abort that means the pruer and verifier could not agree on a statement for which they can run the proof. For instance in the password based authentication example if the pruer is not given a password but only some garbage as auxiliary input then they might decide to abort. On the other hand if the pruer is actually given a valid password then a correct protocol should succeed and not abort. So in case the statement is not abort then a correct protocol must actually end with the second phase both outputting that the protocol succeeded. And I should mention here that the pruer also outputting the result is mainly done so that we know that they both agree on what the outcome was and worst case this can always be achieved at the expense of an additional round of communication. Okay let's now look at the more interesting experiment which is sameness which we formalize as an extraction game analogous to standard proof of knowledge. So analogous to standard proof of knowledge there's a proof relation R and the only difference is really that for us R is not actually a relation but a stateless deterministic algorithm that has oracle access to the set-up functionality. This really gives us a lot of flexibility because now the goal of a proof of knowledge can be phrased depending on the set-up functionality F. So in this extraction game however the agreement phase is run exactly once and so the agreement phase determines a statement X and only after this is done the extractor comes in and has to extract a witness for that statement X from the second phase pruer. This is really important because otherwise the extractor might try to rewind the first phase of the protocol until they result in a statement for which maybe extraction of a valid witness is much easier, something like this. Here we really want that if the honest verifier at the end of phase one thinks we're running the proof for a given statement X and afterwards this proof succeeds then the pruer must have known a witness for that particular X and not some arbitrary X. So in the extraction game unless the statement is a board then the extractor has to extract a witness for that statement X and in addition to black box revinding access to the second phase pruer we also provide the extractor with access to the communication transcript of the first phase as well as all the setup queries the first phase pruer made. This is really needed if we want to have this aspect that maybe a very involved agreement phase can lead to a more efficient proof phase. So let's say in the agreement phase the pruer actually send the witness in order to communicate the statement for whatever reason then now the proof is trivial and so is the extraction. In addition the extractor also gets oracle access to the setup functionality but here only in the role of the pruer obviously because just because the verifier can query something from the setup functionality doesn't mean that the pruer mute is valid because we have this possibility that pruer and verifier have different views on the setup functionality. Finally because the proof relation is no longer a public object we also have to give the extractor black box access to the proof relation so that for instance in a standard extraction the extractor knows whether they need to repeat to rewind once more or whether they're done so maybe even if the pruer themselves does not necessarily know whether a witness is valid in most cases the extractor still seems to need to know and obviously you can tweak our notion by saying that the extractor should not get access to this and stuff like this and yeah there are a lot of different variants but I think what we put forward makes sense for most applications but obviously feel free to tweak. So this finalizes the two main experiments and I really encourage you for the formal definition to look at the actual paper that's available either on e-print or in the conference proceeding. In additional we also consider some additional properties mainly zero knowledge and for zero knowledge we actually consider two experiments that formalize both pruer and verifier zero knowledge which is really in contrast to standard proof of knowledge but the difference here is really that in standard proof of knowledge the verifier does not have any secrets all the verifier knows is essentially the statement and the auxiliary inputs that the pruer knows anyway so there's no need to formalize that a dishonest pruer does not learn any secrets from the verifier. However, in our setting where we have setup functionality where the verifier might have different access than the pruer we also want to formalize that the dishonest pruer does not know learn additional information from about disinformation. So for instance in password based authentication the verifier might have access to the entire password database but the pruer does not so obviously we want to be able to formalize that during the protocol the verifier does not leak information about other users' passwords to a dishonest pruer and to make our notion more general we actually do not just formalize zero knowledge but we formalize zero knowledge with explicit leakage so even if you have a protocol or situation where perfect zero knowledge is not achievable but you have maybe some kind of explicit leakage or bounded leakage our notion has you covered by allowing you to specify an explicit leakage protocol that the simulator then can invoke in order to learn certain well defined information about the other party's secret inputs that is the other party's auxiliary input as well as view on the setup functionality additionally we consider also a programmable variant of our notion where the setup is programmable for instance if you have a common reference string, a CRS then most of the time this is only really useful if you assume that in the soundness game the extractor can actually program the CRS such that they know the trapdoor we formalize this by saying that there can be a trapdoor setup functionality for which the extractor learns the trapdoor but to anybody who does not know the trapdoor it still looks indistinguishable from the actual setup functionality that we assume to be present in the real world finally let me also briefly touch the issue of composability so in our paper we prove actually two results and both of the results are about a high level protocol invoking an agree and prove protocol multiple times in sequence and what our results show is that one invocation of the agree and prove protocol does not negatively affect the security of any of the order invocations and one of the results is about all the invocation all the protocols using the same setup functionality whereas the other is about all the instances using their own private setup functionality and I should maybe stress that while this might sound like the sequential composition theorem you know from proof of knowledge it's really quite different in spirit so in the way I understand it in the regular proof of knowledge the composability notion is really mainly a technical tool that's used to say that if you have a proof of knowledge protocol with a big soundness error you can just repeat it and get the knowledge error down without negatively affecting the zero knowledge property or the correctness or anything of that but there the point is really that sequentially iterating a proof of knowledge protocol results in a proof of knowledge protocol that's just better but less efficient on the other hand sequentially repeating an agree and prove protocol is not really agree and prove protocol anymore because each of the iteration might even agree on a completely different statement for which you then invoke the proof so the way I see it our protocol is really more of a user style composability result that says that our notion is strong enough so that you can use it securely okay so that concludes the second part of the presentation using the agree and prove notion and its properties as a third part let us briefly look at some of the application and first we consider client-side-filed application so in client-side-filed application you have a server that stores a bunch of files and the client approaching it trying to convince the server that they already know the content of one of those files this isn't particularly useful if you think of maybe a hundred users that all have the same file locally stored and want to outsource it to the same cloud storage provider so rather than each of the user uploading the file individually and then maybe the server doing some kind of server-side-filed application to reduce storage we can get something more efficiently by only the first user actually uploading the file whereas all the other users can just run this more efficient protocol but obviously this protocol must be secure in the sense that a user that does not know a file cannot trick a server into making the server believe that he knew it and then handing it out the secret file to the client indeed this application this is something that cloud storage provider are actually interested in and some of them even have deployed in practice unfortunately it turned out that many of those protocols are quite insecure in various subtle or less subtle manners this provide the Talevi et al in 2011 to actually formalize this task as what we nowadays call a proof-of-ownership however despite this proof-of-ownership sounding like a proof-of-knowledge they could not just say it's a specific instance of a proof-of-knowledge but rather had to come up with an entirely new security definition which in their case ended up to be entropy based so the notion talks about all the files having high mean entropy and then securities defined only for such file and so on in our work in contrast we show that proof-of-ownership really can just be formalized as an instantiation of our general agree-on proof framework that is we show that we can provide a specific setup functionality that formalizes this file database, the service stores we can formalize a correctness relation that defines that user that knows such a file must succeed and we can formalize a proof relation that formalized only a user that knows a file must succeed in particular we can then also look at the zero-knowledge definition with leakage that we have and we use that to show the security of a novel protocol we introduced which is essentially the privacy-preserving analogon well-known mercury based proof-of-ownership protocol so this mercury protocol the standard version of it is not zero-knowledge we then make it a set almost zero-knowledge but with some explicit leakage in particular to give you maybe some example the leakage that this honest prover might get is essentially whether the server already has this file stored or not and we believe that in the context of client-side file data application this is not really an issue because this seems something a user inherently has to learn if you want to have official protocols where if the server already stores the file we can skip uploading it but on the other hand if the server does not know that file yet then the user obviously has to upload the file as a second application we consider two-factor client authentication that is a client that wants to log into some server using both a password as well as some kind of second factor which in our case we model as an abstract hardware token and again we formalize this by just instantiating the setup functionality correctness relation and proof relation of our framework and here I would really like to stress that this is something that none of the existing generalization could have done because those relations really depend inherently on the setup functionality which in this case is the password database that stores user names as well as some kind of digest of the user's passwords but given that obviously users should be allowed to change their passwords new users should be allowed to join the systems and so on this is really something dynamic that the protocol cannot just assume to and hard code moreover inherently we do not want that the prover can evaluate the proof relation themselves because that would mean that anybody can do offline brute force attacks towards this system finally this example also shows that our agree and prove formalization actually can not only do proof of knowledge type of stuff but also can handle this kind of hardware token proof that is not really a proof of knowledge because there's nothing to extract but it's rather some kind of proof of our ability where a prover demonstrates that they have access to something physical which in our case we model as having specific access to the setup functionality to wrap up this talk we first revisited proof of knowledge and we've seen that there already existed many generalization however each of those sort of tackled a specific aspect where proof of knowledge were not very general so far in this work we present the first proof of knowledge generalization that unifies all of those aspects namely fully dynamic setup dynamic and setup dependent relations and third dynamic and setup dependent statement negotiation with an explicit agreement phase finally we showed that our notion is indeed useful for formalizing proof of knowledge type higher level security goals by giving those two examples but of course we believe that our general framework can be of use for also many different examples and we leave it up to you to come up with new exciting applications and maybe would love to hear feedback on whether you found our notion to be useful or but you had to maybe slightly tweak it and so on with this I thank you for your attention