Efficiency improvement techniques for private intersection-sum protocol using Bloom filter

A private set intersection protocol is one of the secure multi-party computation protocols, and allows participants to compute the intersection of their sets without revealing them to each other. Ion et al. proposed the private intersection-sum protocol (PI-Sum). The PI-Sum is one of the two-party private set intersection protocol. In the PI-Sum, two parties (say Alice and Bob) have the private sets A and B. Moreover, Bob additionaly has a rational integer associated with each element of B. The PI-Sum allows Bob to obtain the sum of the rational integers associated with the elements of A∩B\documentclass[12pt]{minimal} \usepackage{amsmath} \usepackage{wasysym} \usepackage{amsfonts} \usepackage{amssymb} \usepackage{amsbsy} \usepackage{mathrsfs} \usepackage{upgreek} \setlength{\oddsidemargin}{-69pt} \begin{document}$$A \cap B$$\end{document}. This paper proposes the efficiency improvement techniques for the PI-Sum. The proposed techniques are based on Bloom filters which are probabilistic data structures. More precisely, this paper proposes three protocols which are modifications of the PI-Sum. The proposed protocols are more efficient than the PI-Sum.


Introduction
Secure multi-party computation (SMC for short) protocols allow participants to compute a public function jointly while keeping their inputs private.A Private Set Intersection (PSI for short) protocol is one of the SMC protocols, and allows participants to compute the intersection of their sets without revealing them to each other.Since PSI protocols have many real-world applications (see for example [18,Sect. 2.6]), PSI protocols have extensively been studied in the last decade.
The first PSI protocol was proposed by Freedman et al. in [12] based on polynomial interpolation and an additive homomorphic encryption scheme.Later, Kisser et al. in [17] generalized the first PSI protocol in [12] to the multiparty setting.Le et al. in [19] proposed a two-party PSI protocol with an untrusted third party.There exists several techniques to construct PSI protocols such as public-key techniques [7,12,13,17,22], Map-To-Prime technique [16], oblivious transfer technique [25], and so on.

Related work
Ion et al. in [13] proposed the Private Intersection-Sum Protocol (PI-Sum for short).The PI-Sum is one of the twoparty PSI.In the PI-Sum, two parties (say Alice and Bob) have the private sets A and B.Moreover, Bob additionaly has a rational integer associated with each element of B.
The PI-Sum allows Bob to obtain the sum of the rational integers associated with the elements of A ∩ B .The PI- Sum ( [13,Figure 2] or Algorithm 1) is constructed by Precomputation Algorithm (Algorithm 2), Intersection Set Algorithm (Algorithm 3), and Intersection Sum Algorithm (Algorithm 4).Precomputation Algorithm (Algorithm 2) encrypts all the elements in A and B, respectively.Intersection Set Algorithm (Algorithm 3) computes A ∩ B without revealing the private sets A and B to each other.Intersection Sum Algorithm (Algorithm 4) computes the sum of the rational integers associated with the elements of A ∩ B without revealing the private sets A and B to each other.The PI-Sum is based on Diffie-Hellman key exchange [9].The PI-Sum requires to compute the cardinality ♯(A ∩ B) of the intersection set A ∩ B of input sets A and B for obtaining the output.By DDH (Decisional Difffie-Hellman) assumption, the security of the PI-Sum in the honest-but-curious model was proven by Ion et al. in [13].Participants in honest-but-curious model follow the steps in cryptographic protocol honestly, however the participants try to obtain the private information of other participant.For the input sets A and B, the PI-Sum requires to compute 2(♯A + ♯B) exponentiations for obtaining the output.In computing an online ad revenue, since the input set A is the set of the user who saw online ad, one may assume that the cardinality of A and B to be several hundreds of thousands to million.Therefore the PI-Sum needs to improve the efficiency for computing an online ad revenue.Other PI-Sum protocols can be found in [14,21].

