PRIVATE SET-INTERSECTION WITH COMMON SET-UP

. The problem of private set-intersection (PSI) has been tradition-ally treated as an instance of the more general problem of multi-party com- putation (MPC). Consequently, in order to argue security, or compose these protocols one has to rely on the general theory that was developed for the purpose of MPC. The pursuit of eﬃcient protocols, however, has resulted in designs that exploit properties pertaining to PSI. In almost all practical appli- cations where a PSI protocol is deployed, it is expected to be executed multiple times, possibly on related inputs. In this work we initiate a dedicated study of PSI in the multi-interaction ( MI ) setting. In this model a server sets up the common system parameters and executes set-intersection multiple times with potentially diﬀerent clients. We discuss a few attacks that arise when protocols are na¨ıvely composed in this manner and, accordingly, craft security deﬁnitions for the MI setting and study their inter-relation. Finally, we suggest a set of protocols that are MI -secure, at the same time almost as eﬃcient as their parent, stand-alone, protocols.


Introduction
The problem of private set-intersection (PSI) involves two parties, a client and a server, each having its private set. After the execution of the protocol the client learns the intersection of the sets, whereas, the server learns nothing. Both the parties, by default, learn the cardinality of the other party's input set. In a variant called mutual-PSI, both parties learn the intersection [10]. The security requirements for protocols which solve the PSI problem can be broadly classified into two: security in presence of an honest-but-curious (or, semi-honest) adversary and, the stronger, malicious adversary [24]. An honest-but-curious (HbC) adversary aims at learning additional information without deviating from the protocol specification, whereas a malicious party can arbitrarily deviate from the protocol specification. Security in the HbC model suffices in many scenarios such as where it is difficult to modify the software or where some form of hardware or software attestation can be performed [30].
PSI protocols find application in many privacy-preserving scenarios. Consider the following motivating example from [20]: an airlines company acts as the server and the US Department of Homeland Security (DHS) as the client. The airlines company has its passengers' list and the DHS has a terrorist watch list. The DHS wants to find out whether any suspected terrorists are in the passengers' list of the airlines. The solution is to use a PSI protocol. In a similar application PSI can be used by the banks of one country and the tax authority of another whereby the tax authority finds out whether any of its suspects is a customer of the concerned bank or not in a privacy preserving manner. In yet another interesting real-world application, PSI protocol is used in real-time to secure on-line gaming platforms from cheating attacks [9]. Many on-line strategy games (e.g., Warcraft, Age of Empires) utilise "fog of war" to hide the details of a particular player from another. Bursztein et al [9] developed a tool called Kartograph which enables a cheating user to tinker with the content of his system's memory and undo the fog of war. This technique, which they call "map hacking", gives the cheater an unfair advantage. To counter this, they developed a tool called OpenConflict which deploys the fog of war in a distributed fashion and, then, uses PSI protocol to reveal appropriate information. Other applications include privacy-preserving data-mining [35], human genome research [3], etc. One notable feature of most applications is that they require the set-intersection to be computed multiple times between a server and one or more clients, possibly on related inputs.
1.1. Related work. Given the interesting nature of the problem, it is imperative that the area witnessed a lot of research over the last decade. The problem was introduced by Freedman et al [23] who proposed a solution based on oblivious polynomial evaluation. Subsequent works along the lines of polynomial evaluation include [34,18,1,16,26]. In a different line, Hazay and Lindell [27] used an interesting primitive called oblivious pseudo-random function (OPRFs) to propose two protocols, one secure against a relaxed version of a malicious adversary and the other against the so-called covert adversaries. Jarecki and Liu [31,32] improved upon this work by reducing both the computational and communication complexity to a linear factor assuming common reference sting (CRS). In a further development, Hazay and Nissim [29] combined oblivious polynomial evaluation and OPRF to construct malicious model secure PSI protocols.
Another set of interesting results are due to De Cristofaro et al [20,19] and Ateniese et al [2]. Among all the works on PSI, the results of De Cristofaro and Tsudik [20] are most relevant in our context. They proposed a set of extremely efficient protocols in the HbC model in the RSA and gap Diffie-Hellman (GDH) setting with linear computation and communication complexity. In particular the RSA-based protocol given in [20, Figure 4] -henceforth referred to as the "F4" protocol -has the additional benefit that one can pre-compute, off-line, the costly operations, leading to an efficient streamline protocol suitable for low-power devices like mobiles phones, PDAs, etc. De Cristofaro and Tsudik are also the first to consider more than one executions of the PSI protocol with common set-up. Though they didn't formalise the notion, they do consider the (un)linkability of more than one executions and provide a heuristic argument of server and client security of their protocols in this setting. However, the formal security claims are in the standalone setting and are based on the non-standard one-more RSA or one-more GDH assumption.
The advent of "big data" naturally led to further emphasis on efficiency, resulting in solutions utilising alternative techniques like garbled circuits [30] and Bloom filters [22]. Also, see the results in [37] using garbled circuits and oblivious transfer.
The aforementioned work of Pinkas et al [37] provided a comprehensive comparison of performance (without any pre-computation) of PSI protocols based on different techniques. They stress that the choice of a particular PSI protocol will depend on the application scenario taking into consideration the available communication and computational resources.
1.2. Our motivation. Our interest in the problem of private set intersection stems from the realistic application scenarios where the PSI protocol is executed multiple times between a server and possibly different clients, likely on related inputs. In particular, whether the current definitions (both that of the protocol and its security) take this fact into account. For instance, recall the tool of OpenConflict: the underlying PSI protocol is executed multiple times on related inputs and at a very high frequency. It turns out, that most definitions (especially those concerning security) have evolved considering PSI to be a special case of the more general multi-party computation (MPC) where the convention is to design a secure protocol in the stand-alone setting and then use general composition theorems.
Although the composition of general MPC protocols has been well-studied, like any other problem, there is a gap between theory and practice: by treating a specific problem as an instance of a more general problem, using general security definitions for establishing its stand-alone security and then using general composition theorems to establish that it is secure when used multiple times, we might be, very well, missing out on properties that are specific to the problem. Even though researchers have strongly considered the first aspect and, as a consequence, crafted dedicated protocols for PSI, the latter two aspects -that of security definition and composition -remain relatively unexplored.
Our aim is to explore these two aspects more thoroughly to build efficient and practical PSI protocols that are secure under multiple interactions, simultaneously, bearing in mind the definitional facets. Some initial effort in this direction can be noticed in the well-known work of De Cristofaro and Tsudik [20]. The paper talks about the unlinkability property and hence implicitly assumes multiple interactions with a common set-up. However, as already mentioned, the paper didn't attempt at a formal definition and deferred the issue of formal proof of unlinkability for the proposed protocols as a future work. In this context it is worth noting that the authors of [20] take advantage of off-line precomputation to make the protocol F4 extremely efficient. However, full benefit of pre-computation is accrued when the cost is amortized over multiple execution of the protocol with the same set-up. Unfortunately in such a scenario server unlinkability property of protocol F4 breaks down as noted in the paper itself.
1.3. Our contribution. Taking a cue from [20], we formally investigate the problem of constructing efficient and secure PSI in the multiple interaction environment. Exploring the problem of "server linkability" further, we show that in protocol F4 an adversarial client can, in fact, compute intersection of sets across interactions. Suppose protocol F4 is executed twice: first with server set S 1 and client set C 1 and then respectively with S 2 and C 2 . While the protocol allows the client to compute only C 1 ∩ S 1 and C 2 ∩ S 2 ; we observe that the client can actually also compute C 1 ∩ S 2 and C 2 ∩ S 1 . This is a clear violation of server privacy.
We term the above attack as the "cross-intersection" (CI) attack which subsumes server-linkability attack. Both the attacks indicate limitations of the existing security definitions which do not capture the more realistic multi-interaction (MI) setting. That brings us to the question of stronger security for PSI protocols: the notion of "MI-security". Our primary contribution lies in identifying a meaningful definition for PSI in the multiple interaction environment. We also show that some of the efficient PSI protocols can be easily tweaked to achieve this stronger notion of security with almost no penalty in terms of efficiency. More details follow.
Keeping the practical applications in mind, we focus on the (natural) setting where a server interacts with multiple clients. The server uses a common set-up to establish the long-term public parameter which can be re-used each time the set-intersection is computed, possibly with different clients.
Most of the works mentioned earlier regard PSI to be a particular case of general MPC protocol, while some of the attempts at explicit definitions are quite informal. 1 Our definition of PSI customised for the MI setting consists of two algorithms: i) a Set-up algorithm used by the server to generate the long-term, common parameter; and ii) an interactive Set-Intersection algorithm used to compute the actual intersection. A more formal definition follows. Set-up, G(1 κ ): The algorithm is used by the server for the common set-up: the long-term public parameter pp and the server's secret sk (which could be null) are generated as a result. Set-Intersection, I s (S, sk), I c (C) (pp): The algorithm, which is interactive, is run jointly by the server S and the client C, each having its private (nonempty) sets S and C respectively. At the end of the interaction the client learns the intersection of the sets whereas the server learns nothing; i.e.
Note that, by default, both parties learn the cardinality of the other party's set. Most of the PSI protocols either fit into, or can be modified appropriately to fit Definition 1.1: e.g., the protocol F4 which we alluded to earlier is actually using the above setting. However, some protocols do not: e.g., the schemes based on homomorphic encryption [23,18] are in the "reverse" set-up (i.e., the client generates the public parameter).

