Efficient Aggregate Queries on Location Data with Confidentiality

Abstract

Location data have great value for facility location selection. Due to the privacy issues of both location data and user identities, a location service provider can not hand over the private location data to a business or a third party for analysis or reveal the location data for jointly running data analysis with a business. In this paper, we propose a newly constructed PSI filter that can help the two parties privately find the data corresponding to the items in the intersection without any computations and, subsequently, we give the PSI filter generation protocol. We utilize it to construct three types of aggregate protocols for facility location selection with confidentiality. Then we propose a ciphertext matrix compressing method, making one block of cipher contain lots of plaintext data while keeping the homomorphic property valid. This method can efficiently further reduce the computation/communication cost of the query process—the improved query protocol utilizing the ciphertext matrix compressing method is given followed. We show the correctness and privacy of the proposed query protocols. The theoretical analysis of computation/communication overhead shows that our proposed query protocols are efficient both in computation and communication and the experimental results of the efficiency tests show the practicality of the protocols.

1. Introduction

With the widespread popularity of electronic devices with GPS functions and thanks to advances in information and communication technologies, location-based services (LBS) have developed significantly, and location service providers (LSP), such as Google Maps and FourSquare, already own a very large amount of user location data, which are of great commercial value in facility location selection. LSPs seek to find ways to provide location data aggregate analysis services to other businesses. Businesses would also like to pay for this kind of service for location selection because an appropriate location can bring much more economic interest than an ordinary location. Specifically, for example, a bank plans to open a branch, and it has several candidate addresses. “Which is the best location” is a puzzle for the bank because it does not have the location data of its users, so the bank seeks the help of the LSPs. Even in some public sectors (communal facilities) where economic interests are not the core issue, for businesses that define “value” as being used by more people or making something convenient for more people, a proper location makes the public facilities more valuable. The desire of the LSP and the business to cooperation raises a problem that the LSP can not simply send location data to the business or a third party for analyzing or reveal the location data for jointly running a data analysis query with the business due to privacy issues in both terms of law and ethics. From the above points of view, how to run a two-party privacy-preserving query between an LSP and a business is a meaningful topic.

The selection of a facility location among alternative locations has been widely studied, which is regarded as a multi-criteria decision-making problem, including both quantitative and qualitative criteria [1]. The location selection query is to choose a location with maximum influence for a new facility [2]. We mainly focus on three types of objectives [3] for location selection—(1) maximizing the number of users attracted (Maximum is not appropriate for some special businesses such as express. Instead, they may pursue sharing workload equally for each facility. For this objective, the RNNC query is still applicable.); (2) minimizing the average distance from all users to their nearest facilities; (3) minimizing the maximum distance from all users to their nearest facilities. The above selection indicators correspond to three types of aggregate queries, respectively, as follows:

(1)

Reverse Nearest Neighbor Cardinality (RNNC) query. The RNN query is a very common query for location selection. In our two-party privacy-preserving query scenario, for a (public) set of existing facilities and given query locations, the RNN query computes all the users that are closer to each given query location than to any other facilities. Considering the first objective above, our RNNC query only needs to return the set of the cardinalities of the RNN.

(2)

Average Distance (AVGD) query. The average distance represents the mean value of the distances between all users and their nearest facilities. The average distance is valuable information for the client to minimize is to maximize user benefit. The AVGD query result measures the impact of a candidate location of the new facility on all users, which can help a business such as a supermarket to decide where to put a new branch store in order to maximize the benefit to its customers. In short, the minimized average distance corresponds to the most valuable location.

(3)

Maximum Distance (MAXD) query. The maximum distance represents the maximum value of the distances between all users and their nearest facilities. It takes the worst case as a selection indicator, i.e., after running several MAXD queries returning the maximum distances corresponding to different candidate locations, the business can compare those and choose the location which has the smallest one to maximize the benefits to the most “inconvenient” user.

In practice, for multiple alternative locations, a business can run one of these three types of queries according to the chosen criterion for each location, then decide which location is more beneficial to it.

In this paper, we use “server ($\mathcal{S}$)” to replace the LSP that provides services of aggregate queries and use “client ($\mathcal{C}$)” to replace the business that needs location data analyses. Consistently, we use $U_s/U_c$ to represent $\mathcal{S}/\mathcal{C}$’s user list. We continue to focus on the practical settings described in [3]: (1) We use $I=U_s\cap U_c$, the intersection of the user lists of $\mathcal{S}$ and $\mathcal{C}$, as a substitute for $\mathcal{C}$’s user list $U_c$ because the scale of $U_s$ is so big that the number of items (user identities) in $U_c$ that are out of the intersection is relatively small enough to be ignored; (2) These two user lists $U_s$ and $U_c$ are both private, each of which should not be revealed to the other party; (3) The location data of users in the hands of $\mathcal{S}$ are private from $\mathcal{C}$.

Our Contributions. We proposed two-party privacy-preserving aggregate query protocols for three types of queries—RNN Cardinality query, Average Distance query and Maximum Distance query for facility location selection. Compared with the state-of-the-art scheme [3], our protocols are one step closer to practical application in terms of efficiency. Specifically, our main contributions are as follows:

• We propose a new construction that we call a PSI filter, which can be used by two parties to filter irrelevant data corresponding to items out of the intersection without any computations and without revealing any information of items in their private sets to each other. Specifically, we extract the PSI process of [4] and modify it to a PSI filter generation protocol. The generated filter $\mathcal{F}$ consists of two parts, in both of which the items are indistinguishable (looks random). These two parts are held by these two parties ($\mathcal{S}$ and $\mathcal{C}$), respectively, and they can help to find the valid data in our aggregate query protocols.
• We propose privacy-preserving aggregate query protocols for three types of queries—RNN Cardinality query, Average Distance query and Maximum Distance query by using our PSI filter to find the valid data (corresponding to the items in the intersection) and using a Paillier cryptosystem to achieve the processing on the ciphertext. Compared with the state-of-the-art schemes [3], the use of a PSI filter rather than a superset (for hiding user identities and serving as an index) of user identity space can bring a new advantage: no need to increase the communication costs for hiding the user identity lists from each other. Further, it can efficiently reduce the times of encryption from $\tilde{n}$ to $n_s$ by removing many invalid computations where $\tilde{n}(\gg n_s)$ is the size of the superset and $n_s$ is the size of LSP’s user set.
• We propose a ciphertext matrix compressing (CMC) method that can further reduce the communication cost (and the computation cost incidentally) of the RNN Cardinality query protocol then we give the optimized version of the RNNC query protocol utilizing CMC. Although our original three types of query processing are similar to some extent, the communication cost of the RNN cardinality query protocol is $O(n_s·k)$, $k\times$ that of the other two protocols, where k is the number of facilities. Our ciphertext matrix compressing method can reduce the communication cost to $O(n_s·\lceil k/\eta \rceil )$, where $\eta$ is relevant to the security parameter $\lambda$ and a threshold value $\alpha$ (Section 6). What is striking is that our compressing method has a broader scope of application; more specifically, it has great potential in small-value plaintext scenarios for compressing the scale of ciphertext while maintaining the homomorphic property.
• We give the security analysis and performance evaluation of the aggregate query protocols. First, we prove the security of a PSI filter generation protocol, based on which we illustrate that the aggregate query protocols are privacy-preserving for the location data owned by the LSP and user lists of both the LSP and the business. Finally, we give the theoretical analysis and experimental results of performance.

The remainder of this paper is organized as follows. After reviewing the related research contents and giving the preliminaries in Section 2, we introduce our system model and problem definitions in Section 3. In Section 4, we give the definition of a PSI filter and the generation protocol that we utilized to construct the three types of query protocols in Section 5. We present a ciphertext matrix compressing method in Section 6 to further improve the efficiency of the RNNC query protocol. In Section 7, we give the proofs of correctness and privacy. In Section 8, we give the theoretical analysis and experimental results for performance evaluation. Finally, the concluding remarks are given in Section 9.

2. Related Work and Preliminaries

2.1. Related Work

2.1.1. Aggregate Query on Location Data

The nearest neighbor (NN) query has received vast attention in the spatial database research community since its introduction in [5]. We say point A is the nearest neighbor of B when A is closer to B than any other points under consideration, and naturally, B is one of the reverse nearest neighbors of A. The RNN query was firstly considered in [6]. In monochromatic RNN [7,8], all points are regarded as in the same class; in contrast, the dichromatic RNN [2,6,9,10] considers two different classes of points—objects and sites. The average distance (for ${\mathrm{L}}_1$ distance) query was first considered in min-dist optimal location query [11]. Then, [12] gave a scheme for the ${\mathrm{L}}_2$ distance version. Recently, for the TIPS problem (Trajectory-aware Inconvenience-minimizing Placement of Services), [13] showed both the MAX-TIPS and AVG-TIPS are NP-hard. Then, a novel query called the reverse nearest neighborhood (RNH) query was proposed in [14]. Unlike an RNN query, an RNH query emphasizes a group of users instead of an individual user.

Most of the schemes of aggregate queries on location data assume that data is public or allowed to be sent to another party. Today, when people attach great importance to data privacy, these schemes do not meet our requirements.

2.1.2. Privacy-Preserving Aggregate Query

The privacy-preserving database query was first defined in [15]; Ref. [16] then gave a solution. Ref. [17] showed how to execute SQL aggregations over encrypted data. The authors developed an enhanced encrypted data storage model and introduced formal query implementation techniques to translate original aggregation queries to a form that can be directly executed over the encrypted data. Ref. [18] proposed a privacy-preserving range query protocol. Ref. [19] proposed a privacy-aware query processing framework Casper for privacy-preserving NN query. Then, ref. [20] gave efficient protocols for privacy-preserving k-NN searches by using secure multi-party computation technologies. Ref. [21] proposed a simple privacy-preserving protocol PDAS for computing and verifying queries in outsourced databases against malicious adversaries. For the same problem in [20], ref. [22] gave a solution using a Paillier cryptosystem. Recently, ref. [3] proposed two types of solutions for privacy-preserving aggregate query protocols. The main difference between these two types is who (the server or the client) does most of the encryptions and decryptions. No matter who does, the protocols need a superset of size $\tilde{n}$ in order to conceal the identities of users and to serve as an index—the positions of any users are fixed where both the two parties can operate directly on the corresponding positions.