Our contribution
This paper proposes the efficiency improvement techniques for the PI-Sum ( [13, Figure 2]).We have two interesting contributions as follows: -We propose a new PI-Sum protocol, say the proposed protocol 1 (Algorithm 7).The proposed protocol 1 is constructed by Precomputation Algorithm (Algorithm 2), the proposed algorithm for computing the private set intersection (Algorithm 8), and Intersection Sum Algorithm (Algorithm 4).Thus, the only difference between the PI-Sum ( [13, Figure 2] or Algorithm 1) and the proposed protocol 1 (Algorithm 7) is the phase of the computation of private set intersection (Algorithm 3 and Algorithm 8).The proposed protocol 1 uses a Bloom filter for computing the cardinality of the intersection of input sets A and B. Since Bloom filters are probabilistic data structures, the computational cost of Algorithm 8 is smaller than that of Algorithm 3. Thus, the proposed protocol 1 is more efficient than the PI-Sum (See Eqs.(9 and 10)).We assume that ♯A = ♯B , and let us define T ∶= ♯A ( = ♯B ).Then the computational cost of the proposed protocol 1 is about 1% smaller than that of the PI-Sum if T = 2 16 , and the computa- tional cost of the proposed protocol 1 is about 50% smaller than that of the PI-Sum if T = 2 22 .-This paper also proposes the proposed protocol 2 (Algorithm 10) and the proposed protocol 3 (Algorithm 11) for preventing the security problem described in Sect. 5.By adding an aborting functionality in the proposed protocol 2 and the proposed protocol 3, we can avoid the security problem described in Sect. 5.The computational costs of the proposed protocol 2 and the proposed protocol 3 are also discussed (See Eqs.(14 and 15)).
The rest of this paper is organized as follows: In Sect.2, we describe the notations in this paper, and we review the PI-Sum [13] and a Bloom filter [4].Section 3 proposes the proposed protocol 1 (Algorithm 7) that applying a Bloom filter in order to improve the efficiency of the computation about the intersection A ∩ B , and show the correct- ness of the proposed protocol 1.In Sect.4, we estimate the computational costs of the PI-Sum and the proposed protocol 1, and compare them.We show that the proposed protocol 1 is more efficient than the PI-Sum [13, Figure 2].In Sect.5, we propose the proposed protocol 2 and the proposed protocol 3 for preventing the above security problem.In Sect.6, we discuss the efficiency of the proposed protocols.Section 7 concludes the paper.