1.3.1.
Modelling MI-security. The stand-alone security of PSI protocols in the malicious setting is argued using the simulation paradigm and follows the security definition for two-party computation (see [24, §7.2]). In the HbC setting, one can use simpler notions that are equivalent to the simulation paradigm (e.g., indistinguishability of views, existence of simulator etc.). We refer the reader to §2.1 for the basic definitions of client and server privacy in the HbC setting (IND-CP and SIM-SP, respectively). Arguing server privacy of even some of the basic PSI protocols using the simulation-based definition becomes quite involved and lengthy (e.g., see [20]) -things are bound to get further complex in the multi-interaction setting. To simplify the whole process, we first come up with simple indistinguishability-based (IND) notions for MI-security. However, for the sake of completeness (and intuition), we give the corresponding simulation-based (SIM) definition too. The protocol definition (Definition 1.1), in conjunction with the attacks that we described earlier, lead us to natural notions of security. We start by formalising the notion of server unlinkability through IND-SU and, then, lift this notion to get our central definition: server privacy in the multi-interaction setting (n-IND-SP and (n,m)-IND-SP).
We come up with the corresponding client-side definitions (IND-CU and n-IND-CP) as well. In addition to formalising the notions, we also study the relationship between them. There is a strict hierarchy for the server-side notions (see Figure 2): the separation between the notions follows from natural examples. The client-side notions n-IND-CP and IND-CU, on the other hand, collapse to basic client privacy (see Figure 3). Finally, on putting together everything, we have: A PSI protocol is said to be unlinkable when it is both IND-SU and IND-CU-secure. A PSI protocol is said to be MI-secure when it is both n-IND-SP and 1-IND-CP-secure. Remark 1. The focus of the current work is to investigate the problem of constructing efficient PSI in the realistic multi-interaction setting. In this context it's worth recalling the works on security definition for two-party key exchange where both SIM and IND based notions were used [6,4,12,13]. Building on prior works, Canetti and Krawczyk in [12] formalized the security of key exchange with multiple parties each capable of establishing multiple sessions. Our definition of PSI with MI-security is similar in spirit to the approach of [12] as both model security when multiple sessions are executed. In a subsequent work [13], Canetti and Krawczyk looked at the UC notion of single session key-exchange protocols. The single session protocol may have access to a long term static key (much like the common set-up in PSI) and according to [13], the notion of UC with joint state [14] can be used to argue security of the multi-session case. Some of the PSI papers [27,29] do consider the question of composition using the UC framework [11]. However, to the best of our knowledge, UC-security of PSI protocols with a common set-up has never been addressed in the literature and could be a potential future direction of research.
1.3.2. MI-secure PSI protocols. Finally, we investigate a set of existing protocols that are efficient but were originally designed for the stand-alone setting. Our aim here is to achieve MI-security with as little modification as possible. The protocols we derive involve simple tweaks with performance comparable to their parent protocols. We construct three protocols namely Σ (Figure 1), Π ( Figure 4) and Ψ ( Figure 5). Σ is an unlinkable protocol which is derived from the protocol F4 (hence, RSA-based) and retains all the advantages of the original protocol. Π is also derived from F4, but is MI-secure. Protocol Ψ, on the other hand, is obtained from the Jarecki-Liu protocol [32] and is MI-secure. We also observe that the " Figure  3" protocol given in [20] -henceforth referred to as the F3-protocol -achieves MI-security. Another feature worth mentioning is that our security reductions in the MI-security setting are based on standard assumptions like RSA and GDH. In contrast, the security arguments of the parent protocols in the stand-alone setting were based on non-standard one-more type assumptions. As summarised in Table 1, our results establish that it is possible to achieve the stronger MI-security based on standard computational assumptions without incurring any significant additional cost. An interesting open problem is to design more efficient MI-secure PSI protocol which allows pre-computation that can be reused across multiple executions.
1.4. Notation and conventions. We adopt the notation commonly used in the literature. In addition, we follow some conventions to facilitate easier reading of the paper. We use C and S, respectively, to denote the client and the server set. We use the letter i and j for indexing the client and the server set respectively. Thus, if v and w denote the upper bound on the number of elements in the client and server Protocol MI-secure Computation (Exp.) Communication Assumption Client Server (bits) F4 [20] No [20] Yes 2v + 2 v + w + 1 2(v + 1)|p| + wτ GDH Table 1. Comparison of protocols; cardinality of client (resp. server) set is v (resp. w). In protocols F4, Σ and Π the server takes v +w exponentiations where both the exponent and modulus are of size |N | bits. Since the server knows the factorization of N (p and q), by using the Chinese remainder theorem, the computation cost for the server can be reduced to 2(v + w) exponentiations, where both the exponent and modulus are of size |N |/2 bits (refer to [36,Fact 14.75] and [21]). Note that we give an improved security analysis of protocol F3 (the original reduction is based on one-more GDH assumption). See §5 for further details. Security for MPC protocols are argued using the notion of a "view" [24]. The view of a party P (in the stand-alone setting) consists of: its input, its internal coin tosses and the message it exchanges with the other parties, i.e. (x, r, m 1 , . . . , m t ). For a two-party protocol, we denote it by View P (x, y) where y is the other party's input. The generalisation of the view to include multiple interactions (of a twoparty protocol) is straightforward: it consists of the collection of views (its input, its internal coin tosses and the message it exchanges with the other party) in each round of interaction, i.e.
. We use the following notation.
. It is to be interpreted as the view of the party P when it engages in n interactions, where its own input in round of interaction is x ( ) and the other party's input is y ( ) . Note that the other parties involved need not be the same.
1.4.1. Organisation. The basic security definitions for PSI along with the complexity assumptions that are relevant to the paper are given in §2. We elaborate and, then, formalise the notion of server unlinkability in §3. In §4 we develop the notion of MI-security through the cross-intersection attack and also study its relationship with the other existing notions. Subsequently, in §5, we construct a few MI-secure protocols. Finally, we end with the concluding remarks in §6. Security arguments for the protocols in §5 are given in full detail in Appendix A.