How to cancel the use of a superset and filtrate data without an “index” for aggregate queries on location data while the two parties both have their own private user sets is not solved yet. In general, we use homomorphic encryption and the idea of PSI to design our protocols. Compared with the traditional PSI protocols, our newly constructed PSI filter generation protocol does not find the intersection directly due to privacy issues. What the two parties get are the sets containing computationally indistinguishable labels that were generated in the protocol. In comparison with [3], we cancel the use of a superset through the use of our new primitive PSI filter and further improve the efficiency by compressing multiple data into one block of ciphertext.

2.2. Preliminaries

2.2.1. Private Set Intersection

A private set intersection (PSI) protocol enables two parties, the Sender and the Receiver, holding private sets X and Y, respectively, to jointly compute the intersection $X\cap Y$ without revealing any additional information about their respective sets (the conditions may be weakened or changed in different circumstances). In a one-way version of PSI, only the Receiver can learn the intersection $X\cap Y$, while the Sender learns nothing. In a concrete setting called labeled PSI [23] for applications, there is a label $l_i$ for each item $x_i\in X$, and the protocol enables the Receiver to learn the labels corresponding to the items in the intersection, i.e., the Receiver should learn the set $\{(x_i,l_i):x_i\in Y\}$. A labeled PSI can be seen as a variant of one-way PSI.

We construct our protocols using a PSI filter (Section 4), which is generated by a modified one-way PSI. The generation process is particularly similar to a labeled PSI protocol, and the difference is that the labels do not exist before our PSI processing. In other words, the labels corresponding to the items will be generated in the intermediate process. Moreover, the Receiver does not know the specific correspondence of any pair $(x_i,l_i)$. Note that for reducing the communication/computation cost, the (generated) corresponding labels are important for filtrating data in queries. For consistency, we will use the titles Server ($\mathcal{S}$)/Client ($\mathcal{C}$) instead of Sender/Receiver, and accordingly, use $U_s/U_c$ instead of $X/Y$, afterward.

2.2.2. Decisional Diffie–Hellman Assumption

The decisional Diffie–Hellman (DDH) assumption is a computational hardness assumption in cyclic groups. It indicates that no efficient algorithm can distinguish between these two distributions $(g,g^a,g^b,g^{ab})$ and $(g,g^a,g^b,g^c)$, which enables one to construct efficient cryptographic systems with strong security properties.

Formally, let $\mathbb{G}\left(\lambda \right)$ be a cyclic group of order q with secure parameter $\lambda$. For a probabilistic adversary (algorithm) $\mathcal{A}$, we define the advantage of $\mathcal{A}$ as

$$\begin{array}{cc}\hfill \mathrm{Adv}[\mathcal{A},\mathbb{G}] =& |\mathrm{Pr}[\mathcal{A}(g,g^a,g^b,g^{ab})=1]-\mathrm{Pr}[\mathcal{A}(g,g^a,g^b,g^c)=1]|\hfill \end{array}$$

(1)

where the probability is over a random generator g of $\mathbb{G}$, and random $a,b,c\in \mathbb{G}$. We say that the decisional Diffie–Hellman assumption holds in group $\mathbb{G}$ if for any probabilistic adversary $\mathcal{A}$, the advantage $\mathrm{Adv}[\mathcal{A},\mathbb{G}]$ is negligible.

2.2.3. Homomorphic Encryption

Homomorphic encryption is a cryptographic primitive that allows computation on ciphertexts without decryption. The homomorphism can be expressed as $\mathrm{Enc}\left(m_1\right)\hat{\circ }\mathrm{Enc}\left(m_2\right)=\mathrm{Enc}(m_1\circ m_2)$, more strictly, $\mathrm{Dec}\left(\mathrm{Enc}\left(m_1\right)\hat{\circ }\mathrm{Enc}\left(m_2\right)\right)=m_1\circ m_2$. Note that in nondeterministic encryption, the previous homomorphic equation is not directly equivalent due to the existence of random numbers. It represents that $\mathrm{Enc}\left(m_1\right)\hat{\circ }\mathrm{Enc}\left(m_2\right)$ equals one of the ciphertexts of the message $m_1\circ m_2$.

We choose a Paillier cryptosystem [24] to achieve the additive homomorphism, i.e., $\mathrm{Enc}\left(m_1\right)·\mathrm{Enc}\left(m_2\right)=\mathrm{Enc}(m_1+m_2)$. After selecting the public key $pk=(n,g)$ and the private key $sk=(\lambda ,\mu )$, for message $m\in \mathcal{M}$, the encryption algorithm computes ciphertext $c=g^m·r^{n}mod{n}^2$ where r is randomly selected from ${\mathbb{Z}}_n^{*}$. The decryption algorithm recovers the message by computing $m=L(c^{\lambda }mod{n}^2)·\mu modn$ where $L\left(x\right)=\frac{x-1}{n}$. The Paillier cryptosystem provides semantic security against chosen-plaintext attacks (IND-CPA) under the decisional composite residuosity assumption (DCRA). In other words, the encryptions of different messages are computationally indistinguishable without knowledge of the private key.

2.2.4. Security Definition

We consider two-party privacy-preserving aggregate query protocols in a semi-honest model, i.e., the adversaries are honest but curious, where the main security issue is to protect the privacy of the two parties. We formally define the security of a two-party protocol by using a simulation paradigm [25,26], which gives us an effective method to prove the security.

Let $f=(f_1,f_2)$ be a probabilistic polynomial-time functionality and let $\pi$ be a two-party protocol for computing f. The view of the ith party ($i\in \{1,2\}$) during the execution of $\pi$ on $(x,y)$ and security parameter n is denoted by ${\mathtt{view}}_i^{\pi }(x,y,n)$ and equals $(w,r^i;m_1^i,\dots ,m_t^i)$, where $w\in \{x,y\}$ (depends on the value of i), $r^i$ equals the contents of the ith party’s internal random tape and $m_j^i$ represents the jth message that it received. The output of the ith party during an execution of $\pi$ on $(x,y)$ and security parameter $\lambda$ is denoted by ${\mathtt{output}}_i^{\pi }(x,y,\lambda )$ and can be computed from its own view of the execution. We denote the joint output of both parties by ${\mathtt{output}}^{\pi }(x,y,\lambda )=({\mathtt{output}}_1^{\pi }(x,y,\lambda ),{\mathtt{output}}_2^{\pi }(x,y,\lambda ))$.

Definition 1.

(Security for Semi-honest Adversaries)  Let $f=(f_1,f_2)$ be a functionality. We say that π securely computes f in the presence of static semi-honest adversaries if there exist probabilistic polynomial-time algorithms ${\mathrm{SIM}}_1$ and ${\mathrm{SIM}}_2$ such that

$$\begin{array}{cc}\hfill & \{{\mathrm{SIM}}_1(1^{\lambda },x,f_1(x,y)),f(x,y)){\}}_{x,y,\lambda }\hfill \\ & \stackrel{c}{\equiv }\{{\mathtt{view}}_1^{\pi }(x,y,\lambda ),{\mathtt{output}}^{\pi }(x,y,\lambda )){\}}_{x,y,\lambda },\mathit{and}\hfill \\ \hfill & \{{\mathrm{SIM}}_2(1^{\lambda },x,f_2(x,y)),f(x,y)){\}}_{x,y,\lambda }\hfill \\ & \stackrel{c}{\equiv }\{{\mathtt{view}}_2^{\pi }(x,y,\lambda ),{\mathtt{output}}^{\pi }(x,y,\lambda )){\}}_{x,y,\lambda },\hfill \end{array}$$

where $x,y\in {\{0,1\}}^{*}$ such that $\left|x\right|=\left|y\right|$, and $n\in \mathbb{N}$.

The simulation paradigm is one of the most important paradigms in the definition and design of cryptographic primitives. In a two-party setting, it can ensure one has not learned anything about the other’s secret by showing that the one could have simulated the entire interaction by itself. In other words, one can gain no further knowledge as the result of interacting with the other beyond what it could have discovered by itself. It gives a formal way to prove the security; the details of the proof are shown in Section 7.

3. Models and Problem Definitions

3.1. System Model

The system model is composed of two parties, as shown in Figure 1: the server $\mathcal{S}$ provides location-based services and the client $\mathcal{C}$ that is interested in some aggregated data (query results) that are helpful for selecting the optimal facility location.

$\mathcal{S}$ has a private user set $U_s=\{v_1,\dots ,v_{n_s}\}$, where $u_i$ is the unique ID of the ith user of $\mathcal{S}$. Further, $\mathcal{S}$ has the knowledge of all the users’ locations $L=\{l_1,\dots ,l_{n_s}\}$, where $l_i$ is the location of $u_i$. ($\mathcal{S}$’s own data privacy—how it prevents getting compromised—is not in our consideration. Some techniques can be found in related fields, such as hardware security and database security. We focus on the privacy-preserving interactive protocols between $\mathcal{S}$ and $\mathcal{C}$.) Actually, $l_i$ can be the expression of a point with respect to any coordinate system, for example, $l_i=(x_i,y_i)$ in Cartesian coordinate system and $l_i=(ln{g}_i,la{t}_i)$ in geographic coordinate system. $\mathcal{C}$ has a private user set $U_c=\{u_1,\dots ,u_{n_c}\}$, where $v_i$ is the unique ID of the ith user of $\mathcal{C}$. In addition, $\mathcal{C}$ has $F=\{f_1,\dots ,f_k\}$, a list of locations of $(k-1)$ existing facilities and one of the candidate locations, which can be public to others.

As described in Figure 1, there are two phases of interactions: the setup phase and the query phase. In the setup phase, $\mathcal{C}$ and $\mathcal{S}$ interact to do some pre-computations where a PSI filter will be generated on the basis of the two user sets $U_c$ and $U_s$, in order to facilitate the query phase. After finishing the setup phase, when $\mathcal{C}$ wants to do a query, it can send a query request with a specific query type to $\mathcal{S}$. After receiving the query request, $\mathcal{S}$ interacts with $\mathcal{C}$ to jointly compute an aggregate query result that will be obtained by $\mathcal{C}$ while protecting the privacy of both $\mathcal{C}$ and $\mathcal{S}$. We discuss the details of privacy requirements and list all involving sensitive information in Section 3.2 There is a good property that a fixed $\mathcal{C}$ collaborating with $\mathcal{S}$ can process an aggregate query many times with just one setup phase, so the computation and communication costs of the setup phase can be amortized over a number of queries.

3.2. Threat Model

