1. Introduction
Data breaches in online social networks (OSNs) affect billions of individuals and raise critical privacy concerns across the entire society (Liang et al., 2015; Information is Beautiful, 2018). Besides, driven by the demands on huge storage and computation resources, OSN service providers utilise public commercial clouds as their backend data storage (AWS, 2018a, b; Engineering, 2018), which further broadens the attack plane (Ren et al., 2012). Therefore, there is an urgent call to improve the control of data confidentiality for cloud providers (Yang et al., 2016; Liu et al., 2016; Li et al., 2016), in particular for current OSN services. The prevailing consensus to prevent data leakage is encryption. However, this approach impairs the functionality of social search, a key enabler for quality OSN services (Sullivan, 2012). Social search allows users to search content of interests created by their friends. Compared with traditional web search, it produces personalised search results and serves for a wide range of OSN services such as friend discovering and user targeting.
The first task to enable privacypreserving social search is how to scalably query over very large encrypted social graphs. On the one hand, a typical social graph can contain millions or even billions of users. On the other hand, users may generate large volume of contents which will be queried for social search related services (Curtiss et al., 2013). The second and more challenging task is how to realise complex social search queries in an efficient and secure manner. As developed in plaintext systems (e.g., Facebook’s Unicorn (Curtiss et al., 2013)), queries of social search contains set operations on graphstructured data, and the retrieved contents from the graph need to further be analysed (e.g., aggregation and sorting) for advanced services such as friendshipbased recommendation.
In the literature, some work (Nayak et al., 2015; Blanton et al., 2013) leverages generic building blocks (e.g., garbled circuits and oblivious data structures) to devise secure computational frameworks for graph algorithms. However, those frameworks do not appear to be scalable for low latency queries over large graphs. For example, a recent garbled circuits based framework (Nayak et al., 2015) takes several minutes to complete a sorting algorithm over a graph with only tens of thousands of nodes. Other work focuses on dedicated privacypreserving graph algorithms, e.g., neighbour search (Chase and Kamara, 2010; Kamara et al., 2018), and shortest distance queries (Xie et al., 2016; Meng et al., 2015; Wu et al., 2016; Wang et al., 2017). Unfortunately, the above algorithms are limited for or different from the functionality of social search queries.
Contributions. To bridge the gap, in this paper, we propose and implement GraphSE^{2}, the first encrypted graph database that supports privacypreserving social search. Unlike prior work which either suffers from low scalability or limited functionality, GraphSE^{2} enables scalable queries over very large encrypted social graphs, and preserves the rich functionality of the plaintext social search systems. Our contributions can be summarised as follows:

[leftmargin=*]

We propose an encrypted and distributed graph model built on social graph modelling, searchable encryption, and the data partition technique. It facilitates queries over encrypted graph partitions in parallel, and maintains the locality of graph data and usergenerated contents for low query latency.

We devise mixed yet interchangeable protocols to enable complex social search functions. The way of doing this is to decompose queries into atomic operations (i.e., set, arithmetic, and sorting operations) and then adapt suitable cryptographic primitives for efficient realisation. All these operations are tailored to be executed in parallel.

We realise query operators of the Facebook’s social search system Unicorn (Curtiss et al., 2013), i.e., term, and, or, difference, and apply. We also design a query planner that can parse a query to atomic operations and initiate the corresponding primitives.

We formally prove the security of our proposed query protocols under the real and ideal paradigm. Queries, graph data, and results are protected throughout the query process.

We show the practicality of GraphSE^{2} by implementing a prototype which is readily deployable. It leverages Spark (Zaharia et al., 2010) for setup (data partition and encryption), Redis (Redis Labs, 2017) as the storage backend, and uses Apache Thrift (Slee et al., 2007) to implement the query planner and query processing logic.
Our comprehensive evaluation on the Youtube dataset (Mislove et al., 2007) with 1 million nodes confirms that all atomic operations are of practical performance. For set queries, GraphSE^{2} retrieves a content list with entities within ms. For an average user ( friends), GraphSE^{2} takes at most ms if the set operation involves two indexing terms (attributes); and it takes no more than ms for five indexing terms. Regarding the computational operations, GraphSE^{2} takes ms to handle arithmetic computations over entities, and ms to sort entities. As a summary, most of the queries for an average user are processed within s, and throughput is reduced at most compared to the plaintext queries.
Organisation. The rest of this paper is structured as follows. We discuss related work in Section 2. After that, we describe the system overview in Section 4, and present the encrypted and distributed graph data model and the design of atomic operations in Section 5. In Section 6, we introduce the realisation of privacypreserving social search queries and their security. Next, we describe our prototype implementation in Section 7, and evaluate the performance in Section 8. We give a conclusion in Section 9.
2. Related Work
Privacypreserving graph query processing. There exist various designs that aim to answer a certain type of queries over the encrypted graph. Structured encryption (Chase and Kamara, 2010) is proposed in the framework of SSE and supports adjacency and neighbouring queries. Some recent work is proposed to support privacypreserving subgraph queries (Cao et al., 2011; Chang et al., 2016). However, all the above designs enable limited query functionality. Another line of work on privacypreserving graph processing is to perform shortestpath queries over the encrypted graph. Protocols for this type of queries are devised via oblivious RAM (Xie et al., 2016), structured encryption (Meng et al., 2015), or Garbled Circuit (Wu et al., 2016; Wang et al., 2017). To implement more complicated algorithms, protocols are proposed to use secret sharing and homomorphic encryption for Breadthfirst search (BFS) (Blanton et al., 2013), PageRank (Xie and Xing, 2014), and approximate eigendecomposition (Sharma et al., 2018). We stress that the above work targets on different query functionality other than social search. Note that a recent framework named GarphSC (Nayak et al., 2015) can generate dataoblivious Garbled Circuit (GC) for graph algorithms such as PageRank and Matrix Factorisation. Because oblivious data structures are adapted for large graphs and all computations are realised via GC, it does not appear to achieve low latency for social search queries.
Encrypted database system. Our system is also related to encrypted database systems (Popa et al., 2011; Pappas et al., 2014; Poddar et al., 2016; Papadimitriou et al., 2016; Yuan et al., 2017). CryptDB (Popa et al., 2011) is the first practical encrypted database system, which is built on propertypreserving encryption (PPE). It supports SQL queries over encrypted relational data records. BlindSeer (Pappas et al., 2014) proposes a Bloom Filter based index and leverages GC to evaluate arbitrary boolean queries with keywords and ranges. Arx (Poddar et al., 2016) follows the design of CryptDB to support SQL queries, but it uses SSE and GC to reduce the leakage from PPE. Seabed (Papadimitriou et al., 2016)
uses additively symmetric homomorphic encryption (ASHE) to perform efficient aggregation over the encrypted data, and develops a schema with padding to mitigate the inference attack
(Naveed et al., 2015). EncKV (Yuan et al., 2017) adapts SSE and ORE schemes to design an encrypted and distributed keyvalue store. However, all the encrypted databases mentioned above are neither designed for graph data nor optimised for social search.Graph processing system. In the plaintext domain, a large number of graph processing systems (Low et al., 2012; Curtiss et al., 2013; Chi et al., 2016) (just to list a few) are proposed to support efficient large graph processing. However, all the above systems only support queries over the graphs in unencrypted form, which are unable to address privacy concerns of sensitive data leakage. Authenticated graph query (Goodrich et al., 2011) is proposed to verify the correctness of graph queries, which could be a complementary work to prevent attacks from malicious adversaries.
3. Background
3.1. Social Graph Model
The social graph consists of nodes (aka entities) and edges (aka relationships of entities) in social networks. As the social graph is a sparse graph (Curtiss et al., 2013), it is normally represented via a set of adjacency lists. Like (Curtiss et al., 2013), we refer to these adjacency lists as posting lists.
Formally, the social graph is an edgelabeled and directed graph , where is the entity set and is the relationship set. Each posting list contains a list of entities , which are (sortkey, ) pairs. The sortkey is an integer that indicates the importance of the entity in a posting list, and the is its unique identifier.
The posting lists are indexed by the inverted index, and modelled by the edges in social graph: All edges in can be represented as a triad which consists of its egress, ingress nodes () plus an edgetype which is a string representing the relationship between nodes (e.g., friend, like). The inverted indexing term is in the form of . For example, the user may use to get the posting list of user ’s friends.
3.2. Oblivious CrossTags () Protocol
Oblivious CrossTags () Protocol (Cash et al., 2013) is an SSE protocol, which proceeds between client and server . It provides an efficient way to perform conjunctive queries in encrypted database^{1}^{1}1The scheme proposed in (Kamara and Moataz, 2017) supports disjunctive queries, but it consumes large storage space.. Here we provide a highlevel description as needed for the basic operations of our proposed system.
The protocol has two types of data structures. Firstly, for every keyword , an inverted index, referred as ‘’, is built to point to the set of all entity identifiers s associating with . Each is identified by an indexing term called , and all values in are encrypted via a secret key . Both and are computed as a applied to with ’s secret keys. Another data structure called ‘’ is built to hold a list of hash values (called ’’) over all entity identities and keywords contained in , where is a certain (public) cryptographic hash function. The above two data structures are stored on the serverside.
To search a conjunctive query with keywords, sends the ‘search token’ related to (called ‘sterm’, we assume it to be in the above query) to , which allows the server to run and retrieve from the . In addition, sends ‘intersection tokens’ (called ‘xtraps’) related to the keyword pairs consisting of the ‘sterm’ paired with each of the remaining query keywords , (called ‘xterms’). The xtraps allow the server to evaluate the cryptographic hash function of pairs without knowing either keyword or . checks the existence of in and filters the to subsets of entities that contain the pairs . It only returns the entities that contain all to the client. finally uses to recover the s of entities.
As mentioned in (Cash et al., 2013), the security of parameterised by a leakage function . It depicts what an adversary is allowed to learn about the database and queries via executing
protocol. Informally, considering a vector of queries
, which consists of a vector of sterms , a vector of boolean formulas , and a sequence of xterm vectors . After executing in a chosen database , the adversary only can learn:
[leftmargin=*]