Preliminaries
2.1. Basic definitions. A function µ : N → R is negligible if for any n > 0, we have |µ(x)| < 1/k n for sufficiently large x. Two random variables X and Y are computationally indistinguishable, denoted by X c ≡ Y , if for every PPT distinguisher D, the value |P(D(X)) − P(D(Y ))| is negligible. Computational distinguishability is denoted by c ≡.
2.1.1. Basic privacy: security in the stand-alone setting. An honest-but-curious (HbC) party is assumed to follow the protocol specification. However, it might try to learn information on set elements of the other participating party from the transcript of the protocol executions. We provide a formal security definition for basic client and server privacy that are derived from [24, Definition 7.2.1] (also see [2]): client privacy is argued using indistinguishability of views whereas server privacy using the notion of a "simulator". Definition 2.1 (IND-CP: basic client privacy). For every PPT algorithm A s that plays the role of server S, for every server set S, and for any client input sets (C (0) , C (1) ) such that |C (0) | = |C (1) |, two views of A s corresponding to client C's inputs: C (0) and C (1) , are computationally indistinguishable. i.e., Definition 2.2 (SIM-SP: basic server privacy). Let View C (C, S) be a random variable representing C's view during the execution of the protocol with inputs C, S. There exists a PPT algorithm C * such that In other words, there exists a "simulator" C * which can generate a view for the client (by taking as input just C and C ∩S) that is computationally indistinguishable from the view of the client when it executes the actual protocol with the server. Hence, C can learn only that much of information as can be inferred from the client set and the intersection.

Complexity assumptions.
In this subsection, we list the computational assumptions that are relevant to the paper.
Assumption 1 (RSA: Standard RSA assumption). Let N be the product of two large distinct primes p, q.
Assumption 2 (GDH: Gap Diffie-Hellman assumption). Let G be a group of prime order p, generated by g. Given X, Y $ ← − G where X = g α , Y = g β for some α, β ∈ Z * p and a decision Diffie-Hellman (DDH) oracle O DDH , finding g αβ is (t, ε)-hard. DDH oracle takes input as (X = g a , Y = g b , Z) ∈ G 3 and outputs 1 if Z = g ab , otherwise outputs 0. That is, for every PPT algorithm A that runs in polynomial time t, In other words, the computational Diffie-Hellman problem is hard even if the decision Diffie-Hellman problem is easy.

Server unlinkability
Our starting point is the notion of (server/client) unlinkability that was introduced in [20]. They informally described server unlinkability and client unlinkability as optional security requirements for PSI protocols. When it comes to concrete protocols, the paper claimed that protocol F3 achieves both server and client unlinkability while protocol F4 achieves only client unlinkability. The paper also briefly mentioned why server unlinkability is violated in F4 and discussed some fixes. However, a precise formulation of the notion of unlinkability is necessary to enable any sort of formal security claim. Here we briefly recall how server unlinkability fails in protocol F4 and then proceed to formal definition of the notion. Finally, we show how F4 can be modified to obtain a server-unlinkable protocol Σ, without incurring any significant efficiency loss.
3.1. F4-protocol and server unlinkability. The F4-protocol is based on the idea of RSA blind signature [15]. On a high level, the server acts as the signer whereas the client acts as the verifier: thus, it is the server which has to generate the RSA parameters (keeping the secret key d to itself). Hence the protocol does follow Definition 1.1. The client uses the blinding property of RSA to obtain signatures on its own elements. These signatures are then input to a hash function H 2 to obtain the tags. The server, along with the blinded signatures, sends tags on its own elements. The client, then, compares the two set of tags to compute the intersection. The deterministic nature of the tags (which, in turn, is due to the deterministic nature of RSA signature) is crucial for the correctness to hold. 2 We refer the reader to Figure 7 (in Appendix A.3) for the complete description of the protocol. The basic privacy of the protocol is proved under the One-More RSA (OM-RSA) assumption (Assumption 3 in Appendix A.4). Linking two rounds. Simply put, server unlinkability requires an adversarial client not to be able to distinguish between two server sets involved in two rounds of interaction. The authors of F4-protocol note that, as the server-tags are deterministic, their protocol does not satisfy server unlinkability. The attack is quite simple: the adversarial client has to just compare the server tags obtained during two rounds of interaction. Any change in server elements results in change in the server tags (and vice-versa). This could have devastating consequences when the protocol is used in real-life applications. For instance, suppose that protocol F4 is used as the building block in OpenConflict. Even though a cheating player is unable to completely undo the effect of fog of war, he is still able to monitor any changes in the other player's resources (e.g., troop movements). Thus, there is a need to formalise even a basic notion such as server unlinkability.