Both $\mathcal{C}$ and $\mathcal{S}$ are considered as semi-honest (also called honest-but-curious) adversaries [27], as described in Section 2.2.4 That is, they honestly act according to their prescribed actions in the designed protocols but may try to learn additional information from the encrypted data and all the intermediate messages obtained by themselves, and there is evidently no collusion between $\mathcal{C}$ and $\mathcal{S}$. We say a two-party protocol $\pi$ is secure in the semi-honest model if no party of the two gains information about the other’s private inputs, other than what can be deduced from the result of the protocol.

In our system model, there is some private information that needs to be hidden as follows.

• $U_s$: these user identities should not be revealed to $\mathcal{C}$;
• $U_c$: these user identities should not be revealed to $\mathcal{S}$;
• L: the user location data is private to $\mathcal{C}$;
• Q: the query result is private to $\mathcal{S}$.

Note that the values of $n_s$, $n_c$ and $n_I$ are actually not sensitive information. We do not hide them in our protocol, but just in case, we give a simple way to hide $n_s$ and $n_c$ to some degree. Moreover, the location that was finally selected is not private information, while the query result Q is private to $\mathcal{S}$ because the final location is visible to anyone.

3.3. Problem Definitions

Different sorts of aggregate queries can employ the PSI filter proposed in Section 4 to build privacy-preserving query protocols. In our system model, a privacy-preserving aggregate query protocol is a secure two-party computation protocol for functionality $\mathcal{Q}:((U_c,F),(U_s,L))\to (Q,\perp )$, where $(U_c,F)$ is $\mathcal{C}$’s input and $(U_s,L)$ is $\mathcal{S}$’s input. After executing the protocol, $\mathcal{C}$ receives the query result Q corresponding to a specific query type while $\mathcal{S}$ gains nothing. Note that it is a sketchy representation of the functionality $\mathcal{Q}$ ignoring some inputs such as secure parameters and keys, and the input of functionality $\mathcal{Q}$ has not changed from the previous state-of-the-art scheme. For popularity (usefulness and usage frequency) and ease of comparison with the previous literature, we consider three types of queries, the same as in [3]—RNN Cardinality (RNNC) query, Average Distance (AVGD) query, and Maximum Distance (MAXD) query. The formal definitions of the three types of queries are given as follows:

Definition 2.

(RNNC Query)  Given a set of locations of facilities$F=\{f_1,\dots ,f_k\}$, RNNC query intents to find $\mathrm{RNNC}\left(F\right)=\{q_i=|\left\{u_j\right|f_{i}isNNof{u}_j\}{\left|\right\}}_{i\in \left[k\right]}$ where $|·|$ means the cardinality of a set. In other words, it intents to find the cardinality of RNN for each facility $f_i$.

For the RNNC query, the query result $Q=\mathrm{RNNC}\left(F\right)$ is a k-vector (ordered set) of RNN cardinalities.

Definition 3.

(AVGD Query)  Given a set of locations of facilities $F=\{f_1,\dots ,f_k\}$, AVGD query intends to find

$$\mathrm{AVGD}\left(F\right)=\frac{{\sum }_{i=1}^{n_c}d(u_i,f_j)}{n_c}$$

(2)

where $f_j$ is the NN of $u_i$, and $d(u_i,f_j)$ means the distance between $u_i$ and $f_j$. In other words, it intends to find the average distance of all users and their nearest facilities.

Definition 4.

(MAXD Query)  Given a set of locations of facilities $F=\{f_1,\dots ,f_k\}$, MAXD query intends to find $\mathrm{MAXD}\left(F\right)=max\left(d(u_i,f_j)\right)$, where $f_j$ is the NN of $u_i$. In other words, it intends to find the maximum distance between a user $u_i\in I$ and its nearest facility $f_j\in F$.

Note that we consider Manhattan distance (${\mathrm{L}}_1$ distance) instead of Euclidean distance (${\mathrm{L}}_2$ distance), because ${\mathrm{L}}_1$ distance is more accurate for representing the driving distance in a city road network [28].

3.4. Design Objectives

To meet the anticipated requirements under the aforementioned system model and the threat model, the proposed protocols aim to simultaneously achieve the following objectives:

• Correctness. The client should correctly obtain the desired query result if the two parties execute the protocol honestly.
• Privacy. The private information $U_s$, $U_c$, L and Q should be hidden throughout the whole protocol. Although we use I as a substitute for $U_c$, the client does not gain any knowledge of $U_s$; in other words, the client has no idea if an item in $U_c$ also exactly belongs to $U_s$, and similarly, the server gains nothing about $U_c$.
• Efficiency. Our protocol should be efficient for both $\mathcal{S}$ and $\mathcal{C}$. That is, both the computation cost and the communication cost should be low to support the aggregate queries with large-scale location datasets and user lists.

4. PSI Filter

Definition 5.

(PSI filter) For a two-party query protocol π, and two datasets$D_1$and$D_2$held by$\mathcal{S}$and$\mathcal{C}$, respectively, let$\mathcal{F}=({\mathsf{\Theta }}_1,{\mathsf{\Theta }}_2)$be a tuple of two formally analogous sets that are held by$\mathcal{S}$and$\mathcal{C}$, respectively, where${\mathsf{\Theta }}_1=\{labe{l}_1^{\mathcal{S}},\dots ,labe{l}_{|D_1|}^{\mathcal{S}}\}$, ${\mathsf{\Theta }}_2=\{labe{l}_1^{\mathcal{C}},\dots ,labe{l}_{|D_1\bigcap D_2|}^{\mathcal{C}}\}$. $\mathcal{F}$is said to be aPSI filterif it does not contain any sensitive information and the protocol π can utilize $\mathcal{F}$to filtrate out irrelevant data corresponding to items out of the intersection$D_1\bigcap D_2$with no extra computation.

Our newly constructed PSI filter is a pair of special sets of labels designed to filtrate data, which means helping $\mathcal{C}$ to find and retain the relevant data corresponding to the items (users) in the intersection and discard other irrelevant data without revealing the private identities of users to either $\mathcal{C}$ or $\mathcal{S}$. As described in Section 2.2 the process of generating the PSI filter is, in fact, a modified one-way PSI that is similar to a labeled PSI. Concretely, $\mathcal{C}$ and $\mathcal{S}$ hold private sets $U_c={\left\{u_i\right\}}_{i\in \left[n_c\right]}$, $U_s={\left\{v_i\right\}}_{i\in \left[n_s\right]}$, respectively. An originally non-existent label $labe{l}_i$ that looks random will be generated for each item $v_i\in U_s$ in the intermediate process, and $\mathcal{C}$ will learn $\{labe{l}_i:v_i\in U_c\}$, the set of labels corresponding to the items in the intersection as a result. It should be noted that in the PSI filter generating process, $\mathcal{C}$ does not know the specific correspondence of any pair $(v_i,labe{l}_i)$, and $\mathcal{S}$ does not know which labels $\mathcal{C}$ will retain, so the identities are hidden for both $\mathcal{C}$ and $\mathcal{S}$.

We give the basic idea of the PSI filter generation protocol design in Figure 2. $\mathcal{C}$ and $\mathcal{S}$ hold their private keys $k_c$ and $k_s$, respectively. For each item, $v_i\in U_s$, $\mathcal{S}$ computes $H{\left(v_i\right)}^{k_s}$ as the distinguishable labels forming the set ${\mathsf{\Theta }}_1$ and specifying all the correspondence $<v_i,H{\left(v_i\right)}^{k_s}>$. To determine if $u_i=v_j$, $\mathcal{C}$ and $\mathcal{S}$ jointly compute the double-encryption results $H{\left(u_i\right)}^{k_c{k}_s}$ and $H{\left(v_j\right)}^{k_c{k}_s}$, which is similar to Diffie–Hellman key exchange process. We have that if $u_i=v_j$ then $H{\left(u_i\right)}^{k_c{k}_s}=H{\left(v_j\right)}^{k_c{k}_s}$, and the converse proposition holds with an overwhelming probability close to 1 while the collision resistance holds. After the intersection operation on the sets ${\{H{\left(u_i\right)}^{k_c{k}_s}\}}_{i\in \left[n_c\right]}$ and ${\{H{\left(v_j\right)}^{k_c{k}_s}\}}_{j\in \left[n_s\right]}$, while guaranteeing the privacy of identities $u_i$ and $v_j$ due to the DDH assumption, $\mathcal{C}$ could get the subset ${\mathsf{\Theta }}_2$ of the distinguishable labels in which the labels are corresponding to the items in $U_c$ one by one. The details of the PSI filter generation protocol $\mathsf{PFGen}$ are given in Figure 3.

Thus far, the PSI filter $\mathcal{F}=({\mathsf{\Theta }}_1,{\mathsf{\Theta }}_2)$ has been generated and ${\mathsf{\Theta }}_1,{\mathsf{\Theta }}_2$ are held separately by $\mathcal{S}$ and $\mathcal{C}$. Note that ${\mathsf{\Theta }}_1$ is required to be an ordered set while ${\mathsf{\Theta }}_2$ is an ordinary set. The generation protocol $\mathsf{PFGen}$ will be used as a subprotocol in the setup phase of aggregate query protocols. We will formally state and prove the security of the $\mathsf{PFGen}$ protocol in Section 7, and we just simply indicate here that the $\mathsf{PFGen}$ protocol is secure against semi-honest adversaries, so it can be used to construct privacy-preserving query protocols. Note that the difference from a traditional PSI protocol is that both the two parties have no idea if an item is exactly in the intersection I. All they can get are the labels that look random.

5. Aggregate Query Protocols

In this section, we use the $\mathsf{PFGen}$ protocol proposed in Section 4 to build privacy-preserving query protocols for different types of aggregate queries. In these protocols, the client $\mathcal{C}$ and the server $\mathcal{S}$ execute the $\mathsf{PFGen}$ protocol to generate a PSI filter in the setup phase. In the query phase, $\mathcal{C}$ finds out the encrypted data related to the users in the intersection from all candidate structured data received from $\mathcal{S}$ by comparing the labels in ${\mathsf{\Theta }}_1$ with those in ${\mathsf{\Theta }}_2$.

5.1. RNNC Query

• Setup:

Step 1:$\mathcal{S}$ and $\mathcal{C}$ execute the $\mathsf{PFGen}$ protocol with secure parameter $\lambda$. The output is the PSI filter$\mathcal{F}=({\mathsf{\Theta }}_1,{\mathsf{\Theta }}_2)$, where ${\mathsf{\Theta }}_1$ and ${\mathsf{\Theta }}_2$ are held by $\mathcal{S}$ and $\mathcal{C}$, respectively.

