 Okay, so last talk of this session is a fast and simple partially oblivious PRF with applications by Nirvan, Tiaji, Sofia Tseli, Thomas Christenpart, Nick Suleyvan, Stefano Tessaro, and Christopher Wood. And Nirvan is here. Great, thank you. Hello, my name is Nirvan. I'm a Ph.J. student at Cornell University. And I'm going to talk a little bit about some of our recent work on building a new partially oblivious pseudorandom function. So first, I'll start with some quick background on oblivious pseudorandom functions, OPRFs. At a high level, an OPRF allows a client holding a secret input X to compute a PRF evaluation keyed by a secret held by some other party, say, a server. And so the client should learn only the single evaluation of its input and nothing else about the PRF or PRF key. And the server shouldn't learn anything about the client's secret input. And then additionally, we can add verifiability on top of this, where the client will hold a public key of the server and can then verify that the server performs this oblivious evaluation correctly. And so this OPRF primitive has become pretty hot as of late. It's found homes in a bunch of different applications. And a few of these applications have started being deployed at large scale by companies like Google, Facebook, and Cloudflare. And some examples of where these large scale deployments have come in are, for example, in one-time use tokens for authentication, for bucketized private set membership, for password breach alerting. It's been deployed in the opaque system for password-authenticated key exchange, and also in recent proposals for next generation online advertisement attribution. And so because of all this interest in OPRFs, the IETF has begun standardization of a particular construction called 2-Hash-DH. And this 2-Hash-DH construction is basically universally used across all of these deployed applications. And the construction is actually quite simple. It uses a cyclic group of primordial P. So it works well over standard elliptic curves. The secret key is a random field element in ZP. And then the public key is this G of the SK for some generator G. And so to send a request, a client samples a blinding factor R and sends H of, it hashes its input X and blinds by this value R and sends that to the server. The server raises the request to the secret key and sends back this blinded response. And then the client completes by unblinding the response and computing the final evaluation. And so then we can also add verifiability on top of this in a pretty simple way. And if we were doing that, the server would additionally produce this discrete log equivalence proof, proving that it raised the request to the proper power. And so here, the proper power is with respect to the public key. And this proof can be completed very efficiently using, for example, a chompetters in proof. And so this construction is the prevailing OPRF construction. But then in this work, we're concerned with building a partially oblivious PRF, a POPRF. And so a POPRF is just like an OPRF, except it additionally allows for a public input component that I'm gonna call a tag. And so here now the PRF is evaluated on this combination of the public input tag as well as the client's secret input. And so again, the security properties are the same. The client shouldn't learn anything about the PRF key beyond the evaluation. And the server shouldn't learn anything about the client's secret input component. And then again, we can add verifiability on top of this. So what we've observed is that in all of these OPRF applications that I mentioned, a POPRF can be slotted in in place of an OPRF and this extra ability, this extra power of the public tag can be used to simplify the application. And then when we looked at prior existing POPRF constructions, we found that either these constructions relied on pairings or didn't provide verifiability. And that seemed to pose a barrier to adoption for these applications that were already using this efficient verifiable 2-HDHO PRF. So our main contribution then is constructing a new verifiable POPRF that's as efficient as this 2-HDHO PRF. So it can be easily used as a drop-in replacement. So next I'll expand on one of these OPRF applications so you can kind of see where this like, given this extra power of the public tag, how we can simplify deployments. So I'll focus on the authentication token application called Privacy Pass. And this was one of the leading motivators for our collaborators at Cloudflare. So these content delivery networks like Cloudflare deliver a large portion of the internet's content. And an important function that they've come to start providing is protecting their content hosts from denial of service attacks. And one way these CDNs protect against attacks by bots is by occasionally requiring a capture before completing a web request. And so really these captures are mostly required if the web request is originating from an IP address that's associated with bad actors. And unfortunately that means that they mostly target users that are privacy-conscious users that are connecting through websites like through the Tor network or using a VPN. And so this means that these captures are like disproportionately affecting these privacy-conscious users. And so what Privacy Pass does is once a user passes a capture challenge once, a user can undergo an evaluation of an OPRF that's held by the CDN. And so the user will learn these evaluations, Y1, Y2, et cetera, for a batch of inputs, X1, X2. And then later on, when the user wants to make a web request, they can spend these tokens or these evaluation pairs, X, Y, to prove to the CDN that they passed a capture in the past. And so the CDN verifier can verify that this X, Y pair is a valid evaluation. And then it'll store X on a strike list to prevent double authentication. And then because of the Oblivious Evaluation property, the CDN can't link the token that's being spent to this time of Oblivious Evaluation at some earlier point by the user. And so this is a slightly simplified explanation of protocol, but it gets the main idea across. And Privacy Pass, this protocol has been deployed by Cloudflare for a couple of years now. And one thing that they've observed is an attack that can be mounted despite Privacy Pass' protection. And in this attack, most just users that can pass the capture, so these are human users, will hoard valid tokens over a possibly long period of time. And after hoarding a sufficient number of tokens, they'll distribute these tokens across a botnet and then, again, mount the denial service attack. And so since these tokens are valid, the CDN will allow these requests and the attack will proceed. So one mitigation against this token hoarding attack is to make tokens expire after some timeframe. And this can be done by issuing tokens as an evaluation of an OPRF key that's only valid for some specified time epoch. So here, the most just users can still hoard tokens over time over many epochs, but come time to mount the attack at some later epoch, these tokens will have expired and will not be accepted by the CDN any longer. And so while this per epoch solution works just fine, a deployment challenge is that key management of these many per epoch OPRF keys is somewhat non-trivial. And without proper transparency infrastructure, where this mapping of which OPRF key is the proper OPRF key for which time epoch, without that being easily verifiable by users, users are potentially susceptible to tracking attacks by a malicious CDN. So instead, here's where POPRFs can come in. So we can draw this exact same picture as before. However, instead of using a different OPRF key for each time epoch, the time epoch information can be encoded as a public tag of the POPRF. And so this way only a single POPRF key is required. And so actually what we find is that in almost all of the OPRF applications that we looked at, the same pattern of having many OPRF keys emerges. And in all these cases, we show that a POPRF can be slotted in to simplify deployment somewhat. And so if you're curious about any of these other applications, we discuss them a little bit more in the paper. But then taking this motivation, we took a look at existing proposals for POPRFs. So Pythia was the first proposal for a POPRF. It was proposed in the context of password hardening, but it uses pairings. And what we found when chatting with practitioners about deploying Pythia, it became clear that this use of pairings ended up being a large barrier for many of them. And in particular, it seems that the main barrier was lack of wide library support, particularly in cryptography libraries for the web browser, which was a big concern that was cited. And then the only other proposal is a general transform that transforms any OPRF into a POPRF by generating a per tag OPRF secret key using a POPRF evaluate on the tag. So here I'm showing this transform applied to a two hash DH OPRF where I'm using a hash H3 as the PRF. And so unfortunately, this transform doesn't provide efficient verifiability. The server would have to prove correct evaluation of this hash H3, which would likely require pulling in more expensive general circuit based proof systems. And so then that left us thinking whether we could build a verifiable POPRF from just a discrete hard log group. So I'm giving this talk because we found the answer to that to be yes. And so here's the construction that we end up proposing. We call the construction three hash SDHI for the three hashes that are in the construction and also for the strong Diffie-Hellman inversion structure. And it combines aspects of two existing PRFs. The Doris-Jampolsky PRF strategy is used for encoding the public tag. And it also provides this algebraic structure that we can use to provide proofs of verifiability. And so this is in contrast to that generic transform that was encoding the public tag using a non-algebraic hash function. And then on the other hand, we use the two hash DH OPRF strategy to encode the secret input and also to perform a Bluice evaluation. And so this is how three hash SDHI maintains similar efficiency characteristics of two hash DH which is a really nice property. So we can look at this protocol a bit more closely. The beginning of the protocol remains the same. The client samples a binding factor and blinds this hash of X value. And the main difference now is that in blind evaluation instead of the server raising to this power of the secret key as in two hash DH, the server will instead raise to this Diffie-Hellman inversion value as in the Doris-Jampolsky PRF. So this is the one over SK plus hash of tag value. And then it completes the same. The client unblinds the response and it computes the evaluation. So again, we can add verifiability on top of this using the same discrete log equivalence proof. The elements are a little bit different here because of this different inversion structure compared to two hash DH, but we're still able to use instantiate this discrete log equivalence proof using the sufficient Chomp-Hederson proof. And so the main takeaway I wanted to make here is that the evaluation is really just a minimal delta away from the standards track two hash DH OPRF. And due to its similarity, three hash SDHI is being incorporated as an optional mode into the two hash DH OPRF standardization effort. Great, so it might seem from what I just presented that three hash SDHI is a relatively straightforward combination of two hash DH and the Doris-Jampolsky PRF. And while that is true and it's what gave us all these nice properties, it turns out that the security analysis was not a straightforward combination of the existing analyses. So next I'll try to give a little bit of high level intuition on where these challenges of security analysis arise and how we resolve them. And maybe before that I'll also mention briefly that these new techniques that we come up with also provide the first proof of security for a closely related partially blind signature scheme that's based on pairings. And as far as we know, this is actually the most efficient partially blind signature scheme to date. And so this result may be of independent interest. Great, so in our analysis we introduce new property-based security definitions for POPRFs and OPRFs. These new definitions provide an alternative to the ideal functionality universal composability definition for OPRFs, which was before this, the only existing security definition. And then in this analysis challenge was improving our pseudo-randomness game of three hash SDHI. And so in the pseudo-randomness game, it captures indistinguishability of the PRF from a random function, even against malicious clients that are given access to an oblivious evaluation oracle. So to prove the pseudo-randomness of three hash SDHI, we introduce a new interactive assumption that we call the one more gap SD, strong to be helmet inversion assumption. And we provide a relatively straightforward standard model reduction of three hash SDHI's pseudo-randomness security to this new OM gap SDHI. And then the main technical challenge that we need to overcome is in proving hardness of our new proposed assumption. And so for that, we provide a reduction in the algebraic group model to queue discrete log. Or more precisely, we go through this intermediate Uber assumption that was proposed by Bauer, Fuchs Bauer and Loss recently, that lets us abstract some of the messy details of the AGM proof into an argument about linear independence of the group elements in the game. And so I'll focus for the remainder of my talk on this main technical challenge and provide some intuition for how this algebraic group model analysis for our new assumption goes. So here's a simplified version of the one more strong to be helmet inversion game. I'm omitting the gap decision oracle to simplify the presentation a little bit. And in this game, the average is given G of the X where X is playing the role of the secret key. And then M challenge points G of the Y1, G of the Y2 through G of the YM. And they're also given access to this evaluation oracle that provides strong to be helmet inversion evaluations, which so on an input element B and tag T, the oracle will provide this B to the power of one over X plus T evaluation. And then the adversaries tasked with providing a set of C values where each C is a valid strong to be helmet inversion evaluation for some Y, one of the challenges. And then the adversary must provide more C values for some specified tag T than would be trivially computable by querying the evaluation oracle. So for the sake of time, I won't go into the details of the pseudo randomness security reduction, but intuitively this assumption captures what we want out of the PLPROF security, whereas a query to the blind evaluation oracle for a particular tag allows the client to learn exactly one PRF evaluation for that tag and not any other evaluations for any other tag. So improving the hardness in the AGM rejection to the Uber assumption, we need to argue that at least one of these winning C elements that the adversary produces is linearly independent from all the other elements that the adversary has received from the SDH oracle. And to do this, we need to reason about the types of elements the adversary can get from the oracle. So obviously it's easy for the adversary to compute Q SDH elements from Q queries to the oracle for tag T. What's hard is we need to argue that making queries to other tags doesn't help the adversary compute another winning element for tag T. And so this independence argument becomes especially difficult when the adversary so-called mixes tags where they might pass back an evaluation that they already received from the oracle for some tag T1 back to the oracle to another tag T2. And so I'll expand a little bit on this idea of mixing because resolving this is our main technical hurdle. So here I'm showing a transcript of queries that an adversary might make to the SDH oracle. Here, if an adversary queries element B1 under tag T1, they'll receive this evaluation response R1 that takes this form. Similarly, if an adversary queries element B2 under tag T2, they'll receive R2. Now in query three, consider if the adversary submits an input B3 that includes a response from query one. So here I'm showing in B3 that R1 is included in the form of B3. So this is a repeated query, but it doesn't mix tags. Query one was the tag one and query three is also the tag one. So I'll show that when we don't mix tags, it becomes, we can handle this relatively easily. Our challenging scenario comes when we mix tags. So here I'm showing another query three that mixes responses from both query one and query two, which were the different tags, tag one and tag two. And this results in a response that has this mixed term in the exponent. And so in our reduction to the Uber assumption, we need to show linear independence of these exponents and it's these mixed terms that end up causing us some problems. So now consider again, the repeated query without the mixed terms. Now I'm just gonna show the exponents because for the, in the Uber assumption, we really just need to worry about these rational fractions. And so it turns out that without mixed terms, the independence argument is somewhat easy. We know that the adversary can only create two evaluations on their tag T1 and one evaluation under tag T2. And so here are the, here's the more challenging case, the mixed query transcript. The independence argument of these rational fractions isn't so clear and in particular, it isn't clear if this mixed term will be helpful to produce a new evaluation for tag two, even though only one query to tag two was made. So our insight is that we can rewrite this mixed query three expression to an unmixed query that will be more, that'll be easier to reason about polynomial independence. So here I'm showing a rewriting of query three in a new rewritten transcript. And in this new rewritten, the denominators are unmixed. So they only have tag one in the denominators, right? And so we show that it's possible to find these alpha one, alpha two, alpha three coefficients in such a way that the span of the original transcript and this new rewritten transcript are the same. And so then going back to by a similar argument that we kind of claimed for this unmixed repeated queries, we can show that this new rewritten transcript, which also has unmixed denominators, has a linear independence argument. So we can say that there's only two evaluations for tag two and one evaluation for tag one. And then we show that since this rewritten transcript and the original transcript have the same span, this linear independence argument carries over. And so by this unmixing strategy, we can say something about our original transcript. And so we kind of generalize this argument as the main lemma of this proof of our new assumption. And so by induction, we argue that at each adversary query as long as the transcript of previous queries are unmixed, the new query which could possibly be unmixed can be rewritten as unmixed in such a way that the two transcripts preserve the same span. And so that's what we need to use to complete the independence argument that's needed for the over-reduction. And so that's what I wanted to say about the technical details of our hardness argument. And so I'll wrap up by summarizing some of the impact that 3-HASH-SCHI has begun to have. We evaluated our reference implementation. It confirms that 3-HASH-SCHI is quite practical. It's encouraged just a minimal overhead over 2-HASH-DH. And there's been a good amount of interest from companies that have deployed OPRF applications that would like to slot in POPRFs instead. So because of that, I mentioned before, 3-HASH-SCHI is being integrated into the ongoing OPRF standardization effort. And one of our co-authors, Chris Wood, has been leading that effort. And we'd love to solicit reviews if you're interested in this construction or any of the applications that I mentioned. And so with that, I'll conclude, and thank you and happy to answer any questions. Any questions? Actually, I may have one. So in your analysis, you assume that you can query an oracle with T and you get the power one over X plus T. That's right. But in a protocol, T is hashed. So is the hash necessary? That's right. So the hash, I glossed over those details a little bit. So in the reduction from the Sideranus game to the OM GAP-SCHI game, we do use the random oracle because we need to commit to the set of T values that are part of the OM GAP-SCHI game. So we choose them ahead of time. And then when the Sideranus adversary queries tags, we program the random oracle to our pre-chosen values for the reduction. Okay. And in the protocol, why is the proof optional? So you mentioned that we can add the proof or not? So some applications don't require the client to verify that the... So it depends on the application. It depends on what the trust model is between the users who are doing a blouse evaluation and the party that's holding the OPRF key. If you remove the proof, you lose the unlinkability, right? Yes. So it's very important for the privacy pass application. So that's why verifiability was one of the properties that we wanted of our POPRF. Otherwise, that unverifiable POPRF for the generic transform would have been sufficient. Any other question? Okay, so if not, let's sign the speaker again. Thank you.