Remark 2.
Note that when the authors [20] claim (lack of) server/client unlinkability, they are implicitly assuming more than one interactions with a common set-up. The RSA parameters (N, e, d) are re-used across the two rounds. Otherwise, running the protocol twice won't allow the client to learn changes in the server set: the RSA exponent e changes and so do the tags. This in turn takes away most of the amortized efficiency advantages of F4-protocol in the form of off-line precomputation.

3.2.
Formalising server unlinkability. Informally, server unlinkability requires that an adversarial client should not be able to "tell if any two instances of interactions are related, i.e., executed on the same inputs by the server" [20]. Let's assume for simplicity that the client sets for both the rounds are same (C). Also, let S (0) and S (1) denote the server sets involved. 3 The server sets, by definition, can be trivially linked if the intersections S (0) ∩ C and S (1) ∩ C are different. Thus, under the constraint that S (0) ∩ C = S (1) ∩ C what we intuitively require is: . That is, an adversarial client should not be able to figure out whether it is interacting with the same server set or not. 4 Thus we arrive at the following game-based definition.
Definition 3.1 (IND-SU). The notion of server unlinkability for a PSI scheme is argued in terms of the following game between a challenger S * and an adversarial client A c .
Set-up: S * runs the Set-up algorithm to obtain public parameters pp and the secret key sk. It passes pp to A c . Challenge: A c commits to a client set C and two server sets S (0) and S (1) such that C ∩ S (0) = C ∩ S (1) . S * tosses a coin b and runs the Set-Intersection algorithm twice to generate View 2 C,pp ((S (0) , C), (S (b) , C)) and sends it to A c . A c returns a bit b and wins the game if b = b.
Remark 3 (SIM-SU). Definition 3.1 suffices for all technical purposes. However, for sake of completeness, we describe the simulation-based definition as well. Server unlinkability is ensured if there exists a PPT algorithm D * such that (1) , it follows that the LHS is computationally indistinguishable from View 2 C,pp ((C, S (0) ), (C, S (0) )) (for all client and server sets) as well.
3.3. Protocol Σ. In order to fix the problem of server linkability with protocol F4, [20] came up with two suggestions: i) select a new set of RSA parameters for each protocol instance; or ii) change the hash function H 1 for the server for each protocol instance. Note that both suggestions take one away from the common set-up originally used in F4-protocol and hence, some of the associated efficiency advantages. Here we suggest a protocol Σ by modifying the protocol F4 retaining the common set-up and associated efficiency advantages and formally show that the protocol is client/server unlinkable. The only modification is in tag computation: in each interaction of the protocol, the server randomises the computation of the 3 As we are not considering size-hiding PSI [2], we implicitly assume that both the server sets have the same cardinality: else, it is trivial to link two interactions. 4 We have used the same client set for both the rounds for the sake of simplicity. One may as well have the stronger condition tags. Computing different tags corresponding to an element in different interactions prevents the client from relating two interactions of the protocol. The complete description is given in Figure 1.
Set-up, G(1 κ ): The server generates the public parameters pp := (N, e, H 1 , H 2 ) and a secret key sk := d, where d ≡ e −1 (mod ϕ(N )). Here, H 1 and H 2 are two hash functions such that Let h c,i and h s,j denote H 1 (c i ) and H 1 (s j ) respectively. The steps involved are given below.
k s,j , r s ) for all j, except with a negligible probability of hash collision. Efficiency. Our protocol is as efficient as the original protocol as it retains the online/off-line property. On the contrary, both the suggestions in [20] no longer are.
3.3.1. Security. We show that Σ is server unlinkable assuming that the RSA problem is hard (Assumption 1). Recall that the security of original F4-protocol (without server unlinkability property) is based on the non-standard OM-RSA assumption.
Theorem 3.2. The protocol Σ is unlinkable under the RSA assumption with the hash functions modelled as random oracles.
The detailed proof is given in Appendix A.4. The server unlinkability is based on the RSA assumption (Lemma A.1) whereas the client privacy in maintained unconditionally (Lemma A.3).
Remark 4. In the security argument for server unlinkability of Σ we have relaxed the condition in challenge by requiring the server sets to differ by a single element. In other words, we set We get an alternative definition with this relaxation. The only difference from Definition 3.1 is in the challenge phase: the adversary directly commits to (C, S, s * 0 , s * 1 ) instead of (C, S (0) , S (1) ). It is not difficult to prove that these two formulations are equivalent: one can use a simple hybrid argument as in the proof of Theorem 4.4.

PSI in the multiple-interaction setting
We argue that in most scenarios there are more pressing and subtle security concerns beyond unlinkability. This is motivated by demonstrating the "crossintersection" (CI) attack on the protocols Σ (which we showed to be IND-SU-secure) and F4. Thus there is a need to model CI-attack for PSI. We then define the notion of MI-security in both IND and SIM settings and study their relationship.

4.1.
Cross-intersection attack. By participating in a PSI protocol, the client is supposed to learn the intersection only for that particular interaction. In a crossintersection (CI) attack the client, although following the protocol steps, tries to gain information about server elements other than intersection in that particular interaction by utilizing the transcript of other interactions. For example let C ( ) and S ( ) be the client and server sets, respectively, in the th round of interaction. In a cross-intersection attack, the client attempts to learn C (i) ∩ S (j) where i = j.