Step 2:$\mathcal{S}$ takes the same secure parameter $\lambda$ to generate the key pair $(sk,pk)$ of the Paillier cryptosystem, then sends $pk$ to $\mathcal{C}$.

• Query:

Step 1:$\mathcal{C}$ sends the query request $F=\{f_1,\dots ,f_k\}$ with the type of query “RNNC” to $\mathcal{S}$.

Step 2: After receiving the facility locations, $\mathcal{S}$ computes $d\langle f_i,l_j\rangle$ for $i\in \left[k\right]$ and $j\in \left[n_s\right]$, which means the distances between $f_i\in F$ and $u_j\in U_s$. $\mathcal{S}$ determines each user’s nearest neighbor.

Step 3:$\mathcal{S}$ initializes a $n_s\times k$ zero matrix $\mathbf{M}$, then sets $m_{ij}=1$ for all i, j satisfying $f_j$ is $u_i$’s nearest neighbor. $\mathcal{S}$ computes ${\mathbf{M}}^{\prime }$, the ciphertext of $\mathbf{M}$ under the public key $pk$, i.e., computes each $m_{ij}^{\prime }=\mathrm{Enc}(pk,m_{ij})$.

Step 4:$\mathcal{S}$ augments the ciphertext matrix ${\mathbf{M}}^{\prime }$ with ${\mathsf{\Theta }}_1$, and gets $n_s\times (k+1)$ matrix ${\mathbf{N}}^{\prime }=\begin{array}{cc}{\mathsf{\Theta }}_1& {\mathbf{M}}^{\prime }\end{array}$ as a result (treating the ordered set ${\mathsf{\Theta }}_1$ as a column vector, the same below), then sends ${\mathbf{N}}^{\prime }$ to $\mathcal{C}$.

Step 5: For each row of ${\mathbf{N}}^{\prime }$, $\mathcal{C}$ retains the row if the first element of the row is also in ${\mathsf{\Theta }}_2$. Otherwise, it discards the row. Then, $\mathcal{C}$ discards the first column to obtain a $n_I\times k$ matrix ${\mathbf{Y}}^{\prime }$.

Step 6:$\mathcal{C}$ multiplies the elements in each column of ${\mathbf{Y}}^{\prime }$ and gets the vector ${\mathbf{s}}^{\prime }=[s_1^{\prime },\dots ,s_k^{\prime }]$. $\mathcal{C}$ picks a random vector $\mathbf{r}=[r_1,\dots ,r_k]$ where $r_i\in {\mathbb{Z}}_n$, computes ${\mathbf{r}}^{\prime }=[r_1^{\prime },\dots ,r_k^{\prime }]$ where $r_i^{\prime }=\mathrm{Enc}\left(r_i\right)$, then computes ${\mathbf{t}}^{\prime }=[t_1^{\prime },\dots ,t_k^{\prime }]$ where $t_i^{\prime }=s_i^{\prime }{r}_i^{\prime }$. $\mathcal{C}$ sends ${\mathbf{t}}^{\prime }$ to $\mathcal{S}$.

Step 7:$\mathcal{S}$ decrypts ${\mathbf{t}}^{\prime }$ by computing $t_i=\mathrm{Dec}(sk,t_i^{\prime })$, then returns $\mathbf{t}=[t_i,\dots ,t_k]$ to $\mathcal{C}$.

Step 8:$\mathcal{C}$ computes $\mathbf{s}=\mathbf{t}-\mathbf{r}$ and lets $q_i=s_i$ to obtain $\mathbf{Q}=[q_1,\dots ,q_k]$ as the query result.

The key parts are (1) $\mathcal{C}$/$\mathcal{S}$ hides its user set from the other one by using the PSI filter, which also reduces the computational cost and communication cost, (2) $\mathcal{S}$ hides the user’s location information by using additively homomorphic encryption, (3) $\mathcal{C}$ picks a random vector $\mathbf{r}$ to mask $\mathbf{s}$ (on ciphertext) to hide the query result from $\mathcal{S}$. Clearly, $\mathbf{Q}=[q_1,\dots ,q_k]$ is the desired query result where $q_i$ is equal to the RNN cardinality of $f_i$. We will give the other two aggregate query protocols with similar ideas, and a detailed explanation of correctness and privacy are given in Section 7.

In practice, it is not necessary to generate a key pair of Paillier cryptosystems every time a client comes in. The server can set several key pairs $\{s{k}_i,p{k}_i\}$ corresponding to different security levels (parameters ${\lambda }_i$) and make all $\{{\lambda }_i,p{k}_i\}$ public. When a new client comes in and needs to set up the server, it can pick an appropriate public key and just tell the server which one it chose. The same goes for the next two query protocols in Section 5.2 and Section 5.3

5.2. AVGD Query

• Setup:

The setup phase is the same as in Section 5.1.

• Query:

Step 1:$\mathcal{C}$ sends the query request $F=\{f_1,\dots ,f_k\}$ with the type of query “AVGD” to $\mathcal{S}$.

Step 2: After receiving the facility locations, $\mathcal{S}$ computes $d\langle f_i,l_j\rangle$ for $i\in \left[k\right]$ and $j\in \left[n_s\right]$, which means the distances between $f_i\in F$ and $u_j\in U_s$. $\mathcal{S}$ determines each user’s nearest neighbor.

Step 3:$\mathcal{S}$ initializes a column vector $\mathbf{D}={[d_1,\dots ,d_{n_s}]}^{\mathsf{T}}$ where $d_i$ is the distance between $u_i$ and its nearest neighbor, then computes ${\mathbf{D}}^{\prime }$, the ciphertext of $\mathbf{D}$ under the public key $pk$, i.e., computes each $d_i^{\prime }=\mathrm{Enc}(pk,d_i)$.

Step 4:$\mathcal{S}$ augments ciphertext matrix ${\mathbf{D}}^{\prime }$ with ${\mathsf{\Theta }}_1$, gets $n_s\times 2$ matrix ${\mathbf{N}}^{\prime }=\begin{array}{cc}{\mathsf{\Theta }}_1& {\mathbf{D}}^{\prime }\end{array}$, then sends ${\mathbf{N}}^{\prime }$ to $\mathcal{C}$.

Step 5: For each row of ${\mathbf{N}}^{\prime }$, $\mathcal{C}$ retains the row if the first element of the row is also in ${\mathsf{\Theta }}_2$. otherwise, it discards the row. Then, $\mathcal{C}$ discards the first column to obtain a $n_I$-dimensional column vector ${\mathbf{Y}}^{\prime }={[y_1^{\prime },\dots ,y_{n_I}^{\prime }]}^{\mathsf{T}}$ and saves $n_I$.

Step 6:$\mathcal{C}$ picks a random number $r\in {\mathbb{Z}}_n$ and lets $r^{\prime }=\mathrm{Enc}\left(r\right)$. $\mathcal{C}$ computes $s^{\prime }={\prod }_{i=1}^{n_I}{y}_i^{\prime }$ and $t^{\prime }=s^{\prime }{r}^{\prime }$, then sends $t^{\prime }$ to $\mathcal{S}$.

Step 7:$\mathcal{S}$ decrypts $t^{\prime }$ by computing $t=\mathrm{Dec}(sk,t^{\prime })$, then returns t to $\mathcal{C}$.

Step 8:$\mathcal{C}$ computes $s=t-r$ and $Q=s/n_I$ to obtain the query result Q.

5.3. MAXD Query

• Setup:

The setup phase is the same as in Section 5.1.

• Query:

Step 1:$\mathcal{C}$ sends the query request $F=\{f_1,\dots ,f_k\}$ with the type of query “MAXD” to $\mathcal{S}$.

Step 2: After receiving the facility locations, $\mathcal{S}$ computes $d\langle f_i,l_j\rangle$ for $i\in \left[k\right]$ and $j\in \left[n_s\right]$, which means the distances between $f_i\in F$ and $u_j\in U_s$. $\mathcal{S}$ determines each user’s nearest neighbor.

Step 3:$\mathcal{S}$ initializes a column vector $\mathbf{D}={[d_1,\dots ,d_{n_s}]}^{\mathsf{T}}$ where $d_i$ is the distance between $u_i$ and its nearest neighbor, sorts all $d_i\in \mathbf{D}$ to obtain $\hat{\mathbf{D}}={[d_{\tau \left(1\right)},\dots ,d_{\tau \left(n_s\right)}]}^{\mathsf{T}}$ where $d_{\tau \left(i\right)}\ge d_{\tau (i+1)}$, then sets ${\hat{\mathsf{\Theta }}}_1={[labe{l}_{\tau \left(1\right)}^{\mathcal{S}},\dots ,labe{l}_{\tau \left(n_s\right)}^{\mathcal{S}}]}^{\mathsf{T}}$.

Step 4:$\mathcal{S}$ computes ${\hat{\mathbf{D}}}^{\prime }={[d_{\tau \left(1\right)}^{\prime },\dots ,d_{\tau \left(n_s\right)}^{\prime }]}^{\mathsf{T}}$ where $d_{\tau \left(i\right)}^{\prime }=\mathrm{Enc}(pk,d_{\tau \left(i\right)})$, then sends ${\mathbf{N}}^{\prime }=\begin{array}{cc}{\hat{\mathsf{\Theta }}}_1& {\hat{\mathbf{D}}}^{\prime }\end{array}$ to $\mathcal{C}$.

Step 5: From the top to bottom of ${\mathbf{N}}^{\prime }$, $\mathcal{C}$ finds out the first row in which the $labe{l}_{\tau \left(j\right)}^{\mathcal{S}}$ is in ${\mathsf{\Theta }}_2$ (suppose it is the jth row). $\mathcal{C}$ holds $d_{\tau \left(j\right)}^{\prime }$ and discards all other elements.

Step 6:$\mathcal{C}$ picks a random number $r\in {\mathbb{Z}}_n$, computes $r^{\prime }=\mathrm{Enc}\left(r\right)$, then computes $t^{\prime }=d_{\tau \left(j\right)}^{\prime }{r}^{\prime }$. $\mathcal{C}$ sends $t^{\prime }$ to $\mathcal{S}$.

Step 7:$\mathcal{S}$ decrypts $t^{\prime }$ by computing $t=\mathrm{Dec}(sk,t^{\prime })$, then returns t to $\mathcal{C}$.

Step 8:$\mathcal{C}$ computes $Q=t-r$ (in fact $Q=d_{\tau \left(j\right)}$) as the query result Q.

5.4. Application Examples

In order to make it more clear how to apply our privacy-preserving aggregate query protocols to the actual scenes, we give the application examples for each of the three types of queries as follows.