Mathematical preliminaries
In this section we describe the notations that will be used in this paper.For more details, we refer the reader to [20].For a finite set X, we denote by ♯X the cardinality of X.We use the symbol Inj(X, Y) to represent the set of all the injective maps from a set X to a set Y, and use the symbol Bij(X) to represent the set of all the bijective maps on X.Let ℤ be the rational integer ring.We denote by ℕ + the set {1, 2, …} .For a positive integer m ≥ 2 , we set ℤ m ∶= {0, 1, … , m − 1} (the residue class ring modulo m).For a prime p, p ∶= {0, 1, … , p − 1} denotes the finite field with p elements.We define the map int ∶ {0, , where int is the bijective map from {0, 1} 256 to ℤ 256 .Set [k] ∶= {1, … , k} for each k ∈ ℕ + .For n ∈ ℕ + , {0, 1} n denotes the set of all the n-bit strings when n ≥ 1 , and {0, 1} n denotes the empty set ∅ when n = 0 .In addition, we define {0, 1} * ∶= ⋃ n≥0 {0, 1} n as the set of all the finite bit strings.We let " ⟂ " denote an abort symbol.
Let us denote by (X, P X ) the probability space, where X is a finite set and P X is the map from X to the real closed interval [0, 1].For each x ∈ X , we have 0 ≤ P X (x) ≤ 1 and P X (X) = 1 .
A subset A ⊆ X is said to be an event, and we denote by Pr[A] ∶= ∑ x∈A P X (x) the probability of the event A. For a public key encryption scheme, let us denote the Alice's public key and the Alice's secret key (resp.Bob's public key and the Bob's secret key) by pk A and sk A (resp.pk B and sk B ), respectively.Let be a security parameter.We use the symbol HomEnc pk B (m) to represent the ciphertext of a palaintext m using Bob's public key pk B .We assume that an Abelian group is parameterized by the security parameter .

Private intersection-sum Protocol
Before the description of the PI-Sum, we need some additional notations.Alice and Bob share the security parameter .The set of user identifiers held by Alice is , and the set of all the pairs of user identifier and an integer associated with each user identifier is B = v j , t j j∈ [J] .In this situation, u i∈[I] ∈ U , v j∈[J] ∈ U , and t j∈[J] ∈ ℕ + hold, where U is the set of user identifiers.The private exponent held by Alice (resp.Bob) is k 1 (resp.k 2 ).In the PI-Sum, the Paillier encryption scheme [24] is used for an additive homomorphic encryption scheme.Bob generates the pair of the public key pk B and the secret key sk B using the key generation algorithm of the Paillier encryption scheme.Bob shares the public key pk B with Alice, and privately holds the secret key sk B .
The PI-Sum uses the random oracle RO ∶ U → from the set of user identifiers U to the Abelian group .We will describe the details of the Abelian group in Sect. 4. The map from the set of user identifiers U to the Abelian group is composed with the cryptgraphic hash function SHA-256 and the Montgomery curve Curve25519 [1].By [1, Theorem 2.1], we can regard each element of p as the x-coordinate of the corresponding point on Curve25519.For each x ∈ {0, 1} 256 , we can treat int(x) ∈ p as the x-coordinate of a point on Curve25519.Therefore, we can represent each 256 bit string as the point on Curve25519.We compute the hash value of each user identifier using SHA-256, and represent each 256 bit string as the point on Curve25519 via the map int.From the above discussion, we can compose the map from the user identifier space U to the Abelian group .In [13], it is assumed that the map from the user identifier space U to the Abelian group is the random oracle for the security of the PI-Sum in honest-but-curious model [13].For this reason, we also assume that the map from the user identifier space U to the Abelian group is the random oracle RO ∶ U → .
We describe the PI-Sum [13] in Algorithm 1.
We describe Precomputation Algorithm in Algorithm 2. Precomputation Algorithm encrypts all the elements in A and B, respectively.Precomputation Algorithm outputs {RO(u We describe Intersection Set Algorithm in Algorithm 3. Intersection Set Algorithm computes A ∩ B without reveal- ing the private sets A and B to each other.Intersection Set Algorithm outputs J from Alice's input {RO(u . The set J defined by the fol- lowing equation: By doing so, Alice obtains J . .
We describe Intersection Sum Algorithm in Algorithm 4. Intersection Sum Algorithm computes the sum of the rational integers associated with the elements of A ∩ B without revealing the private sets A and B to each other.
The next assumption (Assumption 1) and the addictive homomorphic property of the Paillier encryption scheme is needed in steps 3-8 of Algorithm 4.More precisely, Assumption 1 guarantees that the sum (not modular addition) of the rational integers associated with the elements of A ∩ B is not exceed the modulus N.
We assume that t j∈[J] ∈ M for each j ∈ [J] , and we also assume the following inequality condition: Remark that by Assumption 1, we always have Sum < N in step 6 of Algorithm 4. By doing so, Bob obtains the intersection sum ∑ t 3 (j)∈J t 3 (j) .Bob outputs the intersection sum ∑ t 3 (j)∈J t 3 (j) in step 4 of the PI-Sum.Thus, by the PI-Sum (Algorithm 1), Alice obtains J (the set of all indices of the elements v 3 (j) ∈ A ∩ B ), and Bob obtains the intersection sum ∑ 3 (j)∈J t 3 (j) , where

Bloom filter
A Bloom filter is the probabilistic data structure using the k hash functions ≠ ′ , then we call the k hash functions independent.We use the k independent hash functions H ∈[k] ∶ {0, 1} * → ℤ l for a Bloom filter.We use the k appropriate cryptographic hash functions for a Bloom filter.For an element x ∈ X , we can check whether x ∈ Y or not using a Bloom filter.A Bloom filter is constructed using Algorithm 5 and Algorithm 6. Algorithm 5 stores a set Y in a l boolean array BF[l] , and Algorithm 6 checks whether x ∈ Y or not.We use [22, Algorithm 5] (resp.[22,Algorithm 6]) for Algorithm 5 (resp.Algorithm 6).The l boolean array BF(Y) denotes the boolean array BF[l] storing a set Y using Algorithm 5.
A Bloom filter may cause a false positive.If ♯Y = w then the probability of a false positive is given by the following equation: The probability of a false positive has a negligible probability for l ≥ 128w [4, Section 2.2].It is well-known that for given l and w, the probability is minimum when k = l w log e 2 [4, Section 2.1].We refer the reader to [2, 4] for details. (1) .

Proposed protocol 1
In this section, we propose the proposed protocol 1 that applying a Bloom filter in order to improve the efficiency of the PI-Sum (Algorithm 1).Inspired by the technique using a Bloom filter proposed by Miyaji, Nakasho, and Nishida in [22], we shall improve the efficiency of Intersection Set Algorithm (Algorithm 3) by using a Bloom filter.

Description of proposed protocol 1
The proposed protocol 1 is described as Algorithm 7.
The PI-Sum is constructed by Algorithm 2, Algorithm 3, and Algorithm 4, whereas the proposed protocol 1 is constructed by Algorithm 2, Algorithm 8, and Algorithm 4. Thus, the only difference between the PI-Sum (Algorithm 1) and the proposed protocol 1 (Algorithm 7) is the phase of the computation of private set intersection (Algorithm 3 and Algorithm 8).Algorithm 8 (the proposed algorithm) is used for the phase of the computation of private set intersection in the proposed protocol 1, and is based on a Bloom filter.In the proposed protocol 1, Alice obtains J (the set of all indices of the elemens v 3 (j) ∈ A ∩ B ), and Bob obtains the intersection sum ∑

Main idea of proposed protocol 1
In this section, we explain the details and the main idea of the proposed protocol 1.In the proposed protocol 1, Alice and Bob perform Precomputation Algorithm (Algorithm 2) in step 1 of the proposed protocol 1 in exactly the same manner as in the PI-Sum, and Alice obtains ))} j∈[J] by this procedure.Alice and Bob also perform Intersection Sum Algorithm (Algorithm 4) in step 3 of the proposed protocol 1 in exactly the same manner as in the PI-Sum, and Bob obtains the intersection sum ∑ t 3 (j)∈J t 3 (j) by this procedure.On the other hand, Alice obtains J in step 2 of the proposed protocol 1 by performing Algorithm 8 (the proposed algorithm), whereas Intersection Set Algorithm (Algorithm 3) are used in the PI-Sum.The proposed algorithm is described as Algorithm 8. We refer the reader to Sect.3.1 for the definition of ∈ Inj( , {0, 1} * ) in Algorithm 8.
As we see above, the only difference between the PI-Sum and the proposed protocol 1 is the phase of the computation of private set intersection (Algorithm 3 and Algorithm 8).The proposed algorithm (Algorithm 8) outputs J from Alice's input {RO(u using a Bloom filter.Since Alice com- putes J by checking whether 1 = 2 or not for each , Alice exactly obtains J in Intersection Set Algorithm (Algorithm 3).However, the computational cost of Algorithm 3 is relatively large because of I × J times computation of checking whether 1 = 2 for each . Inspired by the technique using a Bloom filter proposed by Miyaji, Nakasho, and Nishida in [22], we use a Bloom filter in the proposed algorithm (Algorithm 8) in order to improve the efficiency of Intersection Set Algorithm (Algorithm 3).More precisely, Algorithm 8 requires a computation of Const Algorithm (Algorithm 5) and J times computation of ElementCheck Algorithm (Algorithm 6).Since Algorithm 5 and Algorithm 6 essentially need multiple computation of hashing which is relatively small, the computational cost of the proposed algorithm (Algorithm 8) is smaller than that of Algorithm 3.This is the main observation which allows us to improve the efficiency of Intersection Set Algorithm (Algorithm 3).
On the other hand, since a Bloom filter may cause a false positive, might be included in J in Algorithm 8. We will discuss this point in Sect.3.2 (Lemma 1).

