Repository landing page

We are not able to resolve this OAI Identifier to the repository landing page. If you are the repository manager for this record, please head to the Dashboard and adjust the settings.

Sub-logarithmic Distributed Oblivious RAM with Small Block Size

Abstract

Oblivious RAM (ORAM) is a cryptographic primitive that allows a client to securely execute RAM programs over data that is stored in an untrusted server. Distributed Oblivious RAM is a variant of ORAM, where the data is stored in m>1m>1 servers. Extensive research over the last few decades have succeeded to reduce the bandwidth overhead of ORAM schemes, both in the single-server and the multi-server setting, from O(N)O(\sqrt{N}) to O(1)O(1). However, all known protocols that achieve a sub-logarithmic overhead either require heavy server-side computation (e.g. homomorphic encryption), or a large block size of at least Ω(log3N)\Omega(\log^3 N). In this paper, we present a family of distributed ORAM constructions that follow the hierarchical approach of Goldreich and Ostrovsky [GO96]. We enhance known techniques, and develop new ones, to take better advantage of the existence of multiple servers. By plugging efficient known hashing schemes in our constructions, we get the following results: 1. For any number m2m\geq 2 of servers, we show an mm-server ORAM scheme with O(logN/loglogN)O(\log N/\log\log N) overhead, and block size Ω(log2N)\Omega(\log^2 N). This scheme is private even against an (m1)(m-1)-server collusion. 2. A three-server ORAM construction with O(ω(1)logN/loglogN)O(\omega(1)\cdot\log N/\log\log N) overhead and a block size almost logarithmic, i.e. Ω(log1+ϵN)\Omega(\log^{1+\epsilon}N). We also investigate a model where the servers are allowed to perform a linear amount of light local computations, and show that constant overhead is achievable in this model, through a simple four-server ORAM protocol. From theoretical viewpoint, this is the first ORAM scheme with asymptotic constant overhead, and polylogarithmic block size, that does not use homomorphic encryption. Practically speaking, although we do not provide an implementation of the suggested construction, evidence from related work (e.g. [DS17]) confirms that despite the linear computational overhead, our construction is practical, in particular when applied to secure computation

Similar works

This paper was published in Cryptology ePrint Archive.

Having an issue?

Is data on this page outdated, violates copyrights or anything else? Report the problem now and we will take corresponding actions after reviewing your request.