• A bank wants to open a branch.
  The bank may hope that the new branch serves more people, so it can carry out the RNNC query by interacting with the LSP. Then the bank can choose the best one from several alternative locations to open a branch.
• An express (delivery) company wants to build a new distribution station.
  The company probably hopes to minimize the total delivery distance (count the distance of all distribution stations), so it can carry out the AVGD query by interacting with the LSP. Then the company can choose the best one from several alternative locations to build a new distribution station.
• Choosing a site for a non-profit hospital to be established.
  Choosing a site for a hospital may consider the worst case—it hopes that the furthest one of the all potential patients can arrive at the hospital in a shorter time, i.e., the goal is to minimize the maximum distance between all potential patients and his/her nearest hospital, so it can carry out the MAXD query by interacting with the LSP. Then the hospital can be established in the best location chosen from several alternative locations.

6. Ciphertext Matrix Compressing

Although the processes of the three query protocols in Section 5 have similar design ideas, the communication costs are not exactly of the same magnitude in different query types. Concretely, the communication costs of AVGD query and MAXD query are both roughly $O\left(n_s\right)$, but that of RNNC query is roughly $O(n_s·k)$. The essential cause is that the dimension of matrix $\mathbf{M}$ initialized in Step 3 of the RNNC query must be sufficient to contain the relationship information between all $n_s$ users and all k facilities when each row of the $n_s$-dimension vector $\mathbf{D}$ in Step 3 of AVGD/MAXD query corresponds to only one (the nearest) facility. When the scale of the facility set F is large, the linear relationship between communication cost and the number of facilities will be a challenge. To address this issue, we compress the ciphertext for this particular scenario (the plaintext space actually used is much less than ${\mathbb{Z}}_n$). Properly speaking, under the same security parameter, we make the same size ciphertext contain more plaintext information, which will lead to the reduction of the ciphertext matrix dimension.

In homomorphic cryptosystems satisfying CPA-security, the size of the ciphertext is bigger than that of plaintext because there must be enough randomization to achieve a “non-determination” property. In a Paillier cryptosystem, the encryption function is essentially a map $f:{\mathbb{Z}}_n\times {\mathbb{Z}}_n^{*}\mapsto {\mathbb{Z}}_{n^2}^{*}$, where ${\mathbb{Z}}_n$ is the plaintext space, ${\mathbb{Z}}_{n^2}^{*}$ is the ciphertext space, and the selected random number $r\in {\mathbb{Z}}_n^{*}$ ensures the “non-determination” property. Clearly, the size of the ciphertext is equal to $2\times$ the size of the plaintext. It seems unrealistic to directly compress the ciphertext space under the premise of ensuring security: (1) It is impossible to compress ${\mathbb{Z}}_{n^2}^{*}$ while keeping ${\mathbb{Z}}_n$ and ${\mathbb{Z}}_n^{*}$ fixed because f is bijective, (2) Ensuring a constant security level means that ${\mathbb{Z}}_n^{*}$ can not be compressed, (3) It is hard to compress both ${\mathbb{Z}}_n$ and ${\mathbb{Z}}_{n^2}^{*}$ simultaneously because such behavior will easily break the ingenious bijection structure—the underlying theoretical basis of the Paillier cryptosystem. The generalized Paillier cryptosystem [29] can efficiently reduce the ciphertext expansion factor to $\frac{s+1}{s}$ where s is proportional to the block size of the ciphertext, but under the same secure parameter $\lambda$, picking a large s means concurrently expanding both plaintext space and ciphertext space. Concisely, in a generalized Paillier cryptosystem, a smaller ciphertext expansion factor leads to a larger ciphertext block size, which is not suitable for our scenario. A method [30] similar to ours is an efficient algorithm for fast batch summation using homomorphism on generalized Paillier cryptosystems, but we do not want to use the big ciphertext block because the number of facilities k may be relatively too small to waste a lot of space and bring unnecessary computational overhead.

We observe that even encrypting a small number needs a complete block in a Paillier cryptosystem. For a small number $m\ll n$, the plaintext space ${\mathbb{Z}}_n$ is far from being efficiently used, i.e., ${log}_2\frac{n}{m}$ bits are wasted. In the RNNC query protocol, the elements in matrix ${\mathbf{M}}^{\prime }$ are either $\mathrm{Enc}\left(0\right)$ or $\mathrm{Enc}\left(1\right)$; even in steps 6 and 8 for each $s_i^{\prime }=\mathrm{Enc}\left(s_i\right)$, $s_i$ is relatively very small compared with n.

Our solution is putting multiple data (small numbers) in one plaintext while keeping the ciphertext able to be calculated using the homomorphism property from the vertical direction. Supporting the plaintext space is ${\mathbb{Z}}_n$ and each single data in plaintext throughout the process (considering the intermediate calculation products after decrypting) is no more than $\alpha$ bits, i.e., no overflows of plaintext occur after the sum operations by the homomorphic property in the intermediate process. The process of ciphertext matrix compressing is given in Figure 4.

Suppose we have already generated the parameters of the Paillier cryptosystem over the security parameter $\lambda$. First, we choose the parameter $\alpha$ such that no overflows occur for plaintext throughout the whole query protocol and naturally let $\eta =\frac{{log}_{2}n}{\alpha }$, where $\eta$ means that any block${}_i$ can contain up to $\eta$ data ($m_{i1},\dots ,m_{i\eta }$).

Then, we perform the following process.

(1) For $1\le i\le \mu$, put $\eta$ data in one plaintext block: for $1\le j\le \eta$, pad each $m_{ij}=1$ or 0 to $\alpha$ bits with “0” then attach them end to end—a plaintext block has been constructed.

(2) For $1\le i\le \mu$, compute $c_i=\mathrm{Enc}(pk,{\mathtt{block}}_i)$.

(3) Compute $P={\prod }_{i=1}^{\mu }{c}_i$.

(4) Compute $\hat{s}=\mathrm{Dec}(sk,P)$, then donate $\hat{s}$ as $s_1\left|\right|s_2\left|\right|\dots \left|\right|s_{\eta }$ where $s_i$ is a $\alpha$-bit binary string.

Thus far, we have encrypted $\mu ·\eta$ data using just $\mu$ plaintext blocks. Meanwhile, we have gotten $s_1,\dots ,s_{\eta }$ by running $(\mu -1)$ rather than $(\mu -1)·\eta$ multiplications on the ciphertext. In order to express more clearly, we give a toy example here and interpret why the homomorphic property can still be used.

A toy example. let $\lambda =1024$, $\mu =3$, $\alpha =256$ and $\eta =\frac{\lambda }{\alpha }=4$. Take the matrix as input

$$\mathbf{M}=\begin{array}{c}\left[\begin{array}{cccc}0& 0& 1& 1\\ 0& 1& 0& 1\\ 1& 1& 1& 1\end{array}\right].\end{array}$$

After padding and attaching procedures, we get three blocks as follows.

$$\begin{array}{cc}\hfill {\mathtt{block}}_1:\begin{array}{|c|}\hline 0\dots 0\mathbf{0}\left|\right|0\dots 0\mathbf{0}\left|\right|0\dots 0\mathbf{1}\left|\right|0\dots 0\mathbf{1}\\ \hline\end{array}=& 2^{1·\alpha }+2^{0·\alpha }\hfill \\ \hfill {\mathtt{block}}_2:\begin{array}{|c|}\hline 0\dots 0\mathbf{0}\left|\right|0\dots 0\mathbf{1}\left|\right|0\dots 0\mathbf{0}\left|\right|0\dots 0\mathbf{1}\\ \hline\end{array}=& 2^{2·\alpha }+2^{0·\alpha }\hfill \\ \hfill {\mathtt{block}}_3:\begin{array}{|c|}\hline 0\dots 0\mathbf{1}\left|\right|0\dots 0\mathbf{1}\left|\right|0\dots 0\mathbf{1}\left|\right|0\dots 0\mathbf{1}\\ \hline\end{array}=& 2^{3·\alpha }+2^{2·\alpha }+2^{1·\alpha }+2^{0·\alpha }\hfill \end{array}$$

(3)

After (2)–(4), it is easy to draw that

$$\begin{array}{cc}\hfill P& =\prod _{i=1}^3{c}_i\hfill \\ \hfill & =\mathrm{Enc}\left(\sum _{i=1}^3{\mathtt{block}}_i\right)\hfill \\ \hfill & =1\times 2^{3·\alpha }+2\times 2^{2·\alpha }+2\times 2^{1·\alpha }+3\times 2^{0·\alpha }\hfill \\ \hfill & =0\dots 0\mathbf{1}\left|\right|0\dots 0\mathbf{10}\left|\right|0\dots 0\mathbf{10}\left|\right|0\dots 0\mathbf{11}.\hfill \end{array}$$

(4)

Therefore, we get $s_1=1$, $s_2=2$, $s_3=2$ and $s_4=3$. It is easy to verify that $s_j={\sum }_{i=1}^3{m}_{ij}$ for any $j\in \{1,2,3,4\}$.

For our column-wise summation problem of a small-value $\mu \times \eta$ matrix, the proposed ciphertext matrix compressing combines (pads with 0 then links) multiple plaintexts in a row before encrypting. The number of ciphertext blocks can be reduced from $\mu \times \eta$ to $\mu$, and the number of encryption/decryption operations is reduced from $\mu \times \eta$ to $\mu$. At the same time, the homomorphic property is kept valid. Therefore, we can reform the RNNC query protocol by utilizing the ciphertext matrix compressing method. Here is the variation of the steps of the query process.

An Improved Protocol RNNC-CMC:

Step 3:$\mathcal{S}$ initializes an $n_s\times k$ zero matrix $\mathbf{M}$, then sets $m_{ij}=1$ for all i, j satisfying $f_j$ is $u_i$’s nearest neighbor. $\mathcal{S}$ compresses the matrix $\mathbf{M}$ to $n_s\times \lceil k/\eta \rceil$ matrix $\tilde{\mathbf{M}}$. (When k is not an integer multiple of $\eta$, the way to deal with the extra space is simple: padding with “0” in Step 3.) $\mathcal{S}$ computes ${\tilde{\mathbf{M}}}^{\prime }$, the ciphertext of $\tilde{\mathbf{M}}$ under the public key $pk$, i.e., computes each ${\tilde{m}}_{ij}^{\prime }=\mathrm{Enc}(pk,{\tilde{m}}_{ij})$.