Proposition 1 Step 1 of Algorithm 7 (the proposed protocol 1) corresponds exactly to step 1 of Algorithm 1 (the PI-Sum). Steps 3-4 of Algorithm 7 (the proposed protocol 1) also corresponds exactly to steps 3-4 of Algorithm 1 (the PI-Sum).
On the other hand, step 2 of Algorithm 7 (the proposed protocol 1) only deffer from step 2 of Algorithm 1 (the PI-Sum).  2)the following inequality holds: By setting l = 128I and k = 128log e 2 , we have Therefore, the probability Pr[B] = {1 − (1 − 1∕l) Ik } k is negligible.Thus, by Inequality (3), the probability Pr[A] is also negligible.This concludes the proof of Lemma 1.

Security analysis of proposed protocol 1
In this section, we briefly discuss the security of the proposed protocol 1.Our analysis is similar to that of the (2) . The computational cost of one multiplication on p

S
The computational cost of one squaring on p ECDBL The computational cost of one point doubling on Curve25519 ECADD The computational cost of one point addition on Curve25519 Enc The computational cost of one encryption Dec The computational cost of one decryption Exp The computational cost of one exponentiation on The computational cost of one multiplication between ciphertexts for each x ∈ {0, 1} * .We can construct Enc 128,K using 128bit AES [8], and we can construct k independent hash functions by changing the key K ∈ {0, 1} 128 .

