Graph Oriented ORAM (GORAM)

• Graph Oriented Oblivious RAM (GORAM) is a protocol that enables efficient, privacy-preserving ego-centric queries on federated graphs composed of sensitive subgraph data.
• It integrates secure multi-party computation with distributed oblivious RAM to partition, pad, and secret-share graph data, ensuring sub-linear query times even at billion-edge scales.
• GORAM employs specialized square-root ORAM indexing and two-dimensional block partitioning to protect access patterns while reducing communication overhead by over 70% in practice.

Graph Oriented Oblivious RAM (GORAM) is a graph data structure and protocol stack designed for efficient, privacy-preserving ego-centric queries on federated graphs whose edges are distributed among mutually distrustful data providers. GORAM integrates secure multi-party computation (MPC) and distributed oblivious RAM (ORAM) techniques to enable query execution at billion-edge scale, while ensuring that neither the providers, computation servers, nor clients learn sensitive information about graph structure or query intent beyond public graph size parameters. This is accomplished by partitioning the federated graph into two-dimensional blocks, padding and secret-sharing edge lists, and indexing partitions with Square-Root ORAM constructions specifically tailored for batch retrieval of query-relevant partitions (Fan et al., 2024).

1. System Overview and Roles

GORAM’s architecture features three principal roles:

• Data Providers ($P_i$): Each maintains a private directed subgraph $G_i = (V_i, E_i)$, where the global vertex ID set $V_{\rm pub}$ is public but edge sets $E_i$ remain secret.
• Computation Servers ($S_1, S_2, S_3$): Three non-colluding, semi-honest servers execute all MPC protocols including secret-sharing, distributed ORAM, and secure computation of queries.
• Clients: Issue secret-shared vertex or edge queries and receive secret-shared results.

The workflow proceeds as follows:

1. Chunking and Local Partitioning: Each $P_i$ partitions $V_{\rm pub} = [1, \dots, |V|]$ into $b = \lceil |V|/k \rceil$ vertex chunks of size $k$ and allocates edges to 2D blocks $B_i[p, q]$, where all edges have source in chunk $p$ and target in chunk $q$.
2. Block Padding and Sharing: Blocks are padded to common length $l_i$ with dummy edges and secret-shared among the servers.
3. Global Merge: An MPC-variant odd–even merge sort combines all provider-contributed blocks into global secret-shared 2D blocks $\widetilde{B}[p, q]$ with common length $l = \sum_i l_i$.
4. ORAM Index Construction: Two distributed ORAM instances are built:
   • $\mathsf{VORAM}$ (vertex-centric): size $b$, stores row-blocks for rapid ego-centric queries.
   • $\mathsf{EORAM}$ (edge-centric): size $b^2$, stores individual blocks for edge existence queries. Both ORAMs use Square-Root ORAM with a custom constant-round ShuffleMem protocol.

Each ego-centric or edge-centric query only accesses a single partition via the corresponding ORAM, resulting in per-query work and communication that is sub-linear in the graph size. The protocol ensures that no party learns real access patterns or graph structure except for public block and ORAM sizes.

2. Formalization of Data Structures and Query Semantics

Given the global directed graph $G = (V, E)$, where $|V| = n$ and $|E|$ is secret, the key constructions are:

• Vertex Chunks: $V^{(p)} = \{i \in V: (p-1)k < i \leq pk\}$, $p = 1 \ldots b$.
• 2D Blocks: $$B[p, q] = \{(u, v) \in E : u \in V^{(p)}, v \in V^{(q)}\}$$, each padded to fixed length $l$.
• Row and Block Partitions: For row $r$, $P_r = \bigcup_{j=1}^b B[r, j]$ (vertex-centric); for block $(p, q)$, $P_{p,q} = B[p, q]$ (edge-centric).

An ego-centric query for vertex $v$ returns $Q(v) = \{v\} \cup \{w: (v, w) \in E\}$. The system employs 3-party secret-sharing, with all sensitive data and queries encoded as shares $\llbracket x \rrbracket$.

ORAM abstractions are defined over arrays of secret-shared blocks, supporting oblivious access: $$\llbracket \mathsf{ORAM}.\mathsf{init}(\mathsf{Arr}) \rrbracket, \quad \llbracket \mathsf{ORAM}.\mathsf{access}(i) \rrbracket$$ where the access transcript is secret under a random permutation $\pi$, using recursive position maps and stash for repeated retrievals. GORAM utilizes Square-Root ORAM with stash-size $T = \sqrt{n}$.

3. Query Protocols and MPC Implementation

A typical end-to-end query proceeds as follows for, e.g., a 1-hop neighbors count query $Q_{\mathrm{count}}(v)$:

1. Client secret-shares the vertex ID $v$ among $S_1$, $S_2$, $S_3$.
2. Compute the chunk index $r = \lceil v/k \rceil$ obliviously.
3. Access $\mathsf{VORAM}.\mathsf{access}(r)$ to fetch the partition for $v$.
4. Within this partition, use MPC primitives (EQ, AND) to identify edges with $u = v$, and sum indicators to count neighbors.
5. Return the secret-shared count to the client.

Edge-existence queries compute the block index $(p, q)$ for $(u, v)$, fetch the relevant block via $\mathsf{EORAM}$, and apply MPC reduction to determine existence. The ShuffleMem protocol is used for random permutation in ORAM construction, running in $O(nB)$ MPC cost and $O(1)$ rounds for total bit-length $nB$.

4. Privacy, Adversary Model, and Security Guarantees

The security regime is based on three semi-honest, non-colluding servers, tolerating up to one corrupted server. The system is designed with strict input privacy (edges and query keys secret-shared, so no server learns actual content or targets), query privacy (servers never learn which vertex or edge is queried), and ORAM-style access privacy (partition index access indistinguishable from random). Only public values ($|V|$, block counts) and padded sizes are leaked, with all other graph statistics masked by dummy edges.

The composition theorem holds for the secure composition of MPC protocols and distributed ORAM under UC or simulation-based definitions. The design achieves partial composability: given correct implementations of 3-party secret-sharing, MPC primitives (such as EQ, ADD, AND), and DORAM with ShuffleMem, GORAM realizes an ideal functionality that leaks only the allowed public parameters.

5. Performance Characteristics

Letting $b = \lceil |V|/k \rceil$ and block-size $l \approx |E|/b$, the initialization costs are:

• $O(|E_i|)$ local work per provider for block preparation and padding,
• $O(N(b^2l)\log l)$ MPC work for global merging and sorting,
• $O(b^2l)$ work for DORAM index construction using ShuffleMem.

For each query, the dominant costs are:

• ORAM-indexed partition access ($O(P T \log(n/T))$ MPC gates, $O(\log(n/T))$ rounds, $n = b$ or $b^2$),
• Partition processing ($O(l)$ vectorized gates, $O(\log l)$ rounds for aggregation).

Empirical results include:

• On synthetic graphs (up to $|V| = 2^{15}$, $|E| \approx 10^7$), ego-centric and edge-existence queries complete in 22–133 ms per query, outpacing naive approaches by factors of 50–700 for edge-list scan and 10–30 for adjacency ORAM scan.
• On the Twitter graph with 41.6 million vertices and 1.4 billion edges, single-core timings were: initialization (~3 min), edge-existence (58 ms), neighbors count (~0.5 s), neighbors get (35.7 s), with parallelism reducing neighbors get to ~2.5 s. Bandwidth savings reach 99.9% over full-scan protocols, with overall >70% average communication reduction (Fan et al., 2024).

6. Limitations, Strengths, and Domains of Application

Key strengths:

• Scale: Demonstrates the first practical billion-edge private graph query system compatible with MPC.
• Efficiency: Sub-linear per-query complexity via partitioned ORAM rather than edge-level obliviousness.
• Privacy: Input, query, and access pattern privacy except for block sizes and counts.
• Modularity: Flexible composition with different MPC and DORAM backends.

Principal limitations:

• Static Setting: No support for dynamic graph mutations without complete reinitialization or more advanced dynamic ORAMs.
• Query Expressiveness: Designs for ego-centric (1-hop) and edge-existence queries, requiring further indexing for complex paths or subgraph motifs.
• Block Size Effects: Large $k$, high density graphs lead to sizable blocks and increased MPC workload, though asymptotically less than full-graph scans.
• Assumption of Three Servers: Security model requires honest-majority among computation servers; byzantine or two-party robustness would demand new protocol design.

Application domains include:

• Financial fraud detection across federated transaction graphs (private “who paid whom” and neighbor statistics),
• Secure social network analytics without centralizing social connections,
• Privacy-preserving contact tracing in federated healthcare graphs,
• Any federated setting in which graph structure is secret, providers distrust each other, and client queries must remain hidden.

GORAM establishes that partition-based, ORAM-indexed graph storage enables scalable, privacy-preserving ego-centric analytics feasible for previously intractable large-scale federated environments (Fan et al., 2024).