4.1.1.
Computing cross-intersection. Protocol F4. The deterministic server-tags in protocol F4 causes far more devastation than just linking two server sets. To see this consider two separate rounds of interactions between the server S and an (adversarial) client A c . Let S (0) , S (1) and C (0) , C (1) , respectively, be the server and client sets, where At the end of first round of interaction, A c uses k corresponding to the element c i ∈ C (0) . It also receives the set of server tags T (0) which enables it to determine C (0) ∩ S (0) . The same happens for the second round of interaction. However, as the server tags are deterministic, A c can easily find the intersection of set C (0) with S (1) by matching the tags t (0) i with the set T (1) . In a similar fashion, it can find C (1) ∩ S (0) . In general, if there are n rounds of interactions, the client can learn C (i) ∩ S (j) , for i, j = 1, . . . , n, in addition to C ( ) ∩ S ( ) for = 1, . . . , n.
Thus the common set-up plays the role of double-edged sword in protocol F4. Allowing pre-computation it makes F4 one of the most efficient PSI protocols while simultaneously enabling an adversarial client to mount a realistic attack if the protocol is executed multiple times.
Protocol Σ. Even though we had shown that protocol Σ is IND-SU-secure, we observe that the attack on F4 that we discussed works on Σ as well. Since the randomiser r s is sent in the clear, the server tags in protocol Σ are "effectively" deterministic. Hence, an adversarial client can compute any cross intersection it wants.
Clearly cross-intersection attack is an important security feature of the PSI functionality that goes beyond server unlinkability. The attack has serious repercussions when it comes to practice. Recall the example of airlines company and DHS: every time a new entry is made in its own watch-list, the DHS can go over the past protocol transcripts to find out whether that person was in the passengers' list in the past. In the gaming example, computing cross-intersection enables a cheating client to locate the current position of the server troops rather than just detecting troop movement (even though the platform is secured using OpenConflict). This is a definite breach of server privacy. However, the existing security definitions, including unlinkability, do not capture such attacks.

4.2.
Server privacy in the multiple-interaction setting. We now formulate an appropriate security model for PSI protocol in multiple interaction setting. We give two definitions for this purpose: a SIM-based notion (denoted by n-SIM-SP) and an IND-based notion (denoted by n-IND-SP) and study the relationship between these notions and then relate them with the notion of server unlinkability in §4.3.

Simulation-based definition.
Definition 4.1 (n-SIM-SP). Let the random variable representing C's view during the execution of protocol (with inputs C ( ) and S ( ) in the th interaction) be defined as in (1). Then, the PSI protocol is secure if there exists a PPT algorithm D * such that We, henceforth denote the distributions by D s (the "simulated" distribution on the LHS) and D v (the distribution corresponding to the "view" of the adversary, in the RHS) respectively. Definition 4.1 captures the realistic scenario where the server is engaged in the PSI protocol multiple times with (possibly different) adversarial client. The definition stipulates that the protocol maintains server privacy even when all the clients collude. The trivial information that the adversary can learn in such a scenario is the union of the individual set-intersections. Therefore, D * should be able to simulate the client-view by taking as input the client sets together with the intersections and the adversary should not be able to (computationally) distinguish this from the actual protocol view. By implication, an adversarial client can learn only that much of information which can be inferred from C ( ) and C ( ) ∩ S ( ) (for = 1 to n).

4.2.2.
Indistinguishability-based definition. A major hurdle in giving an IND-based definition is that we have to somehow capture the interactive Set-Intersection algorithm. In the HbC setting the adversary follows the protocol specification, so it suffices to give the protocol view to the adversary. We model this by giving the adversary access to a "view oracle" O v through which it can adaptively obtain views corresponding to the sets of its choice. Set-up: S * runs the Set-up algorithm to obtain public parameters pp and the secret key sk. It passes pp to A c . View Query, Phase 1: O v (C, S): A c can adaptively obtain views corresponding to arbitrary client and server sets through an oracle O v . S * responds by returning a view View C (C, S), which is generated by running the Set-Intersection algorithm, to A c . Note that S * has all the inputs required to generate the view. Challenge: A c sends the challenge sets (C * , S * ) along with two sets of server One can further simplify the server privacy definition by setting m = 1, i.e. the two challenge server sets differ by a single element. Set-up: S * runs the Set-up algorithm to obtain public parameters pp and the secret key sk. It passes pp to A c . View Query, Phase 1: O v (C, S): A c can adaptively obtain views corresponding to arbitrary client and server sets through an oracle O v . S * responds by returning a view View C (C, S), which is generated by running the Set-Intersection algorithm, to A c . Note that S * has all the inputs required to generate the view. Challenge: A c sends the challenge sets (C * , S * ) along with two server elements (s * 0 , s * 1 ) to S * provided that s * 0 , s * 1 / ∈ C * , S * (else, they must be equal). S * picks a bit b uniformly at random and returns  The reduction. Let C denote the n-IND-SP challenger. A 1 passes the public parameters pp that it obtains from C to A m ; it also relays to C all the queries that A m makes to the view oracle and returns the views. On challenge (C * , S * , (S * 0 , S * 1 )), A 1 constructs the set S * * := S * ∪S * ∪ {s * 0,1 , . . . s * 0,i * −1 , s * 1,i * +1 . . . , s * 1,m }, where 0 ≤ i * ≤ m is picked randomly. A 1 then sends (C * , S * * , (s * 0,i * , s * 1,i * )) as its challenge to C. It then passes the resulting challenge view corresponding to (C * , S * * ∪ {s * b,i * }) to A m (where b is the bit flipped by C and is unknown to A 1 ). Further queries to the view oracle are handled as before the challenge. Finally, A m returns to C the bit that A 1 outputs. Note that if b = 0, A 1 effectively plays the game (n, m, i * )-IND-SP, whereas if b = 1, it plays the game (n, m, i * + 1)-IND-SP.
We use the above definition of server privacy in our security arguments which basically requires the following two distributions to be computationally indistinguishable: Note that if a protocol is prone to the CI attack, then an adversary will be trivially able to win the game. 5

