Secure Multi-Party Traversal Queries over Federated Graph Databases
Nouf Aljuaid
1,2
, Alexei Lisitsa
2
and Sven Schewe
2
1
Department of Information Technology, Taif University, Saudi Arabia
2
Department of Computer Science, University of Liverpool, Liverpool, U.K.
Keywords:
Graph Databases, SMPC, Federated Databases, Secure Data Processing, Multi-Party Querying.
Abstract:
We introduce and compare two protocols for the execution of secure multi-party traversal queries over fed-
erated graph databases. The first, client based protocol uses client-to-client communication; it minimises the
exposure of data on a need-to-know basis. The second protocol uses a semi-trusted server; it combines the
use of private channels for communication between the server and clients with the use of encrypted hashing
to prevent the exposure of data to the server. We have conducted experiments to compare the efficiency of
the two protocols. The results demonstrated that the execution times for the server-based protocol are around
half an order of magnitude higher. This does, however, seem to be down to the security layer provided by
encrypted hashing: when switching it off, the running time becomes comparable.
1 INTRODUCTION
With the rapid growth of data volumes collected in
databases from various sources, traditional databases
struggle to scale to these vast amounts of data. This
limitation makes querying a complex and inefficient
task (Nayak et al., 2015). In response to these
challenges, graph databases were developed to over-
come the constraints of relational databases (Salehnia,
2017). They have found application in numerous con-
texts, including among others
social media platforms (Ciucanu and Lafourcade,
2020a).
A key strength of graph databases lies in their abil-
ity to efficiently represent and navigate relationships
using traversal queries. This concept is prominently
employed in graph databases such as Neo4j (Guia
et al., 2017). A typical traversal query follows a pat-
tern where nodes are connected by relationships, cre-
ating a path through the graph structure:
(node
1
) − [: rel
1
] − (node
2
) − [rel
2
] − (node
3
) −
. . . − (node
n
) − [rel
n
] − (node
n
)
Here, node
1
, . . . , node
n
represent the nodes in the
graph, and rel
1
, . . . , rel
n
are the relationships connect-
ing them. This pattern represents a traversal through
n nodes with n − 1 relationships.
In this work, we study the concept of traversal
queries within the realm of federated databases and
privacy-preserving processing. When dealing with
multiple graph databases owned by different parties,
each with its own set of sensitive data, it becomes
important to safeguard privacy during collaborative
analyses. We aim to develop methodologies that al-
low the execution of traversal queries across multi-
ple databases without compromising the confidential-
ity of individual databases.
In doing so, we extend the traditional concept of
secure multi-party computation (SMPC) (Evans et al.,
2018) to secure multi-party querying. Until now, in
the context of data processing, SMPC has primar-
ily been utilized to safeguard relational databases,
as seen in systems like Conclave, Senate, and SM-
CQL (Volgushev et al., 2019; Poddar et al., 2020;
Bater et al., 2016). More recently, applications of
SMPC for other types of databases with different data
models have been considered. This includes sys-
tems targeting graph databases like GOOSE (Ciucanu
and Lafourcade, 2020b), which employs SMPC at
the backend while queries remain single-party only,
and SMPQ (Al-Juaid et al., 2022), which imple-
ments multi-party queries but does not address traver-
sal queries.
The contribution of our work is as follows: We
have developed a system for preserving the privacy of
traversal multi-party queries within a federated graph
database, particularly in scenarios where the distribu-
tion of data relevant for the query is known (clear-cut
principle). The system provides the user with two dif-
ferent security protocols:
The first protocol, client-based, is designed to per-
716
Aljuaid, N., Lisitsa, A. and Schewe, S.
Secure Multi-Party Traversal Queries over Federated Graph Databases.
DOI: 10.5220/0012768000003767
Paper published under CC license (CC BY-NC-ND 4.0)
In Proceedings of the 21st International Conference on Security and Cryptography (SECRYPT 2024), pages 716-721
ISBN: 978-989-758-709-2; ISSN: 2184-7711
Proceedings Copyright © 2024 by SCITEPRESS – Science and Technology Publications, Lda.

