Reducing the servers' computation in private information retrieval: PIR with preprocessing
Reducing the servers' computation in private information retrieval: PIR with preprocessing
复制标题
DOI:
10.1007/s00145-004-0134-y
复制
发表时间:
2004-03-01
影响因子:
3
通讯作者:
Malkin, T
中科院分区:
文献类型:
--
作者:
Beimel, A;Ishai, Y;Malkin, T
Private information retrieval (PIR) enables a user to retrieve a data item from a database, replicated among one or more servers, while hiding the identity of the retrieved item. This problem was suggested by Chor, Goldreich, Kushilevitz, and Sudan in 1995, and since then efficient protocols with sub-linear communication were suggested. However, in all these protocols the servers' computation for each retrieval is at least linear in the size of entire database, even if the user requires only a single bit.In this paper we study the computational complexity of PIR. We show that in the standard PIR model, where the servers hold only the database, linear computation cannot be avoided. To overcome this problem we propose the model of PIR with preprocessing: Before the execution of the protocol each server may compute and store polynomially many information bits regarding the database; later, this information should enable the servers to answer each query of the user with more efficient computation.We demonstrate that preprocessing can significantly save work. In particular. we construct for any constants k greater than or equal to 2 and epsilon > 0: (1) a k-server protocol with O(n(1/(2k-1))) communication, O(n/log(2k-2) n) work, and O(n(1+epsilon)) storage; (2) a k-server protocol with O(n(1/k+epsilon)) communication and work and n(O(1)) storage; (3) a computationally private k-server protocol with O(n(epsilon)) communication, O(n(1/k+epsilon)) work, and n(O(1)) storage; and (4) a protocol with a polylogarithmic number of servers, polylogarithmic communication and work, and O(n(1+epsilon)) storage. On the lower bounds front, we prove that the product of the extra storage used by the servers (i.e., in addition to the length of the database) and the expected amount of work is at least linear in n. Finally, we suggest two alternative models to saving computation, by hatching queries and by allowing a separate off-line interaction per future query.