Step 4:$\mathcal{S}$ augments the ciphertext matrix ${\tilde{\mathbf{M}}}^{\prime }$ with ${\mathsf{\Theta }}_1$, and gets $n_s\times (\lceil k/\eta \rceil +1)$ matrix ${\tilde{\mathbf{N}}}^{\prime }=\begin{array}{cc}{\mathsf{\Theta }}_1& {\tilde{\mathbf{M}}}^{\prime }\end{array}$ as a result, then sends ${\tilde{\mathbf{N}}}^{\prime }$ to $\mathcal{C}$.

Step 5: For each row of ${\mathbf{N}}^{\prime }$, $\mathcal{C}$ retains the row if the first element of the row is also in ${\mathsf{\Theta }}_2$. Otherwise, it discards the row. Then, $\mathcal{C}$ discards the first column to obtain a $n_I\times \lceil k/\eta \rceil$ matrix ${\tilde{\mathbf{Y}}}^{\prime }$.

Step 6:$\mathcal{C}$ multiplies the elements in each column of ${\tilde{\mathbf{Y}}}^{\prime }$ and gets the vector ${\tilde{\mathbf{s}}}^{\prime }=[{\tilde{s}}_1^{\prime },\dots ,{\tilde{s}}_{\lceil k/\eta \rceil }^{\prime }]$. $\mathcal{C}$ picks a random vector $\mathbf{r}=[r_1,\dots ,r_{\lceil k/\eta \rceil }]$, computes ${\mathbf{r}}^{\prime }=[r_1^{\prime },\dots ,r_{\lceil k/\eta \rceil }^{\prime }]$ where $r_i^{\prime }=\mathrm{Enc}\left(r_i\right)$, then computes ${\tilde{\mathbf{t}}}^{\prime }=[{\tilde{t}}_1^{\prime },\dots ,{\tilde{t}}_{\lceil k/\eta \rceil }^{\prime }]$ where ${\tilde{t}}_i^{\prime }={\tilde{s}}_i^{\prime }{r}_i^{\prime }$. $\mathcal{C}$ sends ${\tilde{\mathbf{t}}}^{\prime }$ to $\mathcal{S}$.

Step 7:$\mathcal{S}$ decrypts ${\mathbf{t}}^{\prime }$ by computing $t_i=\mathrm{Dec}(sk,{\tilde{t}}_i^{\prime })$, then returns $\tilde{\mathbf{t}}=[{\tilde{t}}_i,\dots ,{\tilde{t}}_{\lceil k/\eta \rceil }]$ to $\mathcal{C}$.

Step 8:$\mathcal{C}$ computes $\tilde{\mathbf{s}}=\tilde{\mathbf{t}}-\tilde{\mathbf{r}}$, then separates the vector $[{\tilde{s}}_1,\dots ,{\tilde{s}}_{\lceil k/\eta \rceil }]$ to $[s_1,\dots ,s_k]$—like (4) in CMC for each ${\tilde{s}}_i$ (ignoring separated $s_i$ for $i>k)$. Finally, $\mathcal{C}$ sets $q_i=s_i$ to obtain $\mathbf{Q}=[q_1,\dots ,q_k]$ as the query result.

The changes of the reformed protocol RNNC-CMC are intuitive: (1) compressing the scale of matrix $\mathbf{M}$ from $n_s\times k$ to $n_s\times \lceil k/\eta \rceil$, which can efficiently reduce the communication cost; (2) one homomorphic operation (multiplication) on ciphertext by column is equivalent to $\eta$ operations in the original RNNC query protocol. The details of the comparison are given in Section 8.

7. Security Analysis

In this section, we first derive the correctness of our aggregate protocols. Then, we consider the privacy of the PSI filter generation protocol $\mathsf{PFGen}$, give an optional handling for stricter privacy protection as a supplement and finally discuss the privacy of our aggregate query protocols and two types of external attackers.

7.1. Correctness

We simply derive the correctness of three types of queries.

For a component $q_i\in \mathbf{Q}$ in RNNC query, the following equation holds:

$$\begin{array}{cc}\hfill q_i& =t_i-r_i=\mathrm{Dec}(sk,t_i^{\prime })-r_i=\mathrm{Dec}(sk,s_i^{\prime }{r}_i^{\prime })-r_i\hfill \\ \hfill & =\mathrm{Dec}(sk,\prod _{j=1}^{n_I}{y}_{ji}·r_i)-r_i=\sum _{j=1}^{n_I}{y}_{ji}+r_i-r_i=\sum _{u_i\in I}{m}_{ij}.\hfill \end{array}$$

(5)

For the query result Q in AVGD query,

$$\begin{array}{cc}\hfill Q& =\frac{s}{n_I}=\frac{t-r}{n_I}=\frac{\mathrm{Dec}(sk,t^{\prime })-r}{n_I}=\frac{\mathrm{Dec}(sk,s^{\prime }{r}^{\prime })-r}{n_I}\hfill \\ \hfill & =\frac{\mathrm{Dec}(sk,{\displaystyle \prod _{i=1}^{n_I}}{y}_i^{\prime }·r^{\prime })-r}{n_I}=\frac{{\displaystyle \sum _{i=1}^{n_I}}{y}_i+r-r}{n_I}=\frac{{\displaystyle \sum _{u_i\in I}}{d}_i}{n_I}.\hfill \end{array}$$

(6)

For the query result Q in MAXD query, due to the monotonicity of $\hat{\mathbf{D}}$, i.e., $d_{\tau \left(i\right)}\ge d_{\tau (i+1)}$, and Step 5, we only need to demonstrate that $t-r=d_{\tau \left(j\right)}$ holds as follows:

$$\begin{array}{cc}\hfill t-r& =\mathrm{Dec}(sk,t^{\prime })-r=\mathrm{Dec}(sk,d_{\tau \left(j\right)}^{\prime }{r}^{\prime })-r\hfill \\ \hfill & =d_{\tau \left(j\right)}+r-r=d_{\tau \left(j\right)}.\hfill \end{array}$$

(7)

7.2. Privacy

As for the privacy of our aggregate query protocols, we first show our PSI filter generation protocol $\mathsf{PFGen}$ proposed in Section 4 would not reveal any information about the private data and give optional handling for stricter privacy protection (treating $n_s$ and $n_c$ as privacy). Based on this, we illustrate that the proposed aggregate query protocols are privacy-preserving.

The following lemma is given to illustrate the security of the $\mathsf{PFGen}$ protocol in a semi-honest model, and we give the proof in the simulation paradigm.

Lemma 1.

There exist PPT simulators${\mathrm{SIM}}_1$and ${\mathrm{SIM}}_2$, s.t. for all security parameters λ and inputs${\left\{u_i\right\}}_{i\in \left[n_c\right]}$,${\left\{v_j\right\}}_{j\in \left[n_s\right]}$,

$${\mathrm{REAL}}^{c,\lambda }({\left\{u_i\right\}}_{i\in \left[n_c\right]},{\left\{v_j\right\}}_{j\in \left[n_s\right]})\stackrel{c}{\equiv }{\mathrm{SIM}}_c(1^{\lambda },{\left\{u_i\right\}}_{i\in \left[n_c\right]},n_s,n_I),$$

and

$${\mathrm{REAL}}^{s,\lambda }({\left\{u_i\right\}}_{i\in \left[n_c\right]},{\left\{v_j\right\}}_{j\in \left[n_s\right]})\stackrel{c}{\equiv }{\mathrm{SIM}}_s(1^{\lambda },{\left\{v_j\right\}}_{j\in \left[n_s\right]},n_c,n_I).$$

Proof. 

We give the simulators ${\mathrm{SIM}}_c$ and ${\mathrm{SIM}}_s$ in Algorithms 1 and 2 as follows.

Algorithm 1${\mathrm{SIM}}_c$: The simulator for Client

Input:$(1^{\lambda },{\{u_i\}}_{i\in \left[n_c\right]},n_s,|I|)$ Output:$vie{w}_c={\mathrm{SIM}}_c(1^{\lambda },{\{u_i\}}_{i\in \left[n_c\right]},n_s,\left|I\right|)$ 1: Generate key $k_c\in \mathbb{G}$ 2: Honestly generate and send $\mathrm{Shuf}({\{H{(u_i)}^{k_c}\}}_{i\in \left[n_c\right]})$ as Client’s message in Step 2. 3: Create a dummy set $D_1={\{g_i\}}_{i\in \left[n_c\right]}$, where each $g_i$ is randomly selected from $\mathbb{G}$. 4: Compute then send $\mathrm{Shuf}({\{g_i^{k_c}\}}_{i\in \left[n_c\right]})$ as the message received from Server. (regard $g_i$ as a dummy $H{(u_i)}^{k_s}$) 5: Create a dummy set $D_2={\{h_i\}}_{i\in \left[n_s\right]}$, where $h_i=g_i$ for $i\in \left[\right|I\left|\right]$ and each $h_i$ for $i\in \left[\right|I|+1,n_s]$ is randomly selected from $\mathbb{G}$. 6: Send $\mathrm{Shuf}({\{h_i\}}_{i\in \left[n_s\right]})$ as the message received from Server. (regard $h_i$ as a dummy $labe{l}_i=H{(v_i)}^{k_s}$) 7: Honestly generate Client’s message in Step 3 using $D_2={\{h_i\}}_{i\in \left[n_s\right]}$. 8: Honestly execute Step 4 using ${\{g_i^{k_c}\}}_{i\in \left[n_c\right]}$ and ${\{h_i,h_i^{k_c}\}}_{i\in \left[n_s\right]}$ 9: Output Client’s view $vie{w}_c$.

Algorithm 2${\mathrm{SIM}}_s$: The simulator for Server

Input:$(1^{\lambda },{\{v_i\}}_{i\in \left[n_s\right]},n_c)$ Output:$vie{w}_s={\mathrm{SIM}}_s(1^{\lambda },{\{v_i\}}_{i\in \left[n_s\right]},n_c)$ 1: Generate key $k_s\in \mathbb{G}$ 2: Create a dummy set $D_3={\{g_i^{\prime }\}}_{i\in \left[n_c\right]}$, where each $g_i^{\prime }$ is randomly selected from $\mathbb{G}$. Send $\mathrm{Shuf}({\{g_i^{\prime }\}}_{i\in \left[n_c\right]})$ as the message received from Client. 3: Honestly generate ${\{{g_i^{\prime }}^{k_s}\}}_{i\in \left[n_c\right]}$ and ${\{H{(v_i)}^{k_s}\}}_{i\in \left[n_s\right]}$. 4: Compute then send both $\mathrm{Shuf}({\{{g_i^{\prime }}^{k_s}\}}_{i\in \left[n_c\right]})$ and $\mathrm{Shuf}({\{H{(v_i)}^{k_s}\}}_{i\in \left[n_s\right]})$ as Server’s message to be sent to Client. (regard ${g^{\prime }}_i$ as a dummy $H{(u_i)}^{k_c}$) 5: Output Server’s view $vie{w}_s$