4.3.
Relationship between the definitions. Figure 2 sums up the relationship between the security definitions for server privacy. As in the case of encryption schemes, it turns out that the SIM-based definition (n-SIM-SP) is equivalent to the IND-based one (n-IND-SP). We argue this in Theorem 4.5. There is also a strict hierarchy among the notions of basic server privacy, server unlinkability and full server privacy: IND-SP IND-SU n-IND-SP. The first separation is due to server-linkability (protocol F4: IND-SP-secure but not IND-SU-secure) whereas the second one is due to the cross-intersection attack (protocol Σ: IND-SU-secure but not n-IND-SP-secure). We now proceed to our main theorem. Proof (Overview). As in the case of encryption schemes [25], the forward direction (Claim 4.5.2) is relatively straightforward, whereas the reverse direction (Claim 4.5.1) is a bit involved. The latter proceeds via a hybrid argument in which the distinguishability of the intermediate distributions is used to break the indistinguishability of the distributions given in (4). A detailed proof follows. 5 The adversary arbitrarily chooses a server element s * 0 as one of the challenge elements, and then obtains a view for sets (C, S) where C is chosen such that s * 0 ∈ C but not s * 1 . Let's denote it by View 1 . Next, it arbitrarily chooses C * , S * as the challenge sets, an additional element s * 1 as the second challenge element and presents (C * , S * , s * 0 , s * 1 ) as the challenge to S * . Let View * denote the challenge view thus obtained. If the cross-intersection obtained from the views View 1 and View * contains the element s * 0 then it outputs 0 to the S * . It is easy to verify that the adversary always wins the game.  Proof. We proceed via contradiction: if the PSI protocol is not n-SIM-SP-secure, we come up with an n-IND-SP-adversary. But first, in order to simplify the proof, we introduce a "substitute" distribution D r : where R ( ) is a set of random elements (with |R ( ) | = |S ( ) \ C ( ) |). Now, recall the distributions D v (the distribution corresponding to the view of the client) and D s (the distribution corresponding to the output of the simulator D * ) from (3). It is not difficult to see that D r is computationally indistinguishable 6 from D s : another way of looking at server privacy is that the client's view should not change when the server elements that are not in the intersection are replaced by random elements. As a consequence, we can rephrase server privacy: if D r and D v are indistinguishable then the scheme maintains server privacy. The hybrid. If a PSI protocol is not secure according to the n-SIM-SP definition, then the distribution D s generated by any simulator D * is distinguishable from D v . This, in turn, implies D r and D v are also distinguishable. The next step is to prove that D r which yields an n-IND-SP adversary. This is achieved through a hybrid argument. Consider the series of intermediate distributions where varies from 1 to n, j from 0 to w and there are t elements in the intersection (n and w denote the bound on the number of rounds and the size of server set, respectively). Also, s ( ) j denotes, for the th round, the j th server element which is not in the intersection. D The distinguisher. A va be an algorithm which (ε, t)-distinguishes D v from D r . We establish that the same algorithm can be used to (ε , t )-distinguish D * 0 from D * 1 . It follows from our definitions that: which implies that A va also distinguishes D * 0 from D * 1 . That concludes the proof. Proof. Once again, we make use of the substitute distribution D a that is given in (5). Since the protocol is n-SIM-SP-secure, there exists a simulator D * such that

4.4.
Client-side definitions. The security definition for client privacy is fundamentally different from that for the server privacy due to the inherent asymmetry in the PSI protocol (the server learns nothing other than the size of client set). This simplifies the client-side picture by quite an extent (see Figure 3). We start by modifying the notion of basic client privacy (IND-CP) (reproduced in Definition 2.1, §2) to get the notion of 1-IND-CP. The definition is inspired by the security (blindness) of blind signature schemes originally given in [33]. In order to capture the situation where the key-pair is honestly generated, it is the challenger (although it acts as the client in this particular game) who generates the key-pair. The formal definition follows. Full security. We show that the above notion is sufficient for client privacy of PSI with common set-up. In particular, due to asymmetry in the PSI definition, the client privacy in the multiple interaction setting (n-IND-CP, which can be defined in an analogous way) collapses to stand-alone client privacy. As client unlinkability is a special case of n-IND-CP, it collapses to stand-alone privacy as well. Proof. Since the adversary receives the secret key at the beginning of the game, we can do away with the view oracle: the adversary has all the information necessary to generate the views by itself. Thus, client privacy in the MI setting is reduced to the stand-alone case. Figure 3. Relationship between the security definitions for client privacy.

Protocols
We construct two protocols namely Π ( Figure 4) and Ψ ( Figure 5). Π is derived from protocol F4 and hence is based in the RSA setting. Ψ, on the other hand, is obtained from the Jarecki-Liu protocol [32] and hence is described in the cyclic group setting. We also note that the " Figure 3" protocol in [20] is secure under multiple interaction with common set-up. The performance of these protocols is comparable to their parent protocols thus demonstrating that it is possible to achieve the stronger MI-security without incurring any significant additional cost (see Table 1). In addition, in both Π and Ψ server can precompute its tags offline, leading to further efficiency gains. 5.1. Protocol Π. The construction of protocol Π is analogous to that of PSS from RSA-FDH [7,6]. Recall that in PSS, the signature is computed on a randomised message and the randomiser used is sent as a part of the signature. In protocol Π, this randomiser is chosen by the server and communicated to the client at the beginning of Set Interaction. Thus, there is an additional round involved. The details of the construction is given in Figure 4.   If c i ∈ C∩S, then there exists s j ∈ S such that c i = s j , h c,i = h s,j and k c,i = k s,j , hence, tag t i = H 2 (c i , k c,i ) = H 2 (s j , k s,j ) = t j . And if c i / ∈ C ∩ S, then c i = s j , h c,i = h s,j and k c,i = k s,j for all j, hence, tag t i = H 2 (c i , k c,i ) will be different from t j = H 2 (s j , k s,j ) for all j, except with negligible probability of hash collision.
Theorem 5.1. The protocol Π is MI-secure under the RSA assumption with the hash functions modelled as random oracles.
The detailed proof is given in Appendix A.5. The server privacy is based on the standard RSA assumption (Lemma A.4) whereas the client privacy is maintained unconditionally (Lemma A.5).
Remark 6. We get a tight reduction for server privacy based on the standard RSA assumption. However this comes at the cost of one additional round of interaction to communicate the randomiser r s . This additional round can be traded for a less tight reduction in the argument for server privacy. We exploit the fact that the security argument only requires that r s should be unique (like a nonce) across different protocol runs. To avoid the interaction, though, it has to be predictable for both the sides (e.g., one could use a loosely synchronised clock, or session-ids as in key-agreement protocols). However, choosing such an r s would cause the security argument for server privacy (Lemma A.4) to fail 7 . We give an alternative proof for server privacy in the modified protocol (Lemma A.6) using the partitioning technique. But it comes at a price of polynomial degradation in tightness.

5.2.
Protocol Ψ. The protocol Ψ is derived from [32] and hence set in cyclic groups of prime order. We prove that it is MI-secure under the assumption that GDH problem is hard in these groups. Description. Let G be a group of prime order p generated by g and H 1 and H 2 be two hash functions defined as Server runs setup algorithm to generate the public parameters. Client and server jointly interact with their input sets C and S respectively and at the end client computes intersection of both sets i.e. C ∩ S. Let h c,i and h s,j be the output of H 1 hash function on c i and s j respectively. The protocol follows in Figure 5.

Server
Client The detailed proof is given in Appendix A.6. The server privacy is based on the GDH assumption (Lemma A.7) whereas the client privacy in maintained unconditionally (Lemma A.8).

Protocol F3.
We refer the reader to Figure 6 (in Appendix A.2) for the description of the protocol. We note that the protocol achieves multiple interaction security with common set-up. However, the performance of protocol Ψ is slightly better than protocol F3. Security is based on the GDH assumption with the hash functions modelled as random oracle. As the proof strategy is similar to that of protocol Ψ, we omit the details. Note that the original security argument [20] is based on the stronger one-more gap Diffie-Hellman (OM-GDH) assumption.