Correctness of proposed protocol 1
In this section, we shall prove the correctness of the proposed protocol 1 in Theorem ))in Algorithm 5, and obtains1 in step 4 of Algorithm 8. Namely, the event B is that the Bloom filter determines the numberRO(v . Then, we have the following inequality: In other words, the probability Pr[A] is negligible for suffi- ciently largel.
. PI-Sum [13].The security of the PI-Sum was proven by in these algorithms, it is infeasible for Alice to obtain the Bob's secret v 3 (j) ∈ B, k 2 .addition, the index i ∈ of v j , t j ∈ B .Thus, it is infeasible for Alice to obtain any element in A ∩ B by comparing the index 3 (J) ∈ J and the index i ∈ [I] .The latter part follows from the former part.◻ Remark 2 Ion et al. discuss the security of PI-Sum [13] in the honest-but-curious model.More precisely, they discuss that Alice cannot obtain any information about Bob's secret in [13,Theorem 1] and Bob cannot obtain any information about Alice's secret in [13,Theorem 2].
On the other hand, Bob does not input its own secret and does not obtain the output of Algorithm 8.In addition, Bob does not carry out any computation in Algorithm 8. Therefore, we only discuss the security of the phase of the computation of private set intersection (Algorithm 8) for the security of the proposed protocol 1 in Theorem 2.

Efficiency estimation of proposed protocol 1
In this section, we estimate the computational costs of the PI-Sum (Algorithm 1) and the proposed protocol 1 (Algorithm 7).In addition, we compare the computational costs of the proposed protocol 1 with that of the PI-Sum.We use Curve25519 as Abelian group .Since p = 2 255 − 19 and log 2 p = 255 , we assume that = 128 and ⌈log 2 N⌉ = 3072 .As mentioned in Sect.2.1, we can regard each x ∈ p as the x-coordinate of a point on Curve25519 [1, Theorem 2.1].Since a scalar multiplication of Curve25519 is not necessary to compute the y-coordinate of a point on Curve25519, the computational cost of the random oracle RO is negligibly small compared to other steps in the PI-Sum and the proposed protocol 1.Therefore, we can ignore the computational cost of the random oracle RO.By a similar argument, we can also ignore the computational costs of the mappings 1 , 2 , 3 , and .We use the nota- tion in Table 1 to estimate the computational costs of the PI-Sum and the proposed protocol 1.
Here, we estimate the computational costs of the PI-Sum and the proposed protocol 1 by counting the number of (p) , , , , , , , and (N 2 ) , respectively.We denote the computational cost of Precomptation Algorithm (Algorithm 2) (resp.Intersection Sum Algorithm (Algorithm 4)) by Cost Precomp (resp.Cost Inter-Sum ).We define We first estimate the computational cost Cost Common .Table 2 shows the number of computations in Precomptation Algorithm and Intersection Sum Algorithm.
By a similar argument as above, the computational cost Cost Inter-Sum satisfies the following equation: By Eqs.(6 and 7), the computational cost Cost Common satis- fies the following equation: Finally, we estimate the computational costs of the PI-Sum and the proposed protocol 1.Let Cost PI-Sum (resp.Cost Proposed1 ) be the computational cost of Algorithm 1 (resp.Algorithm 7).In Intersection Set Algorithm, we compute J (the set of all indices of the elements v 3 (j) ∈ A ∩ B ) by checking whether 1 = 2 or not for each . Hence, the computational cost Cost PI-Sum satisfies In the proposed algorithm, we input ({RO(u  2 ( Const Algorithm requires I iterations in steps 4-11 of Algorithm 5. Thus, the computational cost of the whole processes in Const Algorithm is I .We input (RO(v 3 (j) ) k 1 k 2 ) and BF( ({RO(u )) in ElemenetCheck Algorithm.It is easy to see that the computational cost of J times performing of Algorithm 6 is J .Hence, the computational cost Cost Proposed1 satisfies (7)

Countermeasures against repeatedly executing the PI-Sum
As explained in [13, Section 3], it may be possible that "repeatedly executing the PI-Sum in sequence will leak information due to correlated inputs in different sessions, and one strategy for resolving this issue would be to compose differential privacy techniques [11] with the cryptographic protocol, by adding appropriately sampled noise to the inputs".In this section, we propose two protocols (Algorithm 10 and Algorithm 11) having the resistance to the above security problem.These proposed protocols are modifications of the "Reverse" Private Intersection-Sum protocol (RePI-Sum for short) in [13, Figure 4].

Description of proposed protocol 2 and proposed protocol 3
In this section, we propose the proposed protocol 2 (Algorithm 10) and the proposed protocol 3 (Algorithm 11).These protocols allow Bob to obtain the intersection sum.The proposed protocol 2 and the proposed protocol 3 are based on the proposed estimation algorithm for the intersection size (Algorithm 9) and the proposed protocol 1. Algorithm 9 is based on Bloom filter Bootstrap [15, Algorithm 2] for preventing the security problem in the RePI-Sum ( [13, Figure 4]).The proposed estimation algorithm for the intersection size is described as Algorithm 9. We refer the reader to Sect.3.1 for the definition of ∈ Inj( , {0, 1} * ) in Algorithm 9. (10) In Algorithm 9, Alice has the private set X and Bob has the private set Y. Algorithm 9 allows Alice and Bob to obtain the estimation size of the intersection x ≈ ♯(X ∩ Y) .Kikuchi and Sakuma in [15,Section 5.1] show that the following inequality holds in Bloom filter Bootstrap [15,Algorithm 2].So, we assume that the above inequality holds in Algorithm 9.In Algorithm 9, we use [10,Protocol 2] for Secure Scalar Product Protocol (SSP for short).In Algorithm 9, the input S is the number of executions of SSP.In steps 1-6 of Algorithm 9, Alice obtains BF( (X )) and Bob obtains BF( (Y)) in the d-th �⌈x⌉ − ♯(X ∩ Y)� ≤ 1 execution of SSP, where 1 ≤ d ≤ S .In steps 4-5 of Algo- rithm 9, y d satisfies the following equation: For ∈ ℤ l , let us denote by the probability of the event BF( (X ))[ ] = BF( (Y))[ ] = 1 .In step 7 of Algorithm 9, θ is the Bayesian estimation of the probability .We call the phase of computing y d using SSP (steps 1-6 of Algo- rithm 9) the secure scalar product phase.We also call the phase of computing the output using θ (steps 7-8 of Algorithm 9) the intersection size phase.We describe the proposed protocol 2 (resp.the proposed protocol 3).The detailed description of the algorithms are given in Algorithm 10 and Algorithm 11.Next, we describe the overview of Algorithm 11.As similar to step 1 of Algorithm 7, Algorithm 11 encrypts A = {u i } i∈[I] and B = {(v j , t j )} j∈[J] , and out- puts {RO(u in just after step 1 of Algorithm 11. Bob also holds {RO(u

Efficiency estimation of proposed protocol 2 and proposed protocol 3
In this section, we estimate the computational costs of the proposed protocol 2 (Algorithm 10) and the proposed protocol 3 (Algorithm 11).Let us denote by (p � ) the computational cost of one multiplication on p ′ .Here, p ′ is a prime satisfying p ′ > l and p � ≈ l , and is used for step 4 of Algorithm 9 ( [10, Protocol 2]).By [15, Section 4.4], we assume that S = 10 and k = 1 .We define Remark that tmp is appeared in the equation of step 8 of Algorithm 9. We denote the computational costs of the proposed estimation algorithm for the intersection size (Algorithm 9) by Cost Estimation .Similarly, we denote the secure scalar product phase (steps 1-6 of Algorithm 9), and the intersection size phase (steps 7-8 of Algorithm 9) by Cost SSP and Cost Size , respectively.As in Section 4, we use the symbol Cost Proposed2 (resp.Cost Proposed3 ) to represent the computational cost of the proposed protocol 2 (resp.the proposed protocol 3).Since the only difference between the proposed protocol 2 and the proposed protocol 3 is their timing of performing Algorithm 9, we have Therefore, we only estimate Cost Proposed2 by counting the number of (p � ) .We first estimate the computational cost Cost Estimation .The computational cost of step

Results and discussion
In Sect.3, we propose Algorithm 7 which is an efficiency improvement technique for the PI-Sum (Algorithm 1).By Table 2 and Eq. ( 9), the computational complexity of Algorithm 1 is O((I + J) 3 ) .Similarly, by Table 2 and Eq. ( 10), the computational complexity of Algorithm 7 is also O((I + J) 3 ) .Thus, the computational complexity of Algorithm 1 is same as the computational complexity of Algorithm 7.However, we claim that if I and J are relatively large for a fixed security parameter then the proposed protocol 1 (Algorithm 7) is more efficient than the PI-Sum ( [13, Figure 2] or Algorithm 1).Next we explain why the claim holds.
Figure 1 shows the computational costs of Cost PI-Sum and Cost Proposed1 .For the sake of simplicity we assume that I = J = 2 x and the security parameter = 128 .In Fig. 1, the graph of y = f (x) (resp.y = g(x) ) is described, where Cost PI-Sum = 2 y (resp.Cost Proposed1 = 2 y ).By [20, Table 2.5] and by [1, Section 1], the multiplication cost (p) is O((⌈log 2 p⌉) 2 ) .Since p = 2 255 − 19 , by omitting the constant cost of the multiplication cost (p) , we may assume that From [20, Table 2.5] and by [24,Section 4], the multiplication cost (N 2 ) is O((⌈2 log 2 N⌉) 2 ) .It is known that if = 128 then ⌈log 2 N⌉ ≈ 3072 (See [23]).By omitting the constant cost of the multiplication cost (N 2 ) , we may assume that In this situation, we have Substituting Eqs.(16 and 17) into Eq.( 9) yields Similarly, substituting Eqs.(16 and 17) into Eq.( 10) yields By Eqs.(18 and 19), if = 16 then the computational cost of the proposed protocol 1 is about 1% smaller than that of the PI-Sum, namely, If x = 22 then the computational cost of the proposed protocol 1 is about 50% smaller than that of the PI-Sum, namely, (   Thus, the proposed protocol 1 (Algorithm 7) is faster than the PI-Sum (Algorithm 1).
In Sect.5, we propose other efficiency improvement techniques for the PI-Sum.As explained in Sect.5, repeatedly executing the PI-Sum in sequence will leak information.The proposed protocol 2 (Algorithm 10) and the proposed protocol 3 (Algorithm 11) are modifications of the RePI-Sum [13,

Conclusion
In this paper, we proposed the efficiency improvement techniques for the Ion et al. private intersection-sum protocol (PI-Sum).The proposed protocol 1 is more efficient than the PI-Sum.The computational cost of the proposed protocol 1 is about 1% smaller than that of the PI-Sum if the base 2 logarithm of the number of the private set is 16, and the computational cost of the proposed protocol 1 is about 50% smaller than that of the PI-Sum if the base 2 logarithm of the number of the private set is 22.To our best knowledge, there exists only two private intersectionsum protocols.Thus, the proposed protocol 1 is the fastest private intersection-sum protocol.We also proposed the proposed protocol 2 and the proposed protocol 3 for preventing the security problem described in Section 5.By adding an aborting functionality in the proposed protocol 2 and the proposed protocol 3, the proposed protocol 2 and the proposed protocol 3 can be more efficient than the "Reverse" Private Intersection-Sum protocol proposed by Ion et al.Implementation of our proposed protocols is left for future work.
adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if changes were made.The images or other third party material in this article are included in the article's Creative Commons licence, unless indicated otherwise in a credit line to the material.If material is not included in the article's Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.To view a copy of this licence, visit http:// creat iveco mmons.org/ licen ses/ by/4.0/.

Fig. 1
Fig. 1 Comparison result of the computational costs of Cost PI-Sum and Cost Proposed1 step 10 of Algorithm 2. Alice and Bob perform Algorithm 9 in step 2 of Algorithm 11.Alice inputs {RO(v3 (j) ) k 1 k 2 } j∈[J] and Bob inputs {RO(u 2 ( 1 (i)) ) k 1 k 2 } i∈[I] intoAlgorithm 9. Thus Alice and Bob obtain the estimation size of the intersection As similar to steps 2-5 of Algorithm 10, Algorithm 11 also checks whether x ≤ T or not in steps 3-6 of Algorithm 11.If x ≤ T , then Alice (or Bob) outputs " ⟂ " and aborts Algo- rithm 11.As similar to steps 1-4 of Algorithm 7, Algorithm 11 outputs the intersection sum in steps 7-9 of Algorithm 11.From the above discussion, Algorithm 10 (resp.Algorithm 11) performs Algorithm 9 in just before (resp.after) encrypting the input sets A and B. In Algorithm 10 and Algorithm 11, Bob can obtain the estimation size of the intersection x ≈ ♯(A ∩ B) .Bob can compute the intersection sum if and only if T ≤ ♯(A ∩ B) holds.If Bob may know the element of the Alice's private set u i∈[I] ∈ A from the intersection sum, Bob can prevent leakage of the element of the Alice's private set u i∈[I] ∈ A by aborting step 4 of Algorithm 10 or step 5 of Algorithm 11 without computing the output.Bob can obtain the intersection sum in Algorithm 10 and Algorithm 11.

Figure 4 ]
, and can prevent the above security problem.Moreover, by adding an aborting functionality in step 4 of Algorithm 10 and step 5 of Algorithm 11, Algorithm 10 and Algorithm 11 are faster than the RePI-Sum [13, Figure 4].

Table 1
Notation for the estimation M (p)

Table 2
The number of computations in Algorithm 2 and Algorithm 4 H right (x) ∈ {0, 1} 128 ) i s t h l e f t ( re s p. t h e right) most significant 128-bits of H(x).Since H lef t (x) ∈ {0, 1} 128 and H right (x) ∈ {0, 1} 128 , we have Enc 128,K (H lef t (x)), Enc 128,K (H right (x)) ∈ {0, 1} 128 .Thus, we can construct a hash function from {0, 1} * to ℤ 256 by taking [13,e correctness of the PI-Sum was proven by Ion et al. in[13, Section 3].Since the only difference between the Algorithm 1 and Algorithm 7 is the phase of the computation of private set intersection, it suffices for the proof of the correctness of Algorithm 7 to show the following lemma (Lemma 1).
Lemma 1 Let A denote the event that in an execu- tion of Algorithm 7, it is determined in step 4 of Algorithm 8 that the number 3 [13, et al. in [13, Section 3.1].More precisely, the authors prove the security of the PI-Sum in the honest-but-curious model in[13, Theorem 1]and[13, Theorem 2].Since the only dif-