The simulation process of ${\mathrm{SIM}}_c$ is the same as $\mathcal{C}$’s Step 1–4 of the $\mathsf{PFGen}$ protocol as long as we regard ${\left\{g_i\right\}}_{i\in \left[n_c\right]}$ and ${\left\{h_i\right\}}_{i\in \left[n_s\right]}$ as the dummy ${\left\{H{\left(u_i\right)}^{k_s}\right\}}_{i\in \left[n_c\right]}$ and the dummy ${\{labe{l}_i=H{\left(v_i\right)}^{k_s}\}}_{i\in \left[n_s\right]}$. Similarly, the simulation process of ${\mathrm{SIM}}_s$ is the same as $\mathcal{S}$’s Step 1–4 of the $\mathsf{PFGen}$ protocol when we regard ${\left\{g_i^{\prime }\right\}}_{i\in \left[n_c\right]}$ as the dummy ${\left\{H{\left(u_i\right)}^{k_c}\right\}}_{i\in \left[n_c\right]}$.

We can say that for all security parameters $\lambda$ and inputs ${\left\{u_i\right\}}_{i\in \left[n_c\right]}$, ${\left\{v_j\right\}}_{j\in \left[n_s\right]}$,

$${\mathrm{REAL}}^{c,\lambda }({\left\{u_i\right\}}_{i\in \left[n_c\right]},{\left\{v_j\right\}}_{j\in \left[n_s\right]})\stackrel{c}{\equiv }{\mathrm{SIM}}_c(1^{\lambda },{\left\{u_i\right\}}_{i\in \left[n_c\right]},n_s,n_I),$$

and

$${\mathrm{REAL}}^{s,\lambda }({\left\{u_i\right\}}_{i\in \left[n_c\right]},{\left\{v_j\right\}}_{j\in \left[n_s\right]})\stackrel{c}{\equiv }{\mathrm{SIM}}_s(1^{\lambda },{\left\{v_j\right\}}_{j\in \left[n_s\right]},n_c,n_I),$$

from the DDH assumption. That is, $\mathcal{C}$ could not distinguish $({\{g_i^{k_c}\}}_{i\in \left[n_c\right]},{\{h_i^{k_c}\}}_{i\in \left[n_s\right]})$ and $({\{H{\left(u_i\right)}^{k_c{k}_s}\}}_{i\in \left[n_c\right]},{\{labe{l}_i=H{\left(v_i\right)}^{k_c{k}_s}\}}_{i\in \left[n_s\right]})$; and $\mathcal{S}$ could not distinguish ${\{{g_i^{\prime }}^{k_s}\}}_{i\in \left[n_c\right]}$ and ${\{H{\left(u_i\right)}^{k_c{k}_s}\}}_{i\in \left[n_c\right]}$.    □

From Lemma 1, we know that throughout the $\mathsf{PFGen}$ protocol, $\mathcal{C}$ can know nothing more than $n_s$ and $n_I$; $\mathcal{S}$ can know nothing more than $n_c$ and $n_I$. These values are, in fact, not so private for $\mathcal{S}$ and $\mathcal{C}$. When $\mathcal{S}$ and $\mathcal{C}$ want to further enhance the privacy, i.e., to hide the cardinalities $n_s$ and $n_c$ from each other, $\mathcal{S}$/$\mathcal{C}$ can simply add some dummy users to $U_s$/$U_c$. This can efficiently conceal $n_s$ and $n_c$ to some extent, and when a new dummy user is added, after being hashed to group $\mathbb{G}$, it may collide with a real user with a probability of $\frac{1}{\left|\mathbb{G}\right|}$. It can be said that $n_I$ is not a privacy issue when $n_s$ and $n_c$ have been concealed.

In the query process, all the messages $\mathcal{C}$ received are ${\mathbf{N}}^{\prime }$ and $\mathbf{t}$ (or t) where $\mathbf{t}$ (or t) is not a private message to $\mathcal{C}$; and the only message $\mathcal{S}$ received is ${\mathbf{t}}^{\prime }$ (or $t^{\prime }$). In the RNNC query protocol, ${\mathbf{N}}^{\prime }=\begin{array}{cc}{\mathsf{\Theta }}_1& {\mathbf{M}}^{\prime }\end{array}$ is a ciphertext matrix augmented with a vector of randomized labels from where $\mathcal{C}$ can not learn any plaintext information without the private key $sk$, and ${\mathbf{t}}^{\prime }=[t_1^{\prime },\dots ,t_k^{\prime }]$ is a ciphertext vector where each component $t_i^{\prime }=s_i^{\prime }{r}_i^{\prime }=\mathrm{Enc}(pk,q_i+r_i)$—even a curious $\mathcal{S}$ decrypts $\mathrm{Enc}(pk,q_i+r_i)$ by using $sk$, a masked query result $q_i+r_i$ would not reveal any information about $q_i$. In the AVGD query protocol, ${\mathbf{N}}^{\prime }=\begin{array}{cc}{\mathsf{\Theta }}_1& {\mathbf{D}}^{\prime }\end{array}$ is also ciphertext from where $\mathcal{C}$ can not learn anything, and $t^{\prime }=s^{\prime }{r}^{\prime }=\mathrm{Enc}(Q·n_I+r)$ is a masking version of $\mathrm{Enc}(Q·n_I)$ ensuring the privacy of the query result Q. In the MAXD query, similarly, ${\mathbf{N}}^{\prime }$ reveals nothing to $\mathcal{C}$, and $\mathcal{C}$ computes $t^{\prime }=d_{\tau \left(j\right)}^{\prime }{r}^{\prime }$ to ensure the privacy of the query result $Q=d_{\tau \left(j\right)}$ to $\mathcal{S}$ due to $\mathrm{Dec}(sk,t^{\prime })=d_{\tau \left(j\right)}+r$. Moreover, our ciphertext matrix compressing method does not sacrifice or reduce the security level. Because of the indistinguishability of the ciphertext in the Paillier cryptosystem, for the same security parameter $\lambda$, the RNNC-CMC query protocol is strictly as secure as the original RNNC query protocol in Section 5.

In addition, traditional protocols with similar ideas to Diffie–Hellman key exchange may suffer from two attacks—statistical attack and man-in-the-middle attack. We give the discussions on these two types of attacks as follows.

Statistical attack. In the $\mathsf{PFGen}$ protocol, each user will obtain a fixed label, and the label corresponding to each user is always the same. Intuitively, it seems that a statistical attack can get the frequency of the users during the queries. In fact, when the client and the server have jointly executed the $\mathsf{PFGen}$ protocol, the generated PSI filter (two sets of fixed labels) has also fixed the user sets with unknown correspondences, which means the client with a modified user set $U_c^{\prime }$ could not successfully execute the query protocols—even the client keeps the set $\mathrm{Shuf}({\left\{labe{l}_i\right\}}_{i\in \left[n_s\right]})$, the set ${\mathsf{\Theta }}_2$ could not be modified appropriately based only on $U_c^{\prime }$ without the correspondences.

Man-in-the-middle attack. There may be a malicious man intercepting in the middle between $\mathcal{S}$ and $\mathcal{C}$, sending and receiving data by using another key $k_e$. There is a simple way to deal with this attack: using the signature technique to ensure the authenticity of the source. Specifically, the Sender (whether $\mathcal{S}$ or $\mathcal{C}$) signs all messages as a whole during each interaction. Even without using the signature technique, it is difficult for the attacker to obtain useful information. When the attacker has jointly performed the $\mathsf{PFGen}$ protocol with $\mathcal{S}$, the computationally indistinguishable labels are meaningless for the attacker, and they can not obtain any private information from $\mathcal{S}$ during some forged queries, according to Lemma 1. When the attacker pretending to be a server has jointly performed the $\mathsf{PFGen}$ protocol with $\mathcal{C}$, the difference from the previous is that $\mathcal{C}$ may obtain a wrong result (non-optimal location) from the message received from the attacker during some queries. It can be said that the attacker may consume a lot of energy and can not obtain the information they want to know. Again, to prevent “man-in-the-middle attacker returning wrong query result”, the signature technique is sufficient.

8. Performance Evaluation

8.1. Theoretical Analysis

We first analyze the computational complexity for each party in the four proposed protocols and compare them with those of the state-of-the-art schemes in [3]—the server-based protocols RNNC/S, AVGD/S and MAXD/S, and the client-based protocols RNNC/C, AVGD/C and MAXD/C, as shown in

Table 1. Computational Complexity.

Comp. Complexity	Setup		Query Process
	$\mathcal{S}$	$\mathcal{C}$	$\mathcal{S}$	$\mathcal{C}$
State-of-the-art Schemes
RNNC/S	-	-	$n_s·k$ dist $\tilde{n}·k$ enc k dec	$n_c·k$ mult k enc
AVGD/S	-	-	$n_s·k$ dist $2·\tilde{n}$ enc 2 dec	$2·n_c$ mult 2 enc 1 div
MAXD/S	-	-	$n_s·k$ dist $n·w$ enc w dec	$w·(n_c-1)$ mult w exp
RNNC/C	-	$\tilde{n}$ enc	$n_s·k$ dist k enc $n_s+k$ mult	k dec
AVGD/C	-	$\tilde{n}$ enc	$n_s·k$ dist 2 enc $2·n_s$ mult $n_s$ exp	2 dec 1 div
MAXD/C	-	$\tilde{n}$ enc	$n_s·k$ dist $n_s$ mult w exp ≤w enc	$w-q+1$ dec
Our Schemes
RNNC	1 $\mathsf{PFGen}$		$n_s·k$ dist $n_s·k$ enc k dec	$n_I·k$ mult k enc
AVGD	1 $\mathsf{PFGen}$		$n_s·k$ dist $n_s$ enc 1 dec	1 enc $n_I$ mult 1 div
MAXD	1 $\mathsf{PFGen}$		$n_s·k$ dist $n_s$ enc 1 dec	1 enc 1 mult
RNNC-CMC	1 $\mathsf{PFGen}$		$n_s·k$ dist $n_s·\lceil k/\eta \rceil$ enc $\lceil k/\eta \rceil$ dec	$n_I·\lceil k/\eta \rceil$ mult $\lceil k/\eta \rceil$ enc