form the traversal query with the minimum required
exposure of data or such client-to-client communica-
tion on a need-to-know basis. The second protocol,
a novel approach implemented on the server side, in-
volves hashing the data and masking it with a Diffie-
Hellman (DH) key exchanged among all clients. This
protects the data against access by the server. The
choice between the two protocols is determined based
on the preference of clients to use and the amount of
information they are willing to share.
In this work we use Neo4j, well-known imple-
mentation for graph databases (Guia et al., 2017).
Neo4j employs a graph data model composed of
nodes and relationships (Miller, 2013). Cypher, the
query language used by Neo4j, manages data within
these graph databases (Francis et al., 2018). Our sys-
tem leverages Neo4j Fabric (Gu et al., pear), a fed-
erated database solution that executes Cypher queries
targeting multiple Neo4j graph databases simultane-
ously.
The remainder of this paper is organised as fol-
lows: Section 2 presents our approach. Next, Section
3 presents the evaluation of the system and the exper-
imental setup, followed by the results of our experi-
ments. Following this, a review of related literature
(Section 4). Finally, the paper concludes in Section 5,
and we offer directions for future work.
2 SYSTEM OVERVIEW
In this section, we present an overview of how the
joint traversal query is distributed and how the system
works.
2.1 Query Agreement and Distribution
The system facilitates joint traversal querying among
two or more parties. After determining the number
of parties involved in performing the traversal query,
they should agree on a computation ID. In our current
system, this computation ID (ComID) can be consid-
ered an agreement as in the JIFF system (Albab et al.,
2019).
Following the agreement among the involved par-
ties on the query, a joint traversal Cypher query is sub-
mitted.
1
To efficiently solve this collaborative query
across multiple parties while safeguarding privacy, it
is necessary to transform the query into (sequences
of) sub-queries for each party’s database.
1
In our system, the query itself should be known for
each party involved to agree on performing it. Query pri-
vacy important in other contexts is not relevant here.
The crucial information for dividing the original
query into relevant sub-queries pertains to the dis-
tribution of data across different parties’ databases.
Depending on the context, various amounts of such
information can be available. Here, we make a strong
assumption and consider only traversal queries with
a clear-cut property. This assumption implies that
we assume the distribution of data relevant to the
traversal query across the parties is known. More pre-
cisely, for a traversal query Q of length k, involving n
parties, and partition k = m
1
+ . . . + m
n
, the clear-cut
property cc(n, [m
1
, ..., m
n
]) holds if the correct result
of the query may be obtained by: 1) splitting the
original query into successive sub-queries of lengths
m
1
, . . . , m
n
; 2) receiving and combining the results
of these queries on parties 1, . . . , n databases, respec-
tively. For example, consider the submitted joint
traversal query:
{(node
1
) − [: rel
1
] − (node
2
) − [: rel
2
] − (node
3
) − [:
rel
3
] − (node
4
) − [: rel
4
] − (node
5
)}
Now, let’s assume the clear-cut property cc(3,
[2, 1, 1]). This means we want to segment the
original query into three parts, with the lengths of re-
lationships assigned to each part as [2, 1, 1].
This will produce three distinct sub-queries corre-
sponding to each party’s database:
Query 1:
{(node
1
) − [: rel
1
] − (node
2
) − [: rel
2
] − (node
3
)}
Query 2:
{(node
3
) − [: rel
3
] − (node
4
)}
Query 3:
{(node
4
) − [: rel
4
] − (node
5
)}
2.2 Query Workflow
After generating the sub-queries corresponding to
each party’s database, the query can be executed on
either the client-based or the server-based. In the fol-
lowing sections, we will explain the query workflow
for each base. Before delving into that, we will ex-
plain all the necessary operations that could be used
on both sides to execute the traversal query.
2.2.1 Preliminaries
In both protocols we need to deal with the results of
the sub-queries, which would be in the form:
{(node
1
, node
2
), ... }, where node
1
, node
2
, . . . are
strings. In order to deal with that we introduce some
notations that will be used later in both protocols as
needed.
• ν(s) := {y | ( ¯x, y) ∈ s}
• µ(s) := {x | (x, ¯y) ∈ s}
Secure Multi-Party Traversal Queries over Federated Graph Databases
717