Conclusion
In this paper, we have placed the problem of constructing efficient PSI in the realistic multi-interaction environment on a formal theoretical foundation. Our framework facilitates better designs along with easier proofs, and we demonstrated its efficacy by designing several efficient protocols that are multi-interaction secure with common set-up. An interesting open problem is to construct protocols where it is possible to take advantage of pre-computation for further efficiency gains. A similar study for the malicious model would also be an interesting future direction. So would be coming up with a more inclusive definition for PSI, say like mutual PSI. A.1.1. Simulating the random oracles. Most of the security arguments that are given here involve random-oracle programming. Therefore we set some common ground-rules regarding the simulation of these random oracles, primarily for ease of understanding. The queries are handled with the aid of tables. The table contains, on a high level, ordered tuples of the form x, h, r where, x is the input to the hash function, h the response to that query. The field r is used to store auxiliary information concerning the query: e.g., it could store a status bit. We say that a random oracle query H(x) is fresh, if it is the first query involving x. Note that if there exists no tuple x i , h i , r i in the table with x i = x then the query is fresh. The way fresh queries are handled varies from proof to proof. However, if a particular query is not fresh then, in order to maintain consistency, the random oracle has to respond with the same value it output during the previous query. In other words, if there exists a tuple x i , h i , r i with x i = x, it has to respond with h i . In our security arguments, we consider only fresh queries. Each table L has two associated interfaces: Add(·, ·, ·) and Retrieve(·). Add(·, ·, ·) is used to insert a new element in the table and by Retrieve(x), we mean "retrieve the tuple x i , h i , r i with x i = x" (assuming such a tuple exists).
A.1.2. Coron's partitioning technique. In some security arguments, we use the partitioning technique that was introduced by Coron in the security proof of RSA-FDH [17]. We describe it in the context of signature -the basic idea is to divide the message space M into two disjoint sets, M 1 and M 2 , depending upon the outcome of a biased coin δ. The simulator, then, programs the random oracle in such a way that it is equipped to respond to signature queries on messages from M 1 ; however, it fails if the adversary signature queries on any message from M 2 (say, because the problem instance is embedded only in elements of M 2 ). Finally, the simulator hopes that the adversary produces a forgery on a message from M 2 . The optimal size of these sets is determined on analysis.
A.2. Protocol "F3". In Figure 6 we describe a version of protocol F3 from [20] that has been crafted according to Definition 1.1 and set in a general cyclic group. Let G = g be a group of prime order p. Server Client   Figure 8. Since A c gets random tag corresponding to s * b , b ∈ R {0, 1}; to be successful (with a non-negligible probability), it must have queried the random oracle H 2 on one of (s * 0 , k * s,0 , r * s ), (s * 0 , k * s,0 ,r * s ) or (s * 1 , k * s,1 ,r * s ), where r * s (resp.r * s ) is the randomiser used in first (resp. second) interaction in the server unlinkability game. Hence R gets the solution during phase 2 of H 2 oracle queries.
Analysis. R aborts the game during the challenge phase if: i) δ i = 0 for any c i ∈ C (abort 1 ); or ii) δ * = 1 for s * 0 or s * 1 (abort 2 ). The probability that R does not abort with failure in the security game is, thus, P(¬abort) = (1 − ρ) v · ρ 2 . The expression is maximized at ρ = 2/(v + 2) where we get P(¬abort) = 4/(e 2 (v + 2) 2 ). R is successful when it does not abort and A c wins the game. Therefore where t e is the time to compute an exponentiation operation. It takes an exponentiation to answer each H 1 oracle queries and an exponentiation to answer each H 2 oracle queries in phase 2 if a query is of the form (s * 0 , k, r) or (s * 1 , k, r). Next, we give an alternative tight reduction based on the following one-more assumption.
Lemma A.2. Let A c be an adversarial client that ( , t, q 1 , q 2 )-breaks protocol Σ in the IND-SU model. If H 1 and H 2 are modelled as random oracles, we can construct an algorithm R that ( , t )-breaks the OM-RSA assumption, where ≥ and t ≤ t + q 2 t e .
Proof (Sketch). The proof, on many levels, proceeds similar to that of Lemma A.1. Recall that we had used the partitioning technique to selectively plug in the problem instance, which in turn, led to the aborts abort 1 and abort 2 . The major difference from the previous proof is that the stronger OM-RSA assumption helps us to avoid these aborts, leading to a tight reduction. The idea is to plug in the problem instance for all the queries to the H 1 -oracle, and then, in the challenge phase, use the RSA oracle to obtain signatures on the client elements. The resulting security argument is much simpler than the previous one. The details are given below.
For all the queries made to the H 1 -oracle, R responds with the challenge z i obtained from the challenge oracle O c . In the challenge phase, to compute y i = h d c,i = z d i , it calls RSA oracle O RSA,e on z i . If A c wins the game, it must have queried H 2 -oracle either on (s * 0 , k * s,0 ) or (s * 1 , k * s,1 ), along with the corresponding r s . As soon as it makes the query, R gets the one more solution required to win the OM-RSA game.
Analysis. Since no abort is involved, the reduction is tight: R is successful whenever A wins the game with non-negligible advantage, and thus ≥ . The time taken by R is t ≥ t + q 2 t e , where t e is the time to compute an exponentiation. It takes an exponentiation to answer each H 2 oracle query in phase 2 if a query is in the form (s * 0 , k, r) or (s * 1 , k, r). Lemma A.3. Protocol Σ is information-theoretically secure in the IND-CU model.
Proof (Sketch). The server gets y i = h c,i · r e c,i corresponding to each client element. Since r c,i is chosen uniformly at random, each y i is also uniformly distributed in Z * N . Therefore, linking two interactions is not possible for an adversary. A.5. Protocol Π: security argument.
Lemma A.4. Let A c be an adversarial client that ( , t, q 1 , q 2 )-breaks protocol Π in the n-IND-SP model. If H 1 and H 2 are modelled as random oracles, we can construct an algorithm R which ( , t )-breaks the RSA problem, where ≥ and t ≤ t + (q 1 + q 2 )t e .
Here q 1 and q 2 denote the upper bound on number of queries to H 1 and H 2 oracles respectively, and t e denotes the time taken for an exponentiation in Z * N . Proof. Let (N, y, e) be the instance of the RSA problem that R aims to solve. R sets (N, e) as the public parameter and passes it to the adversary A c . It allows A c access to two random oracles H 1 and H 2 along with the view oracle O v . As in the proof of Lemma A.1, the queries to the H 2 -oracle are split into two phases and the random oracles are maintained with the help of two tables L 1 and L 2 . L 1 contains an auxiliary field r which is used to store the e-th root of the hash-response (if known). The details of the reduction is provided in Figure 9.
At the end of the game, A c returns its guess b . In the case that it is successful (with a non-negligible probability), it will have queried the random oracle H 2 with either (s * 0 , k * s,0 ) or (s * 1 , k * s,1 ). R uses the queried k * s,b and the corresponding r * b to output the solution of the RSA problem in phase 2 of H 2 -oracle queries.  if (a = s * 0 ) ∧ (k e /(r * 0 ) e = y) then 4: solution := k/r * r * 0 , r * 1 $ ← − Z * N , h * s,0 := y · (r * 0 ) e , h * s,1 := y · (r * 1 ) e 8: L 1 .Add((s * 0 , r * s ), h * s,0 , r * 0 ), L 1 .Add((s * 0 , r * s ), h * s,1 , r * 1 ) 9: for all s j ∈ S * do Generate server-tags 10: H 1 (s j , r * s ), (s j , r * s ), r j , h s,j ← L 1 .Retrieve(s j , r * s ) 11: k s,j := r j , t j := H 2 (s j , k s,j ) 12: end for 13:  Analysis. R is successful whenever A c wins the game with non-negligible advantage, thus = . The time taken by R is t ≤ t + (q 1 + q 2 )t e , where t e is the time to compute an exponentiation operation. It takes an exponentiation to answer each H 1 oracle queries and an exponentiation to answer each H 2 oracle queries in phase 2 if a query is in the form (s * 0 , k) or (s * 1 , k).
At the end of the game A s returns its guess b . Now we claim that it cannot win the game with a non-negligible advantage as y * b = y * b for some r * c,b Hence A s cannot win with non-negligible advantage.
We now analyse server privacy of the modified protocol mentioned in Remark 6.
Lemma A.6. Let A c be an ( , t, q 1 , q 2 )-adversary against protocol Π in n-IND-SP model. If H 1 and H 2 are modelled as random oracle, we can construct an algorithm R which ( , t )-breaks RSA problem, where ≥ 1 v 2 q 2 v · and t ≤ t + (q 1 + q 2 )t e where q 1 and q 2 denote the upper bound on number of queries on H 1 -oracle and H 2 -oracle, v denotes upper bound of client's set size, q v denotes upper bound on number of view queries and t e denotes time to compute an exponentiation.
Proof. The proof goes almost similar to the proof of Lemma A.4. Here H 1 -oracle queries are modelled using the Coron's partitioning technique. On each H 1 -oracle query, R tosses a ρ biased coin to get δ (P(δ = 0) = ρ). Based on the value of δ, query is responded. If δ = 0, it plugs-in the problem instance as h = y ·r e , otherwise sets h = r e . H 2 -oracle queries of Phase 1 and Phase 2 are handled as in Lemma A.4. In the view query phase and challenge phase, for any c i ∈ C, if corresponding tuple in L 1 has δ = 0, then it aborts with failure. Also in the challenge phase, if tuple corresponding to either s * 0 or s * 1 has δ = 1, then it aborts with failure. These aborts with failure result in polynomial degradation in security reduction.
Analysis. R aborts with failure in view query phase and challenge phase if for any c i ∈ C the corresponding tuple in L 1 has δ = 0. It also aborts with failure in challenge phase in the case when tuple corresponding to either s * 0 or s * 1 has δ = 1 in L 1 . The probability that R does not abort with failure in the security game is This is maximized when ρ = 2/(v(q v + 1) + 2). Putting the value of ρ, we get P(¬abort) = 1 e 2 (v(q v + 1) + 2) 2 .
So the advantage of R in solving the RSA challenge is The time taken by R is t ≤ t + (q 1 + q 2 )t e , where t e is the time to compute an exponentiation operation. It takes an exponentiation to answer each H 1 oracle queries and an exponentiation to answer each H 2 oracle queries in phase 2 if a query is in the form (s * 0 , k) or (s * 1 , k). A.6. Protocol Ψ: security argument.
Lemma A.7. Let A c be an adversarial client that ( , t, q 1 , q 2 )-breaks protocol Ψ in the n-IND-SP model. If H 1 and H 2 are modelled as random oracles, we can construct an algorithm R which ( , t )-breaks gap Diffie-Hellman (GDH) problem, where ≥ v and t ≤ t + (q 1 + q 2 + (q v + 1)(v + w))t e .
Here q 1 and q 2 denote the upper bound on number of queries on H 1 -oracle and H 2 -oracle; v and w denote the upper bound on size of client and server input set, respectively; t e is the time to compute an exponentiation in G.
Proof. Let (G, g, p, A = g α , B = g β , O DDH ) be the instance of the GDH problem that R aims to solve. R gives public parameter pp : (G, g, p) to A c . It allows A c access to two random oracles H 1 and H 2 along with the view oracle O v . The queries to H 2 -oracle are split in two: The details of the reduction is given in Figure 10. At the end of the game A c returns b and wins the game if b = b. Note that corresponding to s * b , A c gets only a tag chosen randomly which is set as output of H 2 (s * b , (h * s,b ) α ). Hence to win the game A c must have to make query either H 2 (s * 0 , (h * s,0 ) α ) or H 2 (s * 1 , (h * s,1 ) α ). As A c makes this query R gets the solution of GDH challenge from H 2 -oracle queries in phase 2.
Analysis. R aborts with failure in the above game if i) for any c i ∈ C * the corresponding tuple c i , r i , h i , δ i in L 1 has δ i = 0 or ii) tuple corresponding to either s * 0 has δ * 0 = 1 or s * 1 has δ * 1 = 1. Probability that R does not abort in the game is This is maximized when ρ = 2/(v + 2). Putting the value of ρ, we get P(¬abort) = 4 e 2 (v + 2) 2 . R is successful when A wins the game with non-negligible advantage and it does not abort with failure in the game, which gives the following bound The time taken by R is t ≤ t + (q 1 + q 2 + (q v + 1)(v + w))t e , where t e is the time to compute an exponentiation operation. It takes an exponentiation to answer each H 1 oracle query and an exponentiation to answer each H 2 oracle query in phase 2 if a query is in the form (s * 0 , b) or (s * 1 , b). Further, (v + w) exponentiations to answer each view query and challenge phase takes (v + w) exponentiations.
Lemma A. 8. The protocol Ψ is information-theoretically secure in IND-CP model.
Proof. Challenger C * runs Set-up algorithm to generate public parameter pp = (G, g, p, H 1 , H 2 ) and gives it to A s .