: The total number of pairs.

: The boolean formulae that the client wishes to query.

: The repeat pattern in .

: The size of posting lists for .

: The number of xterms for each query.

: The set of result matching each pair of (sterm, xterm)conjunction which is in the form .

: The set of result both existing in the posting lists of and , which is only revealed when two queries have different sterms but same xterms.
3.3. Secure Computation
Additive Sharing and Multiplication Triplets. To additively share () an bit value , the first party generates uniformly at random and sends to the second party . The first party’s share is denoted by and the second party’s is , the modulo operation is omitted in the description later. To reconstruct () an additively shared value in , sends to who computes . Given two shared values and , Addition () is easily performed noninteractively. In detail, locally computes , which also can be denoted by . To multiply () two shared values and , we leverage Beaver’s multiplication triplets technique (Beaver, 1991). Assuming that the two parties have already precomputed and shared , and , where are uniformly random values in , and . Then, computes and . Both parties run and to get , and lets .
Garbled Circuit and Yao’s Sharing Yao’s Garbled Circuit (GC) is first introduced in (Yao, 1982), and its security model has been formalised in (Bellare et al., 2012). GC is a generic tool to support secure twoparty computation. The protocol is run between a “garbler” with a private input and an “evaluator” with its private input . The above two parties wish to securely evaluate a function . At the end of the protocol, both parties learn the value of but no party learns more than what is revealed from this output value. In details, the garbler runs a garbling algorithm to generate a garbled circuit and a decoding table for function . The garbler also encodes its input to and sends it to the evaluator. The evaluator runs an oblivious transfer (OT) (Asharov et al., 2013) protocol with the garbler to acquire its encoded input . Finally, the evaluator can compute from , decode it with , and share the result with the garbler. The security proof against a semihonest adversary under twoparty setting is given in (Lindell and Pinkas, 2009).
In the following parts, we assume that is the garbler and is the evaluator. GC can be considered as a protocol which takes as inputs the Yao’s shares and produces the Yao’s shares of outputs. In particular, the Yao’s shares of 1bit value is denoted as and , where are the labels representing and , respectively. The evaluator uses its shares to evaluate the circuit and gets the output shares (another labels).
Additive shares can be switched to Yao’s shares efficiently. To be more precise, two parties secretly share their additive shares , in bitwise via Yao’s sharing. The evaluator then receives and and evaluates the circuit to get the label of .
4. System Overview
4.1. System Architecture
As shown in Figure 1, GraphSE^{2} has two entities: the onpremise social search service frontend () and the index server cluster () with several index servers (s) in an untrusted cloud. Note that this setting is consistent with many offtheshelf social network service providers such as Airbnb (AWS, 2018a) and Instagram (Engineering, 2018), who use cloud data storage as the backend to manage large graphs and massive usergenerated data contents. Also, such architecture is now natively supported by public clouds, e.g., AWS Outposts (AWS, 2018c). GraphSE^{2} aims to improve the protection of data confidentiality at the backend, which is usually the highvalue target for adversaries in practice.
During the setup phase, partitions the social graph to disjoint subgraphs and builds two instances of SSE indexes of each subgraph for the queries on structured information. The generated indexes are uploaded to two noncolluded s with multiple s respectively. The sortkeys are colocated with the corresponding indexes in the form of additive shares on the above two s for the arithmetic operations and sorting. Specifically, each has one of the two additive shares, and it pairs with a counterparty in the other cluster, which maintains the same index but holds the other share. Upon receiving a query from its users, uses a query planner to parse the query into atomic operations (see Section 5.3) to generate a query plan. It then sends the query tokens of atomic operations to all s to execute the query plan. After that, each requests the structured information via the tokens. Based on the matched encrypted contents, it executes arithmetic operations and scoring/ranking algorithms with its counterparty. Finally, the encrypted result is returned to .
In this architecture, we consider a scenario of secure computation sourcing where the inhouse assigns the computation to the s in two untrusted but noncolluding clusters and . Such a model of secure multiparty computation is formalised in (Kamara et al., 2011) and applied in many existing studies (Nikolaenko et al., 2013; Baldimtsi and Ohrimenko, 2015; Mohassel and Zhang, 2017). Built on this model, GraphSE^{2} offers two advantages: (i) is not required to be involved with any computation after it distributes the data to the servers, and (ii) the computation process can benefit from the mixture of multiparty computation protocols that enable efficient arithmetic operation, comparison, and sorting at the same time. Note that the communication between s will not be the system bottleneck, because s can be deployed in cloud clusters with dedicated datacenter networking support. This is consistent with prior studies based on the same architecture (Mohassel and Zhang, 2017).
Query operator  Example(from (Curtiss et al., 2013))  Atomic operations  
Index Access  Set Operations  Arithmetic  Sorting  
term  (term friend:1)  
and  (and friend:1 friend:2)  
or  (or friend:1 friend:2)  
difference  (difference friend:3 (and friend:1 friend:2))  
apply  (apply friend: friend:1) 
4.2. Highlevel Description
Before introducing the details of our system, we elaborate on the design overview and underlying design intuitions. To query large social graphs, GraphSE^{2} develops an encrypted and distributed graph model. It is built on graph modelling, searchable encryption, and the standard data partition algorithm. Each server evenly stores an encrypted disjoint part of the whole graph. Meanwhile, this model is designed to colocate the encrypted contents with the disjoint part containing the users who generate or relate to the contents. As a result, GraphSE^{2} not only maximises the system scalability but also preserves data locality for low query latency.
To facilitate the realisation of various social search queries in the encrypted domain, GraphSE^{2} first splits these complex queries into two stages, i.e., content search over the structured social graph and computational operations on the retrieved contents. Within the above stages, queries are further decomposed into atomic operations, i.e., Index Access, Set Operations, Arithmetic operations, and Sorting. Since the first stage commonly performs set operations over the social graph, GraphSE^{2} realises our proposed graph model via a wellknown searchable encryption scheme for boolean queries (aka OXT (Cash et al., 2013)). The second stage requires a combination of different computations to further analyse user contents. For example, collaborative filtering (Breese et al., 1998) first obtains the scores of user contents via several addition and multiplication operations and then sorts the scores for an accurate recommendation.
To accelerate sophisticated computations in the second stage, GraphSE^{2} mixes different secure computation protocols. Note that such philosophy also appears in recent privacypreserving computation applications (Demmler et al., 2015; Mohassel and Zhang, 2017). Unlike prior work, GraphSE^{2} customises the mixed protocols for social search queries and adapts them to our distributed graph model. In particular, GraphSE^{2} represents the importance (score) of usergenerated contents as the additive shares and deploys two distributed instances at two noncolluded server clusters to store both the graph partitions and corresponding shares respectively. Doing so allows GraphSE^{2} to support parallel and batch addition and multiplication without the interaction between servers^{2}^{2}2Multiplication involves a round of interaction between two servers, but they are in the same partition of two clusters.. To achieve fast sorting, GraphSE^{2} first converts additive shares to Yao’s shares inside garbled circuits (GC) and then invokes a tailored distributed sorting protocol via GC. Each pair of servers in two clusters can perform local sorting in parallel, and then the intermediate results are aggregated for global sorting. Within the protocol, the underlying scores are hidden against servers from either of the two parties.
4.3. Threat Assumptions
In this work, we assume that is a private server dedicatedly maintained by the OSN service provider. It is a trustworthy party in the proposed model. Similar to the realworld OSN service provider (e.g. Airbnb), all users should submit their queries to through webpages or mobile apps. We assume that utilises the secure channel and cryptographic techniques to protect users’ secrets. On the other hand, we assume that all s are located in the untrusted domain. Meanwhile, we consider that the two clusters are semihonest but not colluding parties. Each cluster performs social search faithfully but intends to learn additional information such as query terms, result s and ranking values from the graph. Besides, those clusters hold user data and perform query functions, and thus they are highvalue targets of adversaries. We assume that the two clusters can be compromised by two different passive adversaries, but the two adversaries will not collude. GraphSE^{2} aims to protect the confidentiality of the private information in the social graph when the data storage backend of the social search service is deployed at an untrusted domain.
4.4. Query Operators
GraphSE^{2} follows a typical plaintext social search system (Curtiss et al., 2013) to define the operators (see Table 1).
In general, all operators in GraphSE^{2} aim to retrieve posting lists from the encrypted graph index. The simplest form of these operators is term, which retrieves a single posting list via an Index Access operation. Like the other social search system, GraphSE^{2} also supports and and or operators, which yield the intersection and union of posting lists via Set Operations respectively. In addition, it supports difference operator, which yields results from the first posting list that are not present in the others. Moreover, GraphSE^{2} supports the unique query operator of Unicorn system (Curtiss et al., 2013), i.e., apply. The operator allows GraphSE^{2} to perform multiple rounds of posting list retrieval to retrieve contents that are more than one edge away from the source node.
To enable quality search services (e.g., friendshipbased recommendation), the retrieved posting lists should be scored/ranked before returning to users. As mentioned in Section 4, the additive shares of sortkeys are stored with its indexes. As a result, most of the query operators (e.g., term, and, difference and or) can use these shares to perform Sorting on the retrieved contents. Furthermore, it is often useful to return results in an order different from sorting by sortkeys. For instance, collaborative filtering (Breese et al., 1998) evaluates an arithmetic formula about friendships and ratings on items to produce the personalised scores for recommended items. The new score is a better prediction than the sortkeys, as the later only reflects the overall preference in the community (e.g., the hitcount on the item). The defined operators natively support arithmetic computations via the additive shares affixed with indexes. Specifically, apply operator has the capability to support the secure evaluation on complicated scoring formulas with Arithmetic operations: It can access different types of entities (e.g., user’s friends, items liked by users, etc.) in a multiple roundtrip query, which means it can combine the scores of different entities and cache the intermediate result for next round computations.
Notation  Meaning 