1. The $\tilde{n}$ is the size of the superset. Typically, in order to achieve enough privacy for both $U_s$ and $U_c$, $\tilde{n}$ should be far greater than (≫) $n_s$, or at least $\frac{\tilde{n}}{n_s}$ should be not less than a specified threshold. 2. w is a large number satisfying $w>max$, where $max$ is the maximum distance between a user and their nearest facility. 3. When $\mathcal{S}$ and $\mathcal{C}$ jointly run a $\mathsf{PFGen}$ processing, both $\mathcal{S}$ and $\mathcal{C}$ need $(n_c+n_s)$ exponentiation (modular n) operations, while the “exp” represents the exponentiation operation modular $n^2$. 4. The parameter $\eta =\frac{\lambda (={log}_{2}n)}{\alpha }$ is the amount of data concluded in one ciphertext block where $\lambda$ is the security parameter and $\alpha$ is the number of bits reserved for intermediate process with no overflows.

. We focus on the relatively time-consuming operations, i.e., encryption, decryption, multiplication on ciphertext and exponentiation on ciphertext, and the time-saving but repetitive operation, i.e., distance calculation. Note that we ignore the constant permutation operations in Table 1. To be more intuitive, the setup phase and query phase are considered separately.

Setup phase. In the setup phase of all our four query protocols, $\mathcal{S}$ and $\mathcal{C}$ jointly run the $\mathsf{PFGen}$ protocol where both $\mathcal{S}$ and $\mathcal{C}$ need $(n_s+n_c)$ exponentiation operations modular $n=2^{\lambda }$, which is much faster than the modular $n^2$. In addition, $\mathcal{S}$ needs two permutations and $\mathcal{C}$ needs one permutation, both of which can be ignored. It is a small cost compared to the client-based protocols RNNC/C, AVGD/C and MAXD/C, where the client $\mathcal{C}$ needs to execute $\tilde{n}$ encryptions. Although the setup phase is very simple in server-based protocols RNNC/S, AVGD/S and MAXD/S, it will bring a great amount of computation cost to $\mathcal{C}$ in the query phase.

Query phase. In the query phase, for our RNNC, AVGD and MAXD query protocols, the computation processes of $\mathcal{S}$ are similar—$n_s·k$ distance calculations, $n_s$ encryptions and 1 decryption for both the AVGD query and MAXD query, and due to the dimension issue of matrix $\mathbf{M}$, $n_s·k$ distance calculations, $n_s·k$ encryptions and k decryptions for the RNNC query. The main operations of $\mathcal{C}$ take place in Step 6—$n_I·k$ multiplications on the cipher and k encryptions for RNNC, $n_I$ multiplications on the cipher and one encryption for AVGD, one multiplication on cipher and one encryption for MAXD. In addition, for AVGD, $\mathcal{C}$ needs to execute one division in Step 8. For our RNNC-CMC protocol, we further reduce the computational complexity after the distance calculations to $1/k$ times of our original RNNC protocol for both $\mathcal{S}$ and $\mathcal{C}$.

From the analysis results, since we avoid the use of a superset with the very large cardinality $\tilde{n}$ (no “$\tilde{n}$ enc” operations in our schemes), we have completely avoided a large number of homomorphic encryption operations on both the server and client-sides and the corresponding computational complexity has been reduced. Further, we avoid a big number $w>max$ in the MAXD query protocol, resulting in a reduction of a large number of exponentiation and encryption operations. In addition, we further reduce the parameter k to $\lceil k/\eta \rceil$ in the improved protocol RNNC-CMC.

For communication cost, we give the final result directly as follows, which is between those of the server-based protocols and the client-based protocols in [3].

(1) RNNC: $O(n_s·k)\times$ size of the block of cipher;

(2) AVGD: $O(\frac{3}{2}{n}_s+n_I)\times$ size of the block of cipher;

(3) MAXD: $O\left(\frac{3}{2}{n}_s\right)\times$ size of the block of cipher;

(4) RNNC-CMC: $O(n_s·(\lceil k/\eta \rceil +\frac{1}{2}))\times$ size of the block of cipher.

In summary, the proposed aggregate query protocols are comprehensively ahead of the server-based protocols and have advantages and disadvantages in some aspects compared with the client-based protocols.

8.2. Experimental Results

We implement all our protocols in Python 3.7 with a 64-bit Windows 10 system, 3.20 GHz Intel Core i5 processor and 16 GB RAM. We choose the security parameter $\lambda =1024$, and set $n_c$ = 20,000 and $\tilde{n}$ = 1,000,000, the same values as in [3] for reasonable comparisons (We do not emphasize that we use the real-world dataset [31], because whether the location data are real or randomly selected has no effect on our experimental results, and without considering differential privacy, real-world datasets are meaningless for efficiency tests. In fact, the results of the experiments (the trends of the lines in Figure A1 and Figure A2) on real and unreal location datasets are exactly the same). In addition, we suppose $n_I=n_c$ in our experiment. First, for the three types of queries—RNNC, AVGD and MAXD, we fix the value $n_s$ = 100,000 and test the computation costs of our protocols and those of the previous along with the change of k. Then, we fix the value $k=50$ and test the computation costs along with the change of $n_s$. For our RNNC-CMC protocol, we set the threshold $\alpha =16$, which is enough for the general RNNC query (each $q_i$ is no more than $2^{16}-1$ = 65,535), and accordingly, $\eta =64$.

Since the server and the client may have different scales of computing power in a real environment, we test the cost of the server and the cost of the client separately and give their lines in figures. Our experimental results are given in Figure A1 and Figure A2 in Appendix A.

There are two different types of exponentiation operations in our experiments. The first one is the exponentiation modular $n^2$ (2048 bits) executed on the client-side of MAXD/S and the server-side of AVGD/C and MAXD/C. The second one is the exponentiation modular n (1024 bits) executed in the setup phase (jointly running $\mathsf{PFGen}$ protocol) of our four protocols. Note that the time cost of modular exponentiation operation is very unstable when the exponent changes, and we know that computing $a^x$ costs the equivalent of ${log}_{2}x$ multiplications by using the fast exponential algorithm. Therefore, we use the mathematical expectation instead of the unstable value. Suppose an exponent is a b-bit number, the expectation of equivalent times of multiplications can be calculated as $\mathrm{E}\left(t\right)=\frac{{\sum }_{x=0}^{2^b-1}t\left(x\right)}{2^b}\approx \frac{{\int }_1^{2^b}{log}_{2}xdx}{2^b}\approx b-1$. Therefore, we use $(b-1)\times$ the time of 1 multiplication instead of 1 exponentiation to draw the figures to clearly show the trend of change. Moreover, according to our test, the time cost of the 1024-bit modular exponentiation operation is a little smaller than a quarter of that of the 2048-bit.

From the experimental results, we give what we see for reference as follows.

(1) For the RNNC query, our protocols (RNNC and RNNC-CMC) are more efficient than RNNC/S protocols on both the client-side and the server-side, and not as efficient as the RNNC/C protocol but acceptable (Our protocols avoid a lot of encryption operations in the setup phase compared to client-based protocols (RNNC/C, AVGD/C and MAXD/C). The price of the client-based protocols being faster than ours in some cases (on the client-side for RNNC and AVGD queries, and on the server-side for RNNC and MAXD queries) is that a lot of calculations are transferred to the setup phase. In addition, taking note of the multiples of the time cost comparisons in (1), (2) and (3), $\frac{1}{80}$ and $\frac{1}{25}$ are non-ignorable values, but 0.24 s (in our experimental environment) to the client and hundreds of seconds (in our experimental environment) to the server are actually very small values). Concretely, taking $k=50$ and $n_s$ = 100,000, on the client-side, our RNNC-CMC protocol is (0.24 s) 50× faster than the RNNC/S protocol, and $\frac{1}{3}$× faster than the RNNC/C protocol; on the server-side, our RNNC-CMC protocol (407.47 s) is 620× faster than the RNNC/S protocol, and $\frac{1}{80}$× faster than the RNNC/C protocol.

(2) For the AVGD query, on the client-side, the time cost of our AVGD protocol is between that of the AVGD/S protocol and AVGD/C protocol. However, on the server-side, our protocol is much more efficient than the previous two, and it is valuable that our query protocol reduces the rate of increase in the time cost of the server when $n_s$ increases (Figure A2-AVGD Query). Concretely, taking $k=50$ and $n_s$ = 100,000, on the client-side, our AVGD protocol is (0.24 s) 2× faster than the AVGD/S protocol, and $\frac{1}{80}$× faster than the AVGD/C protocol; on the server-side, our AVGD protocol is (508.46 s) 20× faster than the AVGD/S protocol, and 5× faster than the AVGD/C protocol. In addition, when $n_s$ increases to 500,000, our AVGD protocol is (2542.30 s) 4× faster than the AVGD/S protocol, and 5× faster than the AVGD/C protocol on the server-side.

(3) For the MAXD query, our protocol is friendly to a resource-limited client compared with the two previous protocols. It is more than one magnitude faster than the client-based protocol MAXD/C. Moreover, on the server-side, the time cost of our MAXD protocol is between that of the MAXD/S protocol and MAXD/C protocol. Concretely, taking $k=50$ and $n_s$ = 100,000, on the client-side, our MAXD protocol is (0.0051 s) 26,000× faster than the MAXD/S protocol, and 15× faster than the MAXD/C protocol; on the server-side, our MAXD protocol is (508.46 s) $5000\times$ faster than the MAXD/S protocol, and $\frac{1}{25}$× faster than the MAXD/C protocol.

9. Conclusions

In this paper, we have studied the aggregate queries for facility location selection between an LSP and a business with confidentiality. We proposed the construction of a PSI filter to help two parties find the relevant data corresponding to the items in the intersection without revealing the privacy of the items, including those in the intersection. Then, for location data analysis, we utilize our PSI filter to construct three types of aggregate query protocols without setting a superset of a large size for concealing the user identities and serving as an index. Moreover, we propose a ciphertext matrix-compressing method that makes one ciphertext block contain multiple small plaintext data while keeping the homomorphic property valid, and, subsequently, we give the improved protocol by utilizing this method. It further raises the efficiency of both computation and communication on the basis of the original query process. Finally, we illustrate the correctness and privacy and give the performance evaluation through theoretical analysis and experiments that show the superiorities of our protocols.