• τ(s
1
, s
2
) := ν(s
1
) ∩ µ(s
2
)
• F
1
(w, s) := {( ¯x, ¯y) | ¯x ∈ w, ( ¯x, ¯y) ∈ s}
• F
2
(s, w) := {( ¯x, ¯y) | ( ¯x, ¯y) ∈ s, ¯y ∈ w}
• C(s
1
, s
2
) := {( ¯x, y, ¯z) | ( ¯x, y) ∈ s
1
, (y, ¯z) ∈ s
2
)}
The first two are ν and µ, which can be used to
project either the last node or the first node in the
query result. The τ function is used to find the in-
tersection between the two datasets (the result of the
sub-queries).The two functions F
1
and F
2
are used to
filter results based on the result of τ; either the first
or last node is the connection node between the two
queries.
The last one, C, is used to combine the final result
of the traversal path among all involved parties.
2.2.2 Protocol 1: Client-Based
The client-based protocol primarily relies on two fun-
damental operations: projection and intersection. In
this process, each party projects its final node from
the result of its respective sub-query and intersects it
with the subsequent party in the traversal query. Thus,
the information is exchanged on a a need-to-know ba-
sis with the aim to reduce the exposure of the private
data. Algorithm 1 illustrates the phases involved in
client-based query execution.
The following example illustrates the client-based
protocol for the case of three parties, using the nota-
tion detailed in subsection 2.2.1:
Party 1: R
1
:
= r(Q
1
); Send(P
2
, ν(R
1
))
Party 2: R
2
:
= r(Q
2
); t
1
:
= τ(ν(R
1
)), µ(R
2
)));
R
2
:
= F
1
(t
1
, R
2
); Send(P
3
, ν(R
2
)))
Party 3: R
3
:
= r(Q
3
); t
2
:
= τ(ν(R
2
)), µ(R
3
)));
R
3
:
= F
1
(t
2
, R
3
); Send(P
2
, R
3
))
Party 2: C
1
:
= C(R
2
, R
3
); Send(P
1
, C
1
))
Party 1: C
2
:
= C(R
1
, C
1
); Send([P
2
, P
3
], C
2
))
This process illustrates a step-by-step interaction
among the parties involved, highlighting the sequence
of actions and communication exchanges necessary to
execute the traversal query within the framework of
the client-based protocol.
2.2.3 Protocol 2: Server-Based
In the server-based protocol, our goal is to minimize
the exposure of data between parties by employing
two key operations: projection and intersection on the
server. After each party obtains the result of a sub-
query, they send it to the server in a protected form.
This protection involves leveraging Diffie-Hellman
key exchange (DH) during their connection to the sys-
tem and hashing the sub-query result using HMAC
Algorithm 1: Client-based Query Execution.
Require: Q: Joint Traversal query
Require: P: Set of parties P
1
, P
2
, . . . , P
n
for sharing
computations.
Require: ComID: Shared computation ID as proof of
agreement.
Require: k: The length of relationships
Connect to the System
1. Decide the number of parties (P
i
) involved in the
computation.
2. Use shared ComID to agree on the computation.
Preprocessing Phase
1. One of P
i
submits Q to the system.
2. Parse Q into Q
i
based on m
i
for each P
i
.
3. Execute Q
i
on each P
i
’s Neo4j database.
Computation Phase
1: for i = 1 to n − 1 do
1. Each P
i
sends ν(R(Q
i
)) to P
i+1
2. Each P
i+1
computes
τ(ν(R(Q
i
)), µ(R(Q
i+1
)))
3. Each P
i+1
filters his R(Q
i+1
) by:
F
1
(τ(R(Q
i
), R(Q
i+1
)), R(Q
i+1
))
2: end for
Reconstruction Phase
3: for i = n to 1 do
1. Each P
i
sends the updates R(Q
i+1
) to P
i−1
.
2. Each P
i−1
computes C(R(Q
i
), R(Q
i+1
))
4: end for
3. Once P
1
computes the final C, distribute the final
result of Q to all parties.
and the DH key. The ability of the server to per-
form intersection operation on protected values relies
crucially on HMAC being a deterministic function.
Algorithm 2 presents the phases involved in server-
based query execution. The following example illus-
trates the server-based protocol for the case of three
parties.
Party 1: R
1
:
= r(Q
1
); Send(S, Hmac(R
1
))
Party 2: R
2
:
= r(Q
2
); Send(S, Hmac(R
2
))
Party 3: R
3
:
= r(Q
3
); Send(S, Hmac(R
3
))
Server: C
1
:
= C(R
1
, R
2
); C
2
:
= C(C
1
, R
3
);
Send([P
1
, P
2
, P
3
], C
2
))
Party 1: F
1
:
= Hmac
−1
(C, DH); Send(S, (F
1
))
Party 2: F
2
:
= Hmac
−1
(C, DH); Send(S, (F
2
))
Party 3: F
3
:
= Hmac
−1
(C, DH); Send(S, (F
3
))
Server: C
3
:
= C(F
1
, F
2
); C
4
:
= C(C
3
, F
3
);
Send([P
1
, P
2
, P
3
], C
4
))
This process illustrates a step-by-step interaction
among the parties involved, highlighting the sequence
of actions and communication exchanges necessary to
execute the traversal query within the framework of
the server-based protocol.
SECRYPT 2024 - 21st International Conference on Security and Cryptography
718