the unique identifier of entity  
the encrypted entity  
an indexing term in the form of  
an inverted indexed database  
a list of indexed by  
the encrypted posting list with pairs  
the th party in GraphSE^{2} ()  
a numerical value  
a matrix  
the Additive/Yao’s share of a numerical value in  
the Additive/Yao’s share of a matrix in  
a garbling scheme 
5. The Proposed System
We give a list of needed notations in our system construction and security analysis in Table 2. The detailed definitions of preliminaries we used are given in Section 3.
5.1. Encrypted Graph Data Model
To support social search operations in (Curtiss et al., 2013) on an encrypted social graph (see Section 3.1 for details), GraphSE^{2} creates the OXT index (i.e., and , see Section 3.2 for details) for encrypted graph structure access in s, and the additive shares are integrated with the corresponding index to support complex computations. Specifically, to support simple graph structure data access, each posting list is encrypted and stored as a tuple in the : . The tuple consists of the of indexing term as the key and the encrypted posting list as the value. Each element in is an encrypted tuple , which keeps the encryption of entity . Additionally, the sortkey of entity is shared as additive sharing value. GraphSE^{2} associates it with the encrypted entity to support complex computations. Moreover, GraphSE^{2} evaluates the cryptographic hash function of pairs to generate an for complex set operations.
5.2. Encrypted and Distributed Graph Index
In order to support the system to process the query in parallel, GraphSE^{2} distributes the encrypted graph across multiple index servers for each cluster.
GraphSE^{2} devises a partition strategy that shards the posting lists by hashing on result . Figure 2 gives an example of the proposed partition strategy in an with two s. We employ a modulo partition strategy, which split the original posting list into multiple nonduplicate parts, but other graph partition strategies (e.g., (Low et al., 2012)) can also be applied to shard the social graph. The design has three advantages in the context of distributed environment. First, it maintains the availability in the event of server failure. Furthermore, the sharding strategy enables the distributed system to finish most of the set operations and the consequent scoring, ranking and truncating in s. It splits the computation loads into distributed servers to improve the efficiency and also cuts down the communication cost between s and . Finally, it does not affect the security of GraphSE^{2} because the adversary who compromises an gets the same view (the whole encrypted database) as the adversary in a single instance. If the adversary cannot access all s in the , only the view on a fraction of the encrypted database is learned..
5.3. Atomic Operations
As mentioned in Section 4.4, the social search queries are implemented by a set of operators. We observe that these operators can be decomposed to a set of atomic operations. We now describe the implementation of these atomic operations in the encrypted domain. For each atomic operation, we explain how we adapt and optimise it in the proposed system.
5.3.1. Index Access
We start with Index Access operation, which is used to retrieve the neighbouring nodes of the target user with the given edgetype (e.g., friend, likes) from the social graph. Algorithm 1 outlines the searching procedure using operations. On receiving the search keyword, firstly generates a search token , which is of the indexing term . can use to search and get the encrypted posting list as the return. Index Access operation can be easily extended to run in parallel. More specifically, broadcasts search token to all s. After that, each uses to get its local partition of the whole encrypted posting list and sends it back.
Security. The security of Index Access is guaranteed by the security property of . Informally, Index Access is semanticallysecure against adaptive attacks where is the leakage function of . is welldefined and discussed in (Cash et al., 2013). It ensures Index Access only leaks the number of edges in the encrypted social graph.
5.3.2. Set Operations
This operation involves the boolean expression with multiple indexing terms. GraphSE^{2} uses it to query the encrypted graphstructured data and finds the neighbouring nodes and the corresponding usergenerated content that satisfy the given boolean expression. In GraphSE^{2}, we adapt protocol to support this atomic operation, but some of the other SSE protocols supporting conjunctive queries (e.g. (Lai et al., 2018)) can also be readily adapted as the building block of GraphSE^{2}. The protocol supports conjunctive queries of the form natively, but it can be extended to support the boolean query of the form , where is the ‘sterm’, and is an arbitrary boolean expression (Cash et al., 2013). As shown in Algorithm 2, the extended protocol follows the basic steps to obtain search tokens and search in and interactively. Nevertheless, it introduces additional steps (line 3, 13, 15–17 in Algorithm 2) to solve the boolean expression . Specifically, substitutes all indexing terms to boolean variables () and generates a boolean function . then sends to . sets the value of to the truth values of . Then, it evaluates and returns as a result if outputs true.
The algorithm can be utilised to enable set operations of social search queries as shown in Table 1, which will be discussed in the following section.
Security. In cryptographic terms, the protocol is proved to be semanticallysecure against adaptive attacks, where is the leakage function defined in (Cash et al., 2013). It ensures that the untrusted server only learns the information defined in the leakage function, but no other information about the query and underlying dataset. We refer the reader to Section 3.2 for more details.
5.3.3. Arithmetic
GraphSE^{2} uses Arithmetic operations to support complex scoring functions over the retrieved content from Set Operations. Arithmetic operations in GraphSE^{2} involve the secure twoparty computation between two s. Here, we introduce the simplest model of GraphSE^{2}, where each only has one , for ease of presentation on how to use additive shares (see Section 3.3 for detailed definition) to compute addition and multiplication under twoparty setting. Note that this model can be extended to support multiple pairs of s.
In GraphSE^{2}, the posting list is generalised as a matrix and the arithmetic operations are evaluated over the matrix. The reason for that is, instead of running the scoring function with arithmetic operations multiple times for each item of the posting list, the batch processing can reduce the system overhead and support scoring algorithms in parallel. We denote the matrix of sortkeys returned from a structured information query by , and the corresponding shared matrix is denoted by . Given two shared matrices and , the addition operation () can be evaluated noninteractively by computing in each party. To multiply two shared matrices (), two s generate the multiplication triplets, which are shared matrices: . has the same dimension as , has the same dimension as , and . computes and , and sends it to its counterparty. Both parties then recover and let .
The multiplication operation relies on the triplets, which should be generated before the actual computation. In addition, each party keeps their in secret during the generation process, otherwise, they can recover after two parties exchanged . Thus, GraphSE^{2} introduces a secure offline protocol (Mohassel and Zhang, 2017) to generate the triplets via OT, it utilises the following relationship: to compute the shares of . The resulting offline protocol is only required to compute the shares of and as the other two terms can be computed locally.
We illustrate the computing process of in the offline protocol. The basic step of the offline protocol is to use and a column from to compute the share of their product. This is repeated for each column in to generate . Therefore, for simplicity, we focus on the above basic step: We assume that the size of is and we denote each element in as , and . In addition, we assume each column of has elements, which are denoted as , . The computation process is listed as follows:

[leftmargin=*]

runs a correlatedOT protocol (COT) (Asharov et al., 2013), and sets the correlation function to for .

For each bit of , chooses a random value for each bit and runs with .

If , gets ; If , gets . It is equivalent to get in side.

sets , and sets .
After computing , the th element of the th row in is . Analogously, and can compute the share of in the same way.
Security. Additive sharing scheme offers security guarantees to Arithmetic operations in GraphSE^{2} via its computational indistinguishable property. More specific, as discussed in (Pullonen et al., 2012)
, the scheme can create a uniformly distributed input and output to protects the original input/output of
Arithmetic operation under the threat model of GraphSE^{2}, i.e., semihonest but noncolluding twoparty.5.3.4. Sorting
This is a required operation in order to rank the computed scores from Arithmetic operations. A naive solution is to recover all scores from additive shares in and sort them as plaintext. However, transmitting all rank results to is a bandwidthconsuming task, the sort operation can be very inefficient as the result. Therefore, GraphSE^{2} chooses to mix the additive sharing scheme and Yao’s Garbled Circuit (see Section 3.3 for details) to support arithmetic operations and comparison at the same time, as it avoids the communication overhead from sending the shares back to . To protect the privacy of score values, the generated circuit should have a fixed sequence of comparison for a given size of inputs (i.e., achieving the traceoblivious), and it should not reveal the actual scoring value after circuit evaluation.
Local Sorting. To enable sorting on s, GraphSE^{2} leverages an efficient scheme in (Demmler et al., 2015) to switch from additive sharing to Yao’s sharing. It then adopts the sorting network (Batcher, 1968) to generate the optimised sorting circuit. Finally, the garbler concatenates the sorting network with an XOR gate and applies a random mask to mask the score values. As a result, the evaluator can use decode table to figure out the rank, but it does not know the score values. Thus, the local sorting algorithm in GraphSE^{2} can be divided into five phases. Figure 3 illustrates the process of local sorting.
Given as the garbler and as the evaluator, both parties preshare a scoring vector , GraphSE^{2} runs the protocol to sort the vector and returns a sorted vector in descending order of , the protocol can be summarised as follows:

[leftmargin=*]

Phase 1: runs to generate the circuit in Figure 3 as well as its decode table . It then sends the circuit and the decode table to . Doing so ensures that only can see the final result with random mask .

Phase 2: sends the encoded inputs of its additive shares with a payload vector indicating the position. This prevents from learning the additive shares of .

Phase 3: retrieves the encoded inputs of its additive shares and payload vector from via OT protocol. This prevents from learning the additive shares of .

Phase 4: generates the encoded input of a random mask to perform the last XOR gate to protect the vector.

Phase 5: uses the given inputs to evaluate the circuit, and uses to decode the outputs.
Since the circuit puts a mask after sorting, only gets the ranking without knowing the actual scores.
Global Sorting. The above sorting strategy is a suitable and efficient solution for the simplest model, i.e., only one in each . However, it can be problematic when each has several s. In this case, no can provide a full sorted list as each only has a disjoint part of the whole graph. Hence, still needs to perform another inefficient plaintext sorting.
Therefore, GraphSE^{2} uses a specific protocol which runs by a chosen coordinator of each . The protocol can perform an extra round of sorting upon the results from local sort while keeping the scoring value in secret. Assuming that each has different s, and are chosen to be the coordinators for and , respectively. After local sorting, evaluator in sends a vector of masked scoring values where and to and garbler in sends the masks to . In the global sorting, GraphSE^{2} switches the roles of and (i.e., is the garbler, and is the evaluator) for two reasons: It prevents from evaluating two circuits at the same time, as also needs to evaluate another local sorting circuit for its partition. Furthermore, it facilitates pipeline data processing. The partial result of each can be sent to and for global sorting separately. Once the and get the first result, they can start to run encoding and OT. The protocol is summarised as follows:

[leftmargin=*]

Phase 1: runs to generate the circuit in Figure 4 and the decode table . It then sends the circuit and to .

Phase 2: sends the encoded inputs where and with a payload vector .

Phase 3: retrieves encoded masks via OT protocol.

Phase 4: uses the given inputs to evaluate the circuit, and uses to decode the outputs. The result is sent to in descending order.
Security. The security properties of Garbled Circuit (Bellare et al., 2012) and OT (Asharov et al., 2013) ensure the security of Sorting in GraphSE^{2} in the following three aspects: Firstly, no adversary can learn the input of its counterparty when sorting (i.e., the other additive share in and the masked score/mask in ). Secondly, the output of is masked by a onetime mask, which is a uniformly random number. It protects the original score vector because the evaluator only learns the masked values from output. Finally, for the output of , only the decode table of rank is sent to the evaluator, which also ensures that the evaluator only learns global rank without knowing the actual ranking score.
6. Query Realisation
In GraphSE^{2}, receives queries as the query strings in the form of sexpression. It is composed of several operators to describe the set of results the client wishes to receive (see Table 1). In the following sections, we introduce the operators in GraphSE^{2} and their security properties.
6.1. Graph Operators
GraphSE^{2} uses atomic operations in Section 5.3 to realise all operators in Table 1. In this section, we present the detailed constructions of these operators. Note that we only consider the operators as the outermost operators, i.e., they are not nested in any other query strings, because the query plan generation highly depends on the outermost operators.
term. The term operator runs an Index Access operation to retrieve a posting list. In addition, if there is a requirement to rank the result, the Sorting operation is able to return a sorted posting list which puts the record with higher relevance at the beginning of the list.
and. This operator is natively supported by the BooleanQuery algorithm. As mentioned in Section 5.3, conjunctive queries with nested queries (e.g., ) are processed by evaluating the boolean expression in . It is obvious that the and operator is executed in a sublinear time, as its complexity is proportional to the size of .
difference. The difference operator is extended from BooleanQuery algorithm. Considering the query (difference friend:3 (and friend:1 friend:2)) from Table 1, it aims to find the friends of , who are neither ’s friends nor ’s friends. The boolean expression, in this case, is , but the results that satisfy the expression are removed from the results of the query . In summary, difference operator excludes the results that satisfy the boolean expression . Therefore, the sexpression with difference operator is represented as . Comparing with the and operator, it returns the results only if the boolean expression returns false instead of true.
or. The complexity of the original approach for processing disjunctive queries is linear to the size of database (Cash et al., 2013). To achieve a sublinear time complexity, we leverage the above difference and term operators to build a new disjunctive query operator. In particular, the sexpression starts with or operator can be processed via a list of difference expressions and an additional term expression. For instance, if a disjunctive query has three indexing terms: , the corresponding sexpression is (), and it is parsed as: . The above three sexpressions return three different sets of results, and the composite of them is the final result of or operator. The correctness of the above approach can be easily proved by the set operation: .
In general, a disjunctive sexpression with indexing terms can be rewritten as sexpressions with difference operator and sexpressions with term operator. The complexity is proportional to , where is the number of disjunctive indexing terms and is the result size of the most frequent term .
6.2. Apply Operator
The apply is a unique operator in Unicorn (Curtiss et al., 2013), which enables graphtraversal. The basic idea is to retrieve the results of nested queries and use these results to construct and execute a new query. For example, given an sexpression (apply friend: friend:), issues a query (term friend:) and collects users, it then generates the second query to get the entities that are more than one edge away from the user in the encrypted graphstructured data.
GraphSE^{2} defines a query structure to construct apply operator. In details, the query structure is a tuple of (prefix, s, filter), where the prefix (e.g., friend:) is prepended to the given to form the indexing terms, s is an sexpression with indexing terms (e.g., (term ?)), and filter indicates the ranking algorithm for its results. To execute an apply operator, preprocesses the input with a given prefix in the query structure and uses processed to execute the sexpression s from the query structure. handles the query from the sexpression and applies the designated filter in the query structure to refine the result. Consequently, can retrieve a list of as the result of the nested query structure. GraphSE^{2} leverages as input the retrieved and outer query structure to repeat the above procedure until it reaches the outermost query structure. Algorithm 3 gives the detailed implementation of the apply.
The apply operator processes necessary steps on behalf of its users to improve the efficiency of GraphSE^{2}. For example, it would be possible for users to ask recommendation from friends: both and client can execute a twostep query to retrieve friend list in advance and issue an additional query to get the recommendation. Compared to the latter strategy, the apply operator runs in can highly reduce the workload on the client side: it saves the network latency of transmitting intermediate result between and client, addition to the computational cost of aggregation and regeneration. Furthermore, can further optimise the query and adopt the different scoring strategy by giving its semantic context (as shown in the following example).
Example: Friend Recommendation. The friend recommendation is a good example for the use of the apply operator. According to the Homophily theory (McPherson et al., 2001)
, people with higher similarity have a higher probability to become friend. In this context, the system aims to recommend the friendsoffriends to its user according to the order of similarities. Hence, we apply a simple ranking function which returns the sorted similarity value directly for both outer and nested query for this application.
It is also possible to implement the friendsoffriends query without the apply operator. Intuitively, friendsoffriends also can be treated as an edge type, GraphSE^{2} may explicitly store the friendsoffriends list and use the indexing term friendsoffriends:id to index it. Therefore, the friend recommendation problem is easily processed by the term operator. However, such a naive solution blows up the memory consumption on : as shown in Table 3
, the estimated size of friendsoffriends posting list is almost 370x larger than the original friend list of a typical user
(Curtiss et al., 2013). In GraphSE^{2}, each encrypted tuple occupies bytes memory space (See Section 8.2 for the detailed discussion), it indicates that the friendsoffriends posting lists for 1 million users consumes TB RAM.The apply operator also reduces the query latency: it is expensive to sort the posting lists of friendsoffriends:id with 48k entities inline in Garbled Circuit (it needs s to evaluate the corresponding circuit). In comparison, introducing an extra round to query enables to truncate the result, and makes the sorting process more efficient. For example, if GraphSE^{2} applies a filter to return the top results to for the nested query, the result size can be reduced to around users with a higher similarity. Also, the reduced result size is moderate to evaluate sort circuit on it. Under our settings in Section 8, the system replies either a full result list after  s or a truncated result list after  s.
friendsoffriends  apply  

