Bandwidth-Efficient Two-Server ORAMs with O(1) Client Storage

TL;DR

The paper tackles the challenge of secure access pattern privacy in outsourced storage with practical bandwidth and constant client storage using two-server ORAM. It introduces two schemes, Cforam and Cforam+, built on a hierarchical layout with a pairwise-area storage and DPF-based read-only and write-only PIR, complemented by a cyclic-shift optimization in Cforam+. The authors provide detailed storage structures, protocol descriptions, and amortized overhead analyses, and demonstrate through implementation and benchmarks that their schemes achieve up to $2$–$4\times$ bandwidth improvements over LO13 and $16$\–$64\times$ improvements over AFN17 and KM19, with WAN latency around $1$ second for modest database sizes. The results indicate strong practical potential for lightweight clients, while highlighting the remaining cost of linear symmetric-key computations and avenues for GPU acceleration or deployment in distributed settings as future work.

Abstract

Oblivious RAM (ORAM) allows a client to securely retrieve elements from outsourced servers without leakage about the accessed elements or their virtual addresses. Two-server ORAM, designed for secure two-party RAM computation, stores data across two non-colluding servers. However, many two-server ORAM schemes suffer from excessive local storage or high bandwidth costs. To serve lightweight clients, it is crucial for ORAM to achieve concretely efficient bandwidth while maintaining O(1) local storage. Hence, this paper presents two new client-friendly two-server ORAM schemes that achieve practical logarithmic bandwidth under O(1) local storage, while incurring linear symmetric key computations. The core design features a hierarchical structure and a pairwise-area setting for the elements and their tags. Accordingly, we specify efficient read-only and write-only private information retrieval (PIR) algorithms in our schemes to ensure obliviousness in accessing two areas respectively, so as to avoid the necessity of costly shuffle techniques in previous works. We empirically evaluate our schemes against LO13 (TCC'13), AFN17 (PKC'17), and KM19 (PKC'19) in terms of both bandwidth and time cost. The results demonstrate that our schemes reduce bandwidth by approximately 2-4x compared to LO13, and by 16-64x compared to AFN17 and KM19. For a database of size 2^14 blocks, our schemes are over 64x faster than KM19, while achieving similar performance to LO13 and AFN17 in the WAN setting, with a latency of around 1 second.

Figures (9)

• Figure 2: Two-server ORAM system model. In the setup phase, the client sends the distributed structures to two servers. In the access phase, the client requests an element and retrieves results from two servers. The client may reconstruct partial structures during the access phase, e.g., evict a path for tree-based ORAM or rebuild a level for hierarchical ORAM.
• Figure 3: The server storage of our construction. Each server stores a replicated element area and a secret-shared tag area spanning $L-\ell+1$ levels. For each level $i\in\{\ell,\ldots,L\}$, the server storage includes element tables $ET_{i}=(ET_{i0},ET_{i1})$ and tag tables $TT_{i}=(TT_{i0},TT_{i1})$. Additionally, the $\ell$th level contains an element stash and a buffer, a tag stash and a buffer.
• Figure 4: The overall architecture of our ORAM constructions.
• Figure 5: An example of Cforam with four levels for different phases. The diagram uses following colors to represent the components: (i) White: Empty levels. (ii) Orange: Non-empty levels that are occupied. (iii) Light Blue: Positions for element reading. (iv) Dark Blue: Positions for tag writing.
• Figure 6: Examples of optimized reading and writing. For ease of understanding, we only display the flow of the second table at the $i$th level. The diagram uses these colors to represent the components: (i) Green: A light green block represents bit $0$, while a dark green block represents bit $1$. Multiple light green blocks and one dark green block form a secret-shared vector after $DPF.Eval$. (ii) Yellow: Each element in hash table. (iii) Red: Each tag in hash table. (iv) Orange: The random tag $\tau_{r}$ of Protocol \ref{['AlgOpWrite']}.

Theorems & Definitions (21)

• Definition 1: Syntax of Two-table Cuckoo Hashing
• Theorem 1: Build failure probability of cuckoo hashing cryptoeprint:2021/447
• Definition 2: Syntax of DPF
• Definition 3: Syntax of Read-only PIR
• Definition 4: Syntax of Write-only PIR
• Definition 5: Two-server ORAM
• Definition 6: Oblivious simulation security
• Remark 1
• Remark 2
• Lemma 1