Algorithm 2: Server Based Query Execution.
Require: Q: Joint Traversal query.
Require: P: Set of parties P
1
, P
2
, . . . , P
n
for sharing
computations.
Require: ComID: Shared computation ID as proof of
agreement.
Require: k: The length of relationships.
Require: Dh: Key generated and exchanged using the
Diffie-Hellman algorithm.
Require: Hmac: Function to hash result using Dh
Connect to the System
1. Decide the number of parties (P
i
) involved in the
computation.
2. Use shared ComID to agree on the computation.
3. After (P
i
) connects to the system, generate Dh
and exchange it between P
n
.
Client Side
1. One of P
i
submits Q to the system.
2. Parse Q into Q
i
based on m
i
for each P
i
.
3. Execute Q
i
on each P
i
’s Neo4j database.
4. R(Q
i
) for each P
i
are hashed using
Hmac(R(Q
i
), Dh) and store in table.
5. Each P
i
sends the hashed R(Q
i
) to the server.
Server Side
1: for i = 1 to n − 1 do
1. Computes C(R(Q
i
), R(Q
i+1
))
2: end for
7. Send the final result of C to each P
i
.
Client Side
1. Each P
i
recover its parts of C using maps table of
Hmac
−1
(C, DH)
2. Each P
i
sends the decrypted parts of C to the
server.
Server Side
3: for i = 1 to n do
1. Computes C(R(Q
i
), R(Q
i+1
))
4: end for
2. Send the final result of C to each P
i
.
3 EXPERIMENTATION AND
EVALUATION
We evaluated and implemented our proposed system
using JavaScript, drawing inspiration from the con-
cept of constructing the system with the JIFF library
(Albab et al., 2019). It is designed to be highly
flexible, prioritizing usability, and it can run in both
browser and Node.js environments. Our model has
been developed to facilitate joint traversal queries
across multiple graph databases owned by various
parties. We investigate its efficiency to answer the fol-
lowing questions:
• Q1: How effective is our system in ensuring se-
cure joint traversal multiparty queries, and what
is its efficiency in terms of performance?
• Q2: Does the data size impact the system’s effi-
ciency?
• Q3: How does our model performance compare
to executing traversal query on a Single Neo4j
database?
3.1 Experimental Setup
The experiments were carried out on a desktop PC
running Windows 11 with an Intel Core i7 processor
clocked at 1.5 GHz and 16.00 GB of RAM, utilising
a local database for each party. Execution times, rep-
resenting the duration to obtain query results, were
measured using the performance.now() function in
JavaScript.
3.2 Dataset and Joint Traversal Query
For our experiment, we utilized the ’POLE’ dataset,
a large-scale dataset of open crime data for Manch-
ester, UK, spanning August 2017 (Hunger, 2020).
This dataset comprises 61,521 nodes interconnected
by 105,840 relationships. Our experimental setup
involved executing traversal queries using different
numbers of parties and applying the clear-cut algo-
rithm to segment the queries. We aimed to evaluate
the security and performance of two-based protocols
across various configurations. The traversal query
employed is as follows:
MATCH (o:Officer {badge_no: ’26-5234182’})
<-[:INVESTIGATED_BY]-(c:Crime {type: ’Drugs’})
<-[:PARTY_TO]-(p1:Person)-[:KNOWS]-
(p2:Person)-[:KNOWS]-(p3:Person)
-[:PARTY_TO]->(:Crime {type: ’Drugs’})
RETURN o.name, c.type, p1.name, p2.name,
p3.name, c.type
In the first experiment, we ran the traversal
query within two parties using the clear-cut al-
gorithm cc(2,[3,2]), resulting in two distinct
sub-queries. In the second experiment, involving
three parties, we employed the clear-cut algorithm
cc(3,[2,2,1]) to segment the query, leading to
three distinct sub-queries. For the traversal query in-
volving four parties, we utilized the clear-cut algo-
rithm cc(4,[2,1,1,1]), resulting in four distinct
sub-queries. Lastly, in the traversal query involv-
ing five parties, we applied the clear-cut algorithm
cc(5,[1,1,1,1,1]) for segmentation, resulting in
five distinct sub-queries.
Secure Multi-Party Traversal Queries over Federated Graph Databases
719

3.3 Experimental Results
Table 1 presents the execution times of various ex-
periments conducted under different configurations.
We conduct the same experiments using client-based
protocol and server-based protocol. Additionally, we
run the same experiments on the server-based proto-
col without using encryption (DH key with HMAC
hash table) to show the overhead of adding this layer
on the server-based protocol.
Table 1: Execution times for E1– E4 when using Client
based and Server based protocols.
Experiments Client based
Server Based
(with Encryption)
Server Based
(without Encryption)
E1 73 204 70
E2 101 425 166
E3 118 450 179
E4 140 589 224
As evident from Table 1, the client-based protocol
offers better performance but exposes more informa-
tion between parties. On the other hand, the server-
based protocol with encryption provides a higher level
of security but exhibits higher execution times than
the client-based protocol due to rounds of encryption
and decryption and collecting the final result.
The server-based protocol with encryption incurs
additional overhead compared to the client-based pro-
tocol. However, the server-based protocol without
encryption demonstrates lower execution times com-
pared to the server-based protocol with encryption for
all experiments. This shows that the encryption pro-
cess adds significant overhead to the server-based pro-
tocol.
The choice between the two protocols is based
on the preference of the user, either high perfor-
mance or high security. If the clients prioritize high
performance and the data being transmitted is not
highly sensitive, the client-based protocol is the better
choice. However, if security is of utmost importance
and cannot be compromised on data protection, the
server-based protocol may be the better choice despite
the higher execution times.
According to this analysis, we suggest a third pro-
tocol, a hybrid protocol, to take advantage of the per-
formance of the client-based protocol and the security
of the server-based protocol. The idea is, instead of
sharing all the results with the server, we share the
last node as in the client-based protocol but in en-
crypted form and let the server find the intersection
only. Then, the clients perform the filtering of data
and complete the query.
4 RELATED WORK
There have been recent efforts to integrate SMPC with
databases to enhance data security. The following
section summarizes some of the existing works and
provides comparisons between them based on various
factors.
Model of Data: Most existing works have integrated
SMPC with the relational database model, such
as Conclave (Volgushev et al., 2019), SMCQL
(Bater et al., 2016), Senate (Poddar et al., 2020),
SAQE (Bater et al., 2020), Secure Yannakakis
(Wang and Yi, 2021), Shrinkwrap (Bater et al.,
2018), Secrecy (Liagouris et al., 2021), VaultDB
(Rogers et al., 2022), Scape (Han et al., 2022),
Sequre (Smajlovi
´
c et al., 2023), SDB (He et al.,
2015), and Hu-Fu (Tong et al., 2022). Recently,
there has been exploration into applying SMPC
to different data models beyond the traditional re-
lational model, as seen in GOSSE (Ciucanu and
Lafourcade, 2020b) and SMPQ (Al-Juaid et al.,
2022), both of which deal with graph databases.
Number of parties supported: Most of these works
support SMPC within two parties, including SM-
CQL, Senate, SAQE, Secure Yannakakis, and
VaultDB. On the other hand, Scape and Sequre
specifically support three-party scenarios. Fur-
thermore, Conclave, Hu-Fu, and SMPQ apply
SMPC protocols for more than two parties.
SMPC backend: Some of these works utilize exist-
ing implementations of SMPC as a backend to
perform joint queries. For example, JIFF (Al-
bab et al., 2019) employs secret sharing proto-
col and serves as the backend for both Conclave
and SMPQ. Similarly, OblivM (Liu et al., 2015)is
used as a backend for systems supporting two par-
ties, such as SMCQL, SAQE, and Shrinkwrap. In
contrast, both SDB and GOOSE use SMPC as a
backend over a database, but they do not support
multi-party user queries.
To the best of our knowledge, this research is the first
work to develop a system for preserving the privacy of
traversal multi-party queries within a federated graph
database.
5 CONCLUSION
We have developed a framework for securing traver-
sal queries between multiple private graph databases.
Our system provides users with two protocols, the
choice between which is determined based on the
client’s preferences and the amount of information
SECRYPT 2024 - 21st International Conference on Security and Cryptography
720

they are willing to share. We have conducted experi-
ments to compare the efficiency of the two protocols.
The results demonstrate that the execution times for
the server-based protocol are approximately half an
order of magnitude higher. In future work, we plan to
extend the system to secure traversal queries for cases
where our assumption of a clear-cut scenario does not
apply. Additionally, we aim to expand the system to
handle secure multi-party queries over heterogeneous
federated databases supporting different data models.
REFERENCES
Al-Juaid, N., Lisitsa, A., and Schewe, S. (2022). Smpg:
Secure multi party computation on graph databases.
In ICISSP, pages 463–471.
Albab, K. D., Issa, R., Lapets, A., Flockhart, P., Qin, L.,
and Globus-Harris, I. (2019). Tutorial: Deploying se-
cure multi-party computation on the web using JIFF.
In 2019 IEEE Cybersecurity Development (SecDev),
pages 3–3. IEEE.
Bater, J., Elliott, G., Eggen, C., Goel, S., Kho, A., and
Rogers, J. (2016). SMCQL: secure querying for fed-
erated databases. arXiv preprint arXiv:1606.06808.
Bater, J., He, X., Ehrich, W., Machanavajjhala, A., and
Rogers, J. (2018). Shrinkwrap: efficient sql query pro-
cessing in differentially private data federations. Pro-
ceedings of the VLDB Endowment, 12(3):307–320.
Bater, J., Park, Y., He, X., Wang, X., and Rogers, J.
(2020). SAQE: practical privacy-preserving approx-
imate query processing for data federations. Proceed-
ings of the VLDB Endowment, 13(12):2691–2705.
Ciucanu, R. and Lafourcade, P. (2020a). GOOSE: A se-
cure framework for graph outsourcing and sparql eval-
uation. In 34th Annual IFIP WG 11.3 Conference
on Data and Applications Security and Privacy (DB-
Sec’20). Accept
´
e,
`
a para
ˆ
ıtre.
Ciucanu, R. and Lafourcade, P. (2020b). GOOSE: A se-
cure framework for graph outsourcing and sparql eval-
uation. In 34th Annual IFIP WG 11.3 Conference
on Data and Applications Security and Privacy (DB-
Sec’20). Accept
´
e,
`
a para
ˆ
ıtre.
Evans, D., Kolesnikov, V., and Rosulek, M. (2018). A prag-
matic introduction to secure multi-party computation.
Found. Trends Priv. Secur., 2:70–246.
Francis, N., Green, A., Guagliardo, P., Libkin, L., Lin-
daaker, T., Marsault, V., Plantikow, S., Rydberg, M.,
Selmer, P., and Taylor, A. (2018). Cypher: An evolv-
ing query language for property graphs. In Proceed-
ings of the 2018 International Conference on Manage-
ment of Data, pages 1433–1445.
Gu, Z., Corcoglioniti, F., Lanti, D., Mosca, A., Xiao, G.,
Xiong, J., and Calvanese, D. (to appear). A systematic
overview of data federation systems. Semantic Web.
Guia, J., Soares, V. G., and Bernardino, J. (2017). Graph
databases: Neo4j analysis. In ICEIS (1), pages 351–
356.
Han, F., Zhang, L., Feng, H., Liu, W., and Li, X. (2022).
Scape: Scalable collaborative analytics system on pri-
vate database with malicious security. In 2022 IEEE
38th International Conference on Data Engineering
(ICDE), pages 1740–1753. IEEE.
He, Z., Wong, W. K., Kao, B., Cheung, D., Li, R., Yiu, S.,
and Lo, E. (2015). SDB: A secure query processing
system with data interoperability. Proc. VLDB En-
dow., 8:1876–1879.
Hunger, M. (2020). neo4j-graph-examples/pole. https:
//github.com/neo4j-graph-examples/pole/. Accessed:
2023-12-28.
Liagouris, J., Kalavri, V., Faisal, M., and Varia, M. (2021).
Secrecy: Secure collaborative analytics on secret-
shared data. arXiv preprint arXiv:2102.01048.
Liu, C., Wang, X. S., Nayak, K., Huang, Y., and Shi, E.
(2015). ObliVM: A programming framework for se-
cure computation. In 2015 IEEE Symposium on Secu-
rity and Privacy, pages 359–376.
Miller, J. J. (2013). Graph database applications and con-
cepts with Neo4j. In Proceedings of the Southern
Association for Information Systems Conference, At-
lanta, GA, USA, volume 2324.
Nayak, K., Wang, X. S., Ioannidis, S., Weinsberg, U., Taft,
N., and Shi, E. (2015). Graphsc: Parallel secure com-
putation made easy. In 2015 IEEE Symposium on Se-
curity and Privacy, pages 377–394. IEEE.
Poddar, R., Kalra, S., Yanai, A., Deng, R., Popa, R. A.,
and Hellerstein, J. M. (2020). Senate: A maliciously-
secure mpc platform for collaborative analytics. arXiv
e-prints, pages arXiv–2010.
Rogers, J., Adetoro, E., Bater, J., Canter, T., Fu, D., Hamil-
ton, A., Hassan, A., Martinez, A., Michalski, E.,
Mitrovic, V., et al. (2022). Vaultdb: A real-world pi-
lot of secure multi-party computation within a clinical
research network. arXiv preprint arXiv:2203.00146.
Salehnia, A. (2017). Comparisons of relational databases
with big data: a teaching approach. South Dakota
State University Brookings, SD 57007, pages 1–8.
Smajlovi
´
c, H., Shajii, A., Berger, B., Cho, H., and Nu-
managi
´
c, I. (2023). Sequre: a high-performance
framework for secure multiparty computation enables
biomedical data sharing. Genome Biology, 24(1):1–
18.
Tong, Y., Pan, X., Zeng, Y., Shi, Y., Xue, C., Zhou, Z.,
Zhang, X., Chen, L., Xu, Y., Xu, K., et al. (2022).
Hu-fu: Efficient and secure spatial queries over data
federation. Proceedings of the VLDB Endowment,
15(6):1159.
Volgushev, N., Schwarzkopf, M., Getchell, B., Varia, M.,
Lapets, A., and Bestavros, A. (2019). Conclave: se-
cure multi-party computation on big data. In Pro-
ceedings of the Fourteenth EuroSys Conference 2019,
pages 1–18.
Wang, Y. and Yi, K. (2021). Secure yannakakis: Join-
aggregate queries over private data. In Proceedings
of the 2021 International Conference on Management
of Data, SIGMOD ’21, page 1969–1981, New York,
NY, USA. Association for Computing Machinery.
Secure Multi-Party Traversal Queries over Federated Graph Databases
721