Est. # of users/posting list  k  
Est. Storage overhead  GB  TB 
Query delay  s  s 
6.3. Security Analysis
In Section 5.3, we discuss the security of each atomic operation. Here, we analyse the security of the overall system. Specifically, we formulate the security of GraphSE^{2} based on the prior work of SSE (Curtmola et al., 2011; Cash et al., 2013) and further combine the security of additive sharing and Garbled Circuit to depict the security of query operators. Throughout the analysis, we consider a query in GraphSE^{2} containing a boolean formula and a tuple of indexing terms .
Overview. The main idea of analysing the security of GraphSE^{2} is similar to that in SSE scheme (Curtmola et al., 2011; Cash et al., 2013). Specifically, the analysis constructs a simulator of GraphSE^{2} to show that the adversary in GraphSE^{2} only learns the controlled leakage parameterised by a leakage function , after querying a vector of queries . Note that the simulator of GraphSE^{2} is slightly different from the original SSE simulator, we outline these different points as the sketch of our security analysis. Firstly, we update the leakage function of SSE ( in GraphSE^{2}
) to additionally capture the ranks leaked in query results. Secondly, we slightly modify the capability of adversaries to fit our twoparty model: an adversary in our system is able to see the view on the corrupted cluster as well as the output of the counterparty. Under the new adversary model, the joint distribution of the outputs of both the adversary and the counterparty can be properly simulated by an efficient algorithm with the updated leakage function. Finally, as GraphSE
^{2} has the submodules implemented by SSE, additive share scheme, and Yao’s Garbled Circuit, the simulator of GraphSE^{2} can be constructed by combining the simulators of these submodules. For instance, our simulator uses the output of SSE simulator as the input of garbled circuit simulator in order to simulate the query operators with structured data access and sorting.Due to the page limit, the updated leakage function is given in Appendix A.1 and the detailed proof is in Appendix A.2.
Discussion. Note that there exist some emerging threats against the building blocks of GraphSE^{2}. Regarding SSE, leakageabuse attacks (Cash et al., 2015; Zhang et al., 2016) can help an attacker to explore the information learned during queries. To mitigate them, recent studies on padding countermeasures (Cash et al., 2015; Bost and PA, 2017) and forward/backward privacy (Bost et al., 2017; Sun et al., 2018) are proposed and shown to be effective. We leave the integration of these advanced security features to our system as future work. Regarding sorting, GraphSE^{2} reveals the rank of the query result. Recent work (Kellaris et al., 2016; Kornaropoulos et al., 2019) demonstrates that the underling data values are likely to be reconstructed if an adversary knows ranks and some auxiliary information of queries and datasets. Currently, we do not consider such a strong adversary, and how to fully address the above threat remains as an interesting problem.
7. Implementation
We implement a prototype system for evaluating the performance of GraphSE^{2}. To build this prototype, we first realise the cryptographic primitives in Section 3. Specifically, we use the symmetric primitives, i.e., AESCMAC and AESCBC, from Bouncy Castle Crypto APIs (The Legion of the Bouncy Castle, 2007). In addition, we use a builtin curve from Java Pairingbased Cryptography (JPBC) (Caro and Iovino, 2011) library (Type A curve) to support the group operations in . The security parameter of symmetric key encryption schemes is 128bit, and the security parameter of the elliptical curve cryptographic scheme is 160bit. Regarding the secure twoparty computation, we set the field size to . Therefore, we can use regular arithmetics on Java integer type to implement the modulo operations, as it is significantly faster than the native modulo operation in Java BigInteger type (i.e., we observed that it is 50x faster). We involve this optimisation into the implementation of additive sharing scheme in the finite field , the addition (multiplication) operations is calculated by several regular addition and multiplication operations with the modulo operation. Oblivious Transfer and Garbled Circuit are implemented by using FlexSC (Wang, 2018). It implements the extended OTs in (Asharov et al., 2013) and several optimisations for the garbled circuit, which make it a practical primitive under Java environment.
The prototype system consists of three main components: the encrypted database generator, the query planner in and the index server daemon in . The encrypted database generator is running on a cluster with Hadoop (Apache, 2015). It partitions the plaintext data, runs the adapted to convert the data into encrypted tuples with the additive share of sortkeys and stores these tuples on each . We leverage Spark (Zaharia et al., 2010) to execute these tasks inmemory and enable the pipelining data processing to further accelerate this process. The generated tuples are stored in the inmemory keyvalue store Redis (Redis Labs, 2017) in the form of on each for querying purpose later. In addition, the generated is kept in the external storage of each to support the set operations. All queries are handled by the query planner and index server daemons by following the query processing flow in Section 4.1. Thrift thread pool proxy (Slee et al., 2007) is deployed to handle the queries in index server daemons.
To improve the runtime performance of our prototype, each posting list is segmented into fixedsize blocks indexed by its and a block counter for the . As the final result of the block counter indicates the total number of blocks for each , it is also stored in Redis after the whole posting list is converted to encrypted tuples. Those counters enable to retrieve multiple tuples in parallel. We also introduce a startup process for protocol and secure twoparty computation in index server daemons. In terms of the matching, the index server daemon creates a Bloom Filter (Bloom, 1970) to load the into memory during the startup process. In our prototype, we deploy the Bloom filter from Alexandr Nikitin as it is the fastest Bloom filter implementation for JVM (Nikitin, 2017). We set the false positive rate to , and the generated Bloom Filter only occupies a small fraction of memory. Besides generating the Bloom Filter, each index server also precomputes several multiplication triplets and sorting circuits and periodically refreshes it to avoid extra computational cost onthefly.
Our prototype system implementation consists of four main modules with roughly 3000 lines of Java code, we also implement a test module with another 1000 lines of Java code.
Node type  # of nodes  Edge type  # of edges 

User  friend  
Group  follow 
8. Experimental Evaluations
8.1. Setup
Platform. We deploy the index server daemons in a cluster () with 6 virtual machine instances in the Microsoft Azure platform. All VMs are E42s v3 instances, configured with 2 Intel Xeon E52673 v4 cores, 32GB RAM, 64GB SSD external storage and 40Gbps virtualised NIC. Another D16s v3 instance is created in Azure to run with the query planner and client; it is equipped with 16 Intel Xeon E52673 v3/v4 cores, 64GB RAM, 128GB SSD external storage and 40Gbps virtualised NIC. We also have the other three E42s v3 instances controlled by ; we use them to run the encrypted database generator for generating the encrypted index. All VMs are installed with Ubuntu Server 16.04LTS.
Dataset. We use a Youtube dataset from (Mislove et al., 2007), which is an anonymised Youtube usertouser links and user group memberships network dataset. The detailed statistical summary is given in Table 4. We recognise the usertouser links as friend edge and user group memberships as follow edge from this dataset. The generated posting lists are indexed by above two edge types and user s. As the social network in our Youtube dataset is an unweighted network, we randomly generate a weight between and for each edge to evaluate the arithmetic and sort operations of GraphSE^{2}.
Baseline. To evaluate the performance of GraphSE^{2}, we create a graph search system by removing/replacing cryptographic operations in this baseline system. Specifically, we leverage hash function to generate instead of using expensive group operations. The index and sortkey are stored in plaintext, which means that the can compute and sort without any network communication for OT and multiplication triplets. Finally, the query planner provides the indexing term in plaintext instead of to the as query token. Nonetheless, we still use the PRF value of indexing term and the block counter as tuple index, because we want to keep the table structure of unaltered to make our system comparable to the baseline. We use this baseline system to evaluate the overhead from cryptographic operations as GraphSE^{2} implements the same operators as Facebook Unicorn (Curtiss et al., 2013).
8.2. Evaluation Results
Vector length  2  4  8  16  32  64  128 

# of AND Gates  4382  9148  19448  41968  91616  201664  446336 
GC evaluation time (ms)  17.3  20.3  31.5  48.2  101.0  206.5  440.0 
GC comm. overhead (MB)  0.12  0.41  0.46  0.97  2.10  4.49  9.80 
EDB Generation. Firstly, we demonstrate the runtime performance of the encrypted database generator. The generator needs to partition and create additive shares from the original plaintext data, and to generate the adapted index for each . GraphSE^{2} uses to locally generate the partitions and additive shares for our dataset and then uses the dedicated cluster to generate the encrypted graph index in parallel. The result on our million records dataset shows that it only takes s to preprocess data on and mins to generate the encrypted index via Spark.
Storage. Recall that GraphSE^{2} uses adapted index to support boolean queries over the encrypted graph, which needs to generate two dedicated data structure (i.e., and ). As a result, GraphSE^{2} consumes more storage capacity than the baseline system (see Figure 5), because it is required to keep more information (i.e., in ciphertext), and because it stores encrypted index which is larger than the corresponding plaintext. By using the , we observe that our system increases the memory consumption of Redis by (557MB in and 300MB in plaintext), which is slightly smaller than the theoretical memory consumption overhead ( according to Figure 5). The reason is that GraphSE^{2} also keeps the number of blocks of each posting list (see Section 7) to accelerate the tuple retrieving process^{3}^{3}3If the size of posting list is unknown, the system needs to sequentially retrieve the tuple from blocks, as the key is derived from and block counter. Otherwise, the tuples can be retrieved in parallel.. As shown in Figure 5, the block counter requires an additional bytes of memory consumption for each indexing term both in and in plaintext. It introduces the same extra cost on GraphSE^{2} as well as in the baseline system, and makes the memory consumption overhead smaller than the theoretical expectation.
For storage overhead, GraphSE^{2} increases it by 17x (1.5GB versus 90MB), mostly due to the fact that the size group element is much larger than a PRF value. But the Bloom Filter successfully saves the memory consumption in runtime, because the size of Bloom Filter only depends on the false positive rate and the number of total elements inside (the number of edges in our system) (Bloom, 1970), and it is much smaller than itself. By fixing the false positive rate to , the runtime overhead of in our system is identical to the baseline system (only 18MB in RAM).
Query Delay. To understand the query delay introduced by cryptographic primitives, we measure the cryptographic overhead from these cryptographic primitives independently. To evaluate the query delay introduced by the set operations, we choose an indexing term a from friend edges with fixed selectivity (, as the average user has friends according to Unicorn paper (Curtiss et al., 2013)), and we further choose several variable indexing terms v from friend edges with selectivity from to . Figure 6 illustrates query delay on Index Access v and two variants of twoterm Boolean Query. In Index Access v query, the query only consists of sterm v, and the figure shows that its execution time is linear to the size of corresponding posting lists. The other twoterm queries combine the previous queries with the fixed term a. In the first of these two queries, we use a as xterm, each tuple from should be checked wtih the cost of an exponentiation, which requires to ms to process. In the last one, a is used as sterm, where we observe that the execution time is kept invariable ( ms), irrespective of the variable selectivity of the xterm v. It demonstrates that GraphSE^{2} can respond a query related to the moderate users with a tiny latency, and it is also able to reply query about popular users with a slightly bigger but still modest delay.
The secure addition and multiplication is supported by additive sharing scheme with a relatively small overhead, because in most cases, the two servers noninteractively do the computation tasks by using regular arithmetic operations, and because the expensive tasks, such as multiplication triplets generation, are precomputed in the startup process. Figure (a)a and (b)b demonstrate the execution delay of addition and multiplication over the different size of vectors. We can see that the addition operation with two vectors containing entities can be done within ms. For the multiplication operation, it needs ms to compute the product of entities because it requires several efficient but nonnegligible communications with the counterparty.
As the sorting algorithm is implemented by Garbled Circuit, we provide a benchmark about the size of the circuit and the corresponding evaluation time. The results are listed in Table 5. Note that we do not report the circuit generation time as it is generated in the startup process. The reported result demonstrates the practicality of our sorting strategy: the local sorting generally involves fewer entities after partition ( if the system sorts a result list with users), which takes ms to sort. Additionally, the local sort can help to truncate the result before sending it for global sorting, which makes the sorting algorithm in Garbled Circuit more efficient (less than ms for a vector with entities).
We further examine the query delay from set operations under multiplekeyword setting by using the same a as sterm, but we add more variable terms as xterm. Figure 7 shows that each additional xterm increases the query delay by ms, which means a query with xterms can still be processed within ms.
Communication. We measure the intercluster communication overhead, because it includes the main communication overhead in GraphSE^{2}, which is to send the garbled sorting circuit as well as the labels of inputs to the counterparty. Note that this is much larger than sending the multiplication triplets ( bytes for each) and the encrypted ( bytes for each). We demonstrate the communication overhead for different size of the circuit in Table 5. It shows that for an average user with approximately friends, the twoparty only requires to transmits MB data to sort them. This overhead is negligible both in our evaluation platform (40Gbps NIC in Azure intranet) and the other public clouds such as AWS.
Throughput. To evaluate the impact of our system on throughput, we measure the server throughput for different types of operators. For each operator, we compare the throughput results between GraphSE^{2} and the baseline. Figure 9 and Table 6 show the throughput test results for GraphSE^{2} and baseline. In all the cases, we group our 6 VM instances into 2 clusters with 3 VMs to fulfil the twoparty settings. All VMs are running with only one core involved in the computation, and we simulate parallel client processes to send the query to the server, which ensures workload on the server side. The results show that the throughput penalty is mainly from the sorting: the local sorting decreases the throughput by to . We also observe that the global sorting is the bottleneck of the whole system (see Table 6), it gives a constant query throughput for all operators, which means it runs longer to obtain the final result. However, for the operators without sorting, the throughput loss is modest (only to ).
Operators  term  and/diff.  or 

Baseline  
Our system 
9. Conclusion
This paper presents an encrypted graph database, named GraphSE^{2}. It enables privacypreserving rich queries in the context of social network services. Our system leverages the advanced cryptographic primitives (i.e., , and mixing protocol with additive sharing and Garbled Circuit) with strong security guarantees for queries on structured social graph data, and queries with computation, respectively. To lead to a practical performance, GraphSE^{2} generates an encrypted index on a distributed graph model to facilitate parallel processing of the proposed graph queries. GraphSE^{2} is implemented as a prototype system, and our evaluation on YouTube dataset illustrates its efficiency on social search.
References
 (1)
 Apache (2015) Apache. 2015. Hadoop. https://hadoop.apache.org[online]. (2015).
 Asharov et al. (2013) G. Asharov, Y. Lindell, T. Schneider, and M. Zohner. 2013. More Efficient Oblivious Transfer and Extensions for Faster Secure Computation. In ACM CCS’13.
 AWS (2018a) AWS. 2018a. AWS Case Study: Airbnb. https://aws.amazon.com/solutions/casestudies/airbnb/[online]. (2018).
 AWS (2018b) AWS. 2018b. AWS Case Study: PIXNET. https://aws.amazon.com/cn/solutions/casestudies/pixnet/[online]. (2018).
 AWS (2018c) AWS. 2018c. AWS Outposts: Run AWS Infrastructure OnPremises for A Truly Consistent Hybrid Experience. https://aws.amazon.com/outposts/[online]. (2018).
 Baldimtsi and Ohrimenko (2015) F. Baldimtsi and O. Ohrimenko. 2015. Sorting and Searching Behind the Curtain. In FC’15.
 Batcher (1968) K.E. Batcher. 1968. Sorting Networks and their Applications. In ACM SJCC’68.
 Beaver (1991) D. Beaver. 1991. Efficient Multiparty Protocols using Circuit Randomization. In CRYPTO’91.
 Bellare et al. (2012) M. Bellare, V.T. Hoang, and P. Rogaway. 2012. Foundations of Garbled Circuits. In ACM CCS’12.
 Blanton et al. (2013) M. Blanton, A. Steele, and M. Alisagari. 2013. DataOblivious Graph Algorithms for Secure Computation and Outsourcing. In ACM AISACCS’13.
 Bloom (1970) B.H. Bloom. 1970. Space/Time Tradeoffs in Hash Coding with Allowable Errors. Commun. ACM 13, 7 (1970), 422–426.
 Bost et al. (2017) R. Bost, B. Minaud, and O. Ohrimenko. 2017. Forward and Backward Private Searchable Encryption from Constrained Cryptographic Primitives. In ACM CCS’17.
 Bost and PA (2017) R. Bost and Fouque PA. 2017. Thwarting Leakage Abuse Attacks against Searchable Encryption–A Formal Approach and Applications to Database Padding. Cryptology ePrint Archive, Report 2011/1060. (2017).
 Breese et al. (1998) J.S. Breese, D. Heckerman, and C. Kadie. 1998. Empirical Analysis of Predictive Algorithms for Collaborative Filtering. In UAI’98.
 Canetti (2000) R. Canetti. 2000. Security and Composition of Multiparty Cryptographic Protocols. Journal of Cryptology 13, 1 (2000), 143–202.
 Cao et al. (2011) N. Cao, Z. Yang, C. Wang, K. Ren, and W. Lou. 2011. PrivacyPreserving Query over Encrypted GraphStructured Data in Cloud Computing. In IEEE ICDCS’11.
 Caro and Iovino (2011) A. De Caro and V. Iovino. 2011. JPBC: Java Pairing Based Cryptography. In IEEE SCC’11. 850–855.
 Cash et al. (2015) D. Cash, P. Grubbs, J. Perry, and T. Ristenpart. 2015. LeakageAbuse Attacks Against Searchable Encryption. In ACM CCS’15.
 Cash et al. (2013) D. Cash, S. Jarecki, C.S. Jutla, H. Krawczyk, MC. Rosu, and M. Steiner. 2013. HighlyScalable Searchable Symmetric Encryption with Support for Boolean Queries. In CRYPTO’13.
 Chang et al. (2016) Z. Chang, L. Zou, and F. Li. 2016. Privacy Preserving Subgraph Matching on Large Graphs in Cloud. In ACM SIGMOD’16.
 Chase and Kamara (2010) M. Chase and S. Kamara. 2010. Structured Encryption and Controlled Disclosure. In AISACRYPT’10.
 Chi et al. (2016) Y. Chi, G. Dai, Y. Wang, G. Sun, G. Li, and H. Yang. 2016. Nxgraph: An Efficient Graph Processing System on A Single Machine. In IEEE ICDE’16.
 Curtiss et al. (2013) M. Curtiss, I. Becker, T. Bosman, S. Doroshenko, L. Grijincu, T. Jackson, et al. 2013. Unicorn: A System for Searching the Social Graph. Proceedings of the VLDB Endowment 6, 11 (2013), 1150–1161.
 Curtmola et al. (2011) R. Curtmola, J. Garay, S. Kamara, and R. Ostrovsky. 2011. Searchable Symmetric Encryption: Improved Definitions and Efficient Constructions. Journal of Computer Security 19, 5 (2011), 895–934.
 Demmler et al. (2015) D. Demmler, T. Schneider, and M. Zohner. 2015. ABYA Framework for Efficient MixedProtocol Secure TwoParty Computation. In NDSS’15.

Engineering (2018)
Instagram Engineering.
2018.
What Powers Instagram: Hundreds of Instances, Dozens
of Technologies.
https://instagramengineering.com/whatpowersinstagramhundredsofinstancesdozensoftechnologies
adf2e22da2ad[online]. (2018).  Goodrich et al. (2011) M.T. Goodrich, R. Tamassia, and N. Triandopoulos. 2011. Efficient Authenticated Data Structures for Graph Connectivity and Geometric Search Problems. Algorithmica 60, 3 (2011), 505–552.

Information is
Beautiful (2018)
Information is Beautiful.
2018.
World’s Biggest Data Breaches.
http://www.informationisbeautiful.net/visualizations/worldsbiggestdatabreacheshacks/
[online]. (2018).  Kamara and Moataz (2017) S. Kamara and T. Moataz. 2017. Boolean Searchable Symmetric Encryption with WorstCase SubLinear Complexity. In EUROCRYPT’17.
 Kamara et al. (2018) S. Kamara, T. Moataz, and O. Ohrimenko. 2018. Structured Encryption and Leakage Suppression. In CRYPTO’18.
 Kamara et al. (2011) S. Kamara, P. Mohassel, and M. Raykova. 2011. Outsourcing MultiParty Computation. Cryptology ePrint Archive, Report 2011/272. (2011).
 Kellaris et al. (2016) G. Kellaris, G. Kollios, K. Nissim, and A. O’Neill. 2016. Generic Attacks on Secure Outsourced Databases. In ACM CCS’16.
 Kornaropoulos et al. (2019) E.M. Kornaropoulos, C. Papamanthou, and R. Tamassia. 2019. Data Recovery on Encrypted Databases with KNearest Neighbor Query Leakage. In IEEE S&P’19.
 Lai et al. (2018) S. Lai, S. Patranabis, A. Sakzad, J.K. Liu, D. Mukhopadhyay, R. Steinfeld, et al. 2018. Result Pattern Hiding Searchable Encryption for Conjunctive Queries. In ACM CCS’18.
 Li et al. (2016) J. Li, L. Zhang, J. K. Liu, H. Qian, and Z. Dong. 2016. PrivacyPreserving Public Auditing Protocol for LowPerformance End Devices in Cloud. IEEE Transactions on Information Forensics and Security 11, 11 (2016), 2572–2583.
 Liang et al. (2015) K. Liang, J.K. Liu, R. Lu, and D. S. Wong. 2015. Privacy Concerns for Photo Sharing in Online Social Networks. IEEE Internet Computing 19, 2 (2015), 58–63.
 Lindell and Pinkas (2009) Y. Lindell and B. Pinkas. 2009. A Proof of Security of Yao’s Protocol for Twoparty Computation. Journal of Cryptology 22, 2 (2009), 161–188.
 Liu et al. (2016) J.
Comments
There are no comments yet.