Short Paper: Industrial Feasibility of Private Information Retrieval

Angela J

¨

aschke

1

, Bj

¨

orn Grohmann

2

, Frederik Armknecht

1

and Andreas Schaad

2

1

University of Mannheim, Germany

2

Huawei German Research Institute, Darmstadt, Germany

Keywords:

Private Information Retrieval, Industrial Use Case, Practicability, Overview, Implementation.

Abstract:

A popular security problem in database management is how to guarantee to a querying party that the database

owner will not learn anything about the data that is retrieved — a problem known as Private Information

Retrieval (PIR). While a variety of PIR schemes are known, they are rarely considered for practical use cases

yet. We investigate the feasibility of PIR in the telecommunications world to open up data of carriers to

external parties. To this end, we ﬁrst provide a comparative survey of the current PIR state of the art (including

ORAM schemes as a generalized concept) as well as implementation and analysis of two PIR schemes for the

considered use case. While an overall conclusion is that PIR techniques are not too far away from practical

use in speciﬁc cases, we see ORAM as a more suitable candidate for further R&D investment.

1 BACKGROUND AND

MOTIVATION

The telecommunications world is undergoing a tran-

sition where carriers not only provide services such as

telephony or internet access, but also attempt to mon-

etize the huge amount of data associated with their

subscribers’ activity. Analyzing data like call statis-

tics or roaming behavior can be used to offer specif-

ically tailored services and packages. The combi-

nation of such data with other data from 3

rd

parties

can potentially result in even more value. As such,

one direction is to open up the existing databases to

subscribing external parties. In fact, it may well be

the case that two rivaling carriers allow each other

to query their subscriber databases, e.g. for detect-

ing fraudulent activities or faults in the network. An-

other real-world scenario is that of answering to the

demands of public authorities wanting to verify that

a user has been making a call at a certain time or to

assess whether a certain IMEI or IMSI is part of the

carriers subscriber base.

An open practical problem is how to guarantee

to the querying party that the database owner will

not learn anything about the data that is retrieved

— a problem known as Private Information Retrieval

(PIR) (Goldreich and Ostrovsky, 1996). Accordingly,

we assessed the feasibility of PIR schemes to support

such use cases, where the typical database consists of

400.000-800.000 entries of IMEIs and/or IMSIs. This

paper provides a comparative survey of PIR schemes

as part of Section 2. We then discuss two schemes

in detail, i.e. a Trapdoor Group scheme in Section

3.1 and an ORAM approach in Section 3.2. We pro-

vide detailed performance and runtime analysis data

in Section 4.

2 OVERVIEW AND

COMPARISON OF EXISTING

SCHEMES

The trivial solution for a user who wants to query a

database without the database server learning about

the query is to retrieve the entire database from the

server and ignore all except the queried entries. Of

course, this is very inefﬁcient in terms of communica-

tion, but very efﬁcient regarding computational effort

because there is (almost) none. Thus, the incurred ef-

fort provides a good starting point in that any new so-

lution should have less communication than this triv-

ial solution, often trading this for computational com-

plexity in some form.

We split existing works that realize some form

of private information retrieval into four main ap-

proaches. In a forthcoming paper, we present a de-

tailed overview of the different schemes, here we

only categorize the schemes into these high-level ap-

proaches. Some of the mentioned schemes have also

Jäschke, A., Grohmann, B., Armknecht, F. and Schaad, A.

Short Paper: Industrial Feasibility of Private Information Retrieval.

DOI: 10.5220/0006382003950400

In Proceedings of the 14th International Joint Conference on e-Business and Telecommunications (ICETE 2017) - Volume 4: SECRYPT, pages 395-400

ISBN: 978-989-758-259-2

Copyright © 2017 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved

395

been presented in (Ostrovsky and Skeith(III), 2007)

and (Olumoﬁn and Goldberg, 2011), and some obser-

vations about computational complexity can be found

in (Gasarch, 2004) and (Sion and Carbunar, 2007).

• Homomorphic Approaches: The user masks

(e.g., homomorphically encrypts) the queried in-

dex, and the server algebraically combines all in-

dices with the database entries to obtain a masked

version of only the queried entry. The user then

removes the mask to obtain the result. Publi-

cations following this general idea are (Kushile-

vitz and Ostrovsky, 1997), (Chang, 2004), (Mel-

chor et al., 2016) (Group Homomorphic), (Tros-

tle and Parrish, 2010) (Trapdoor Group), (Kiayias

et al., 2015; Lipmaa, 2009; Ishai and Paskin,

2007) (Branching Programs), (Melchor and Ga-

borit, 2007) (Lattice-based) and (Dor

¨

oz et al.,

2014) (FHE-based).

• ORAM Approaches: Comes from the ﬁeld of

software protection, but can also be used to pro-

tect privacy in databases. ORAM requires a

slightly different setup: The database must be en-

crypted and thus there must be some key manage-

ment mechanism. In contrast to pure PIR, ORAM

offers the added option of writing, i.e., changing

or adding entries. Publications based on ORAM

are (Mayberry et al., 2014; Stefanov et al., 2013;

Ma et al., 2016) (ORAM-Tree), (Devadas et al.,

16 A) (Onion-ORAM), (Apon et al., 2014) (FHE-

ORAM) and (Lorch et al., 2013) (Parallel-Tree-

ORAM).

• Garbled Approaches: Since PIR consists of two

parties (the user and the server) trying to compute

a function (the correct database entry) without the

server learning the users input (the query index),

it is natural to look to Multiparty-Computation,

where two or more parties compute a function

together without learning any input except their

own, and the result of the computation. Publica-

tions involving this approach are (Lu and Ostro-

vsky, 2013; Gentry et al., 2014a; Gentry et al.,

2014b).

• Other Approaches: The ϕ-Hiding Approach

(Cachin et al., 1999), the Trapdoor Permutation

Approach (Kushilevitz and Ostrovsky, 2000), and

the Sender Anonymity Approach (Trostle and Par-

rish, 2010).

Table 1 compares the schemes from the above ap-

proaches, indicating a particularly good value with a

(light) green background and particularly unfavorable

aspects with a (darker) red background. The aspects

considered are Comm

U

(communication from user

to the server), Comm

S

(communication from server

to the user), Comp

U

(user computation effort) and

Comp

S

(server computation effort). The variables

used are:

• n is the number of database elements

• B is the block size

• λ is the security parameter

• M (resp. C) is the message (resp. ciphertext)

space of the encryption scheme

• m is a ﬁnite group order

The leftmost column denotes the approach as pre-

sented above: H for homomorphic, O for ORAM, G

for garbled and “-” if none apply.

3 CHOOSING AND OPTIMIZING

To test performance for the use cases described in

Section 1, we implemented two approaches — one

homomorphic and one ORAM-approach, as these dif-

fer greatly, yet can both solve our problem of PIR.

Concretely, we chose and modiﬁed a Trapdoor Group

Scheme based on (Trostle and Parrish, 2010) and the

Path-ORAM Scheme (Stefanov et al., 2013) for their

conceptual simplicity.

3.1 The (Optimized) Trapdoor Group

Scheme

The original scheme (Trostle and Parrish, 2010) only

allows retrieval of an entire row (i.e.,

√

n out of n)

of database entries, which we extend to allow single-

entry-retrieval and minimize communication. We

present this optimized scheme as a protocol:

Database Structure: n elements of Z

N

arranged as

a ln(n)-dimensional array with entries x

i

1

,...,i

ln(n)

,i

j

=

1,... ,n

1/ln(n)

for j = 1,...,ln(n).

Prerequisites: We assume that we work in the group

(Z

m

,+) and that m and N are coprime.

Queries: Suppose the user wants to query the element

x

i

∗

1

,...,i

∗

ln(n)

.

1. The user selects m as the group order above de-

pending on the required security level, but at least

m > N

dln(n)e

·n ·(N −1).

2. The user randomly selects secret b

j

∈ Z

∗

m

, j =

1,. .. ,ln(n) and ln(n) ·n

1/ln(n)

coefﬁcients e

i, j

,i =

1,. .. ,n

1/ln(n)

, j = 1, .. ., ln(n) with three restric-

tions:

i. e

i, j

<

ln(n)

q

m

n·(N−1)

for all (i, j).

ii. For j = 1,...,ln(n): If i

∗

j

6= i,e

i, j

is a multiple

of N (i.e., e

i

= a

i

·N for some a

i

).

SECRYPT 2017 - 14th International Conference on Security and Cryptography

396

Table 1: A comparison of different PIR solutions.

Idea Scheme Comm

U

Comm

S

Comp

U

Comp

S

Comments Code

- Trivial 1 n ·B - - - x

H (Chang, 2004), (Melchor

et al., 2016), [Kushilevitz

and Ostrovsky, 1997]

(Group Homomorphic)

√

n ·log(|C|)

√

n ·

log(|C|)

√

n encryptions, 1

decryption

n scalar ciphertext

multiplications,

√

n ·log(

√

n) ciphertext

additions

C is the ciphertext space,

log(|C|) is the size of a

ciphertext.

x

H [Trostle and Parrish, 2010]

(Trapdoor Group)

√

n ·log

2

(m) O(

√

n ·

log

2

(m) +

n)

Generating m,

√

n

modular exponentiations/

multiplications +

√

n

discrete logs

n integer exponentiations/

multiplications

+

√

n ·log(

√

n) integer

multiplications/ additions

Group order m can be chosen

by user such that discrete log

is efﬁcient (e.g., additive

group). Several queries can

be sent at once, so amortized

cost lower.

Not

pub

lic

H This paper (Optimized

Trapdoor Group)

ln(n)·n

1/ln(n)

·

log

2

(m)

O((log

2

(

m))

ln(n)

+

√

n)

Generating m,

ln(n) ·n

1/ln(n)

modular

exponentiations/

multiplications +ln(n)

discrete logs

O(n) integer

exponentiations/

multiplications +O(n)

integer multiplications/

additions

Group order m can be chosen

by user such that discrete log

is efﬁcient (e.g., additive

group).

Not

pub

lic

H (Kiayias et al., 2015),

(Lipmaa, 2009), [Ishai and

Paskin, 2007] (Branching

Programs)

log(n) ·

√

n ·

log(|C|)

√

n ·

log(|C|)

log(n) encryptions and

decryptions

For k-ary branching

program (optimal k = 5):

n multiplications,

n

k

·

√

k ·log(

√

k) additions

C is the ciphertext space of

the Damg

˚

ard-Jurik

cryptosystem.

x

H [Melchor and Gaborit,

2007] (Lattice-based)

O(n ·N

2

·m) N ·m O(n ·N

x

) where x

depends on the matrix

multiplication algorithm

used, mostly a bit less

than 3.

2n ·N

2

multiplications

and 2N ·log(n·N)

additions.

Recommended as N = 50. X

C++

H (Dor

¨

oz et al., 2014)

(FHE-based)

log(C) log(C) One encryption, one

decryption

Depends on the concrete

FHE scheme used, likely

very expensive.

This is one extreme where

the server does all the work

and the user almost none.

x

O [Mayberry et al., 2014],

(Stefanov et al., 2013),

(Ma et al., 2016)

(ORAM-Tree)

O(log(n)

3

+

log(n)

2

·

log(|C|))

O(log(n)

3

+

log(n)

2

·

log(|C|))

log(n) recryptions for

each operation

- Supports writing as well.

Could be combined with

FHE to reduce user

communication and transfer

computation to the server.

X

Java

O (Devadas et al., 16 A)

(Onion-ORAM)

O(log(n)) O(B)

˜

O(B ·log

4

(n))

˜

ω(B ·log

4

(n)) The block size B needs to be

very large

˜

Ω(log

5

(n))

.

x

O (Apon et al., 2014)

(FHE-ORAM)

log(|C|) ·|op|,

op = ORAM

operation

written as

circuit

log(|C|) Convert operation into

circuit, encrypt values,

decrypt result.

Again depends on

concrete FHE scheme,

likely very expensive.

This seems worse than the

trivial FHE approach above,

but ORAM has a

write-operation which pure

PIR does not.

x

O (Lorch et al., 2013)

(Parallel-Tree-ORAM)

log(n) O(B) - log(n) recryptions for

each operation, but

parallelized.

Tree-ORAM outsourced to

server using secure

coprocessors (with which the

user communicates in

non-oblivious fashion).

Not

pub

lic

G Trivial Garbled Circuit >> n O(B) Transform function into

Boolean circuit, generate

4 keys for each gate,

compute 2 MACS for

each gate.

Evaluate the Boolean

circuit with the garbled

keys.

This is worse than the trivial

solution in every aspect

except server

communication.

x

G [Lu and Ostrovsky, 2013],

(Gentry et al., 2014a),

(Gentry et al., 2014b)

(Garbled RAM)

O(RAM-

execution time

of query)

O(B) Garble the query

(O(RAM-execution time

of query))

Evaluate garbled query

(O(RAM-execution time

of query))

The user also has to garble

and upload the database once

in the beginning.

x

- (Cachin et al., 1999)

(ϕ-Hiding)

log(n) + λ λ Effort of computing

ϕ-hiding m plus 2

modular exponentiations

Hamming-weight(n)

modular exponentiations

λ is logarithmic in n, with

recommended settings total

communication is

O(log

8

(n)).

Pseu

do

code

- [Kushilevitz and

Ostrovsky, 2000]

(Trapdoor Permutation)

O(B) n−

n

2B

(< O(n)

while

n > B

2

)

O(B) O(n ·B) User computation depends

on the trapdoor functions and

hardcore predicates used,

assumed O(n).

x

- [Trostle and Parrish, 2010]

(Sender Anonymity)

(λ + 1) ·

√

n (λ+ 1) ·

√

n

O(log(λ) ·

√

n) O(Q ·(λ + 1) ·

√

n), Q is

number of separate

queries sent (> 1!)

Very likely insecure, as

summing up all subqueries

yields sum of separate query

vectors.

Not

pub

lic

iii. For j = 1,. .. ,ln(n): If i

∗

j

= i,e

i, j

has the form

1 + a

l

·N for some a

l

.

3. The user sends the b

j

i

= b

j

· e

i, j

mod m to the

database. This constitutes the query.

Database Action: For j = 1,. .. ,ln(n): The database

computes x

i

1+ j

,...,i

ln(n)

:=

∑

n

1/ln(n)

k=1

b

j

k

·x

k,i

1+ j

,...,i

ln(n)

and

sends x := x

i

ln(n)+1

to the user. Operations in this step

are done over the integers, as the database does not

know the group order.

User Decoding: For j = 1, .. ., ln(n), the user sets

x = x ·(b

j

)

−1

mod m and transforms the result to N-

ary encoding. Then the least signiﬁcant digit is the

requested database item x

i

∗

1

,...,i

∗

ln(n)

.

Security: In this new protocol, the size limit of the

e

i

’s has changed from the original version. This

requirement ensures getting the correct result with-

out wrapping around mod m in the decoding phase.

The security of the original scheme relies on the as-

sumption that given the

√

n PIR request elements

Short Paper: Industrial Feasibility of Private Information Retrieval

397

(b

1

,. .. ,b

√

n

), where b

i

= b · e

i

mod m and the e

i

’s

are chosen according to the constraints detailed above

(with the a

i

’s in 2.ii. and 2.iii. selected uniformly

at random), any computationally bounded adversary

can output the correct m only with negligible proba-

bility. Indicators for the hardness of this assumption

(called Hidden Modular Group Order Assumption),

i.e., how much information about the group order is

leaked by the queries, are presented in the original

paper (Trostle and Parrish, 2010), along with a reduc-

tion from the PIR protocol to this assumption. For

our improved scheme, it can easily be veriﬁed that

√

n > ln(n) ·n

1/ln(n)

for n ≥ 213. As databases are

generally much larger than 213 elements, we can base

security on the security of the original scheme, since

we will be sending less query elements and thus leak-

ing at most as much data as the original scheme.

3.2 The Path-ORAM Scheme

The second solution we implemented is the Path-

ORAM scheme from (Stefanov et al., 2013) with

non-recursive position map storage. We describe the

scheme with some parameters as we implemented

them instead of the generic version:

Database Structure: The database is held in a binary

tree of height L = dlog

2

(n)e with 2

L

leaves. Each

leaf (called a “bucket”) holds up to 5 database en-

tries (and is ﬁlled with dummy entries if it contains

less). There are far more buckets than database el-

ements. The bucket is encrypted by the user with

AES in CBC mode, where each database entry con-

sists of 1 or 2 AES-Blocks (128 bits each) depend-

ing on the chosen parameter setting (see Section 4).

Thus, each bucket contains 5 or 10 AES Blocks plus

the IV, so 6 or 11 blocks in total. Also, the user main-

tains a local stash S (which acts as a temporary stor-

age space) and a lookup table (called “position map”)

mapping database blocks to the leaves of the binary

tree. We assume that the database is already initial-

ized, as setup is rather tedious and must only be done

once before the ﬁrst query is made, making it irrele-

vant for performance comparisons.

Queries: To retrieve an entry, the user looks up what

tree leaf the data block is mapped to in the position

map and reads the entire path from root to leaf into the

local stash S (which may contain some elements from

previous queries), as the entry will be in some bucket

on this path (or in the stash). The entry is mapped to a

new leaf randomly and the data is replaced in case of

a write operation. Then, all elements in the stash are

reencrypted and written to the server in a bottom-up

manner: Each entry in the stash is placed in a bucket

on the path to the (old) leaf as far away from the root

as possible, guaranteeing that the maximum amount

of blocks can be placed into the tree. The bucket is

ﬁlled up with dummy blocks and encrypted with AES

in CBC-mode with a random IV. Sometimes, some

elements from the stash can’t be placed into the tree,

these remain in the client stash and are placed into

a bucket in a future query. If too many of these el-

ements accumulate and the stash overﬂows, we say

that the ORAM has failed. We chose a stash size of

220 blocks.

Security: We implemented the scheme without

changing it, so the original security analysis holds.

4 PERFORMANCE

We now present the performance of our two chosen

schemes. Times were measured on an Intel Core i5-

4570 CPU with 3.20GHz and constitute average val-

ues, and the number of database entries was derived

from our use case (400.000 − 800.000 with some

smaller numbers for scale). The entries are random

numbers of lengths 256 (resp. 128) bits to simulate

the IMEIs and (or) IMSIs. The AES implementa-

tion in the ORAM scheme was wolfcrypt. Regard-

ing memory

1

for our use case, the Trapdoor Group

scheme requires a group order m of at least 3756 bits.

This implies a server memory of about 25.6MB for

the database, and about 1.317GB for storing interme-

diate results, so roughly 1.345GB in total. The mem-

ory requirement on the user side is only about 34kB.

In the ORAM-scheme, user memory is about 2.1MB,

whereas server memory strongly depends on the num-

ber of entries and got so large that we could not supply

data for 800.000 entries because our allotted memory

limit was exceeded.

For the more traditional PIR metrics, we split the

performance into three main components: Commu-

nication (Figure 1a), user computational effort (1b)

and server computational effort (1c) and plot the ef-

fort for different numbers of database entries. In each

diagram, the dotted plots represent entries of length

256 bits, and the solid plots are entries of length

128 bits. The green plots always correspond to the

ORAM scheme, and the red plots to the Trapdoor-

Group scheme. In the communication ﬁgure, red is

the amount of data sent from the user to the server

in the Trapdoor-Group scheme, blue is the amount of

data sent from the server to the user in the Trapdoor-

Group scheme, and green is the amount of data sent

from user to server or vice versa (as these values

are equal) in the ORAM scheme. User computa-

tion encompasses decrypting, reading and encrypting

1

Theoretical results, not actually measured.

SECRYPT 2017 - 14th International Conference on Security and Cryptography

398

0 200 400

600

800

0

100

200

300

Number of Records (x1000)

Communication (KBits)

(a) Communication.

0 200 400

600

800

0

1

2

3

4

5

Number of Records (x1000)

Time in milliseconds (ms)

(b) User Comp.

0 200 400

600

800

0

1

2

3

4

Number of Records (x1000)

Time in seconds (s)

(c) DB Comp.

Figure 1: Performance of the two approaches: Red (top 2 lines) is Trapdoor-Group (user to server in communication), green

(bottom 2 lines) is ORAM, blue (middle 2 lines) is server to user communication (Trapdoor-Group). Dotted is 256 bit, solid

is 128 bit database entries.

0 100 200 300 400

500 600

700 800

15

20

25

Number of Records (x1000)

Time in milliseconds (ms)

Figure 2: User setup without prime generation for 128 (red)

and 256 (blue) bit inputs.

in the ORAM scheme, and the decoding step in the

Trapdoor-Group scheme

2

.

5 CONCLUSION AND FUTURE

WORK

We see that ORAM performs better in all aspects,

even though the Trapdoor-Group protocol actually

performs worse in terms of user computation than

Figure 1b implies (see Footnote 2). Thus, for the use

case of this paper, ORAM is the better solution —

provided that the server has enough memory to store

the tree. If, however, memory is the constraining fac-

tor rather than speed (which seems unlikely in today’s

world), the Trapdoor Group protocol would be the

2

There is a user setup phase which incurs computational

effort but was not included in Figure 1b. The reason is

that m was computed as a prime by calling nextprime()

from the GMP-library in our code. This function’s run-

time varies enormously, dominating total time. This could

be easily be circumvented in reality once the parameters

of the database are set, e.g., by picking m randomly from

a large list of primes, or choosing m as not prime and im-

plementing constraints on the secret values instead. Either

way, this additional cost really needs to be added to the

time in Figure 1b. The time for user setup without this

prime generation can be seen in Figure 2.

better choice both for user and for the server.

For future work, an interesting aspect could be the

“levels” observed in Figure 1a for the Trapdoor Group

scheme (i.e., the values for 200,000 and 400, 000

entries seem similar, as do those for 600, 000 and

800,000), which we suppose comes from the dln(n)e

exponent in the constraint for the size of the group

order m (where n is the number of database entries).

REFERENCES

Apon, D., Katz, J., Shi, E., and Thiruvengadam, A. (2014).

Veriﬁable oblivious storage. In PKC.

Cachin, C., Micali, S., and Stadler, M. (1999). Compu-

tationally private information retrieval with polyloga-

rithmic communication. In EUROCRYPT.

Chang, Y. (2004). Single database private information re-

trieval with logarithmic communication. In ACISP.

Devadas, S., van Dijk, M., Fletcher, C. W., Ren, L., Shi, E.,

and Wichs, D. (2016-A). Onion ORAM: A constant

bandwidth blowup oblivious RAM. In TCC.

Dor

¨

oz, Y., Sunar, B., and Hammouri, G. (2014). Bandwidth

efﬁcient PIR from NTRU. In FC Workshops BITCOIN

and WAHC.

Gasarch, W. I. (2004). A survey on private information re-

trieval (column: Computational complexity). Bulletin

of the EATCS.

Gentry, C., Halevi, S., Lu, S., Ostrovsky, R., Raykova, M.,

and Wichs, D. (2014a). Garbled RAM revisited. In

EUROCRYPT.

Gentry, C., Halevi, S., Raykova, M., and Wichs, D. (2014b).

Outsourcing private RAM computation. In FOCS.

Goldreich, O. and Ostrovsky, R. (1996). Software protec-

tion and simulation on oblivious rams. J. ACM.

Ishai, Y. and Paskin, A. (2007). Evaluating branching pro-

grams on encrypted data. In TCC.

Kiayias, A., Leonardos, N., Lipmaa, H., Pavlyk, K., and

Tang, Q. (2015). Optimal rate private information re-

trieval from homomorphic encryption. PoPETs.

Short Paper: Industrial Feasibility of Private Information Retrieval

399

Kushilevitz, E. and Ostrovsky, R. (1997). Replication is

NOT needed: SINGLE database, computationally-

private information retrieval. In FOCS.

Kushilevitz, E. and Ostrovsky, R. (2000). One-way trap-

door permutations are sufﬁcient for non-trivial single-

server private information retrieval. In EUROCRYPT.

Lipmaa, H. (2009). First CPIR protocol with data-

dependent computation. In ICISC.

Lorch, J. R., Parno, B., Mickens, J. W., Raykova, M., and

Schiffman, J. (2013). Shroud: ensuring private access

to large-scale data in the data center. In FAST.

Lu, S. and Ostrovsky, R. (2013). How to garble RAM pro-

grams. In EUROCRYPT.

Ma, Q., Zhang, J., Peng, Y., Zhang, W., and Qiao, D.

(2016). SE-ORAM: A storage-efﬁcient oblivious

RAM for privacy-preserving access to cloud storage.

In CSCloud.

Mayberry, T., Blass, E., and Chan, A. H. (2014). Efﬁcient

private ﬁle retrieval by combining ORAM and PIR. In

NDSS.

Melchor, C. A., Barrier, J., Fousse, L., and Killijian, M.

(2016). XPIR : Private information retrieval for ev-

eryone. PoPETs.

Melchor, C. A. and Gaborit, P. (2007). A lattice-based

computationally-efﬁcient private information retrieval

protocol. IACR Cryptology ePrint Archive, 446.

Olumoﬁn, F. and Goldberg, I. (2011). Revisiting the com-

putational practicality of private information retrieval.

In FC.

Ostrovsky, R. and Skeith(III), W. E. (2007). A survey of sin-

gle database PIR: techniques and applications. PKC.

Sion, R. and Carbunar, B. (2007). On the practicality of

private information retrieval. In NDSS.

Stefanov, E., van Dijk, M., Shi, E., Fletcher, C. W., Ren,

L., Yu, X., and Devadas, S. (2013). Path ORAM: an

extremely simple oblivious RAM protocol. In CCS.

Trostle, J. T. and Parrish, A. (2010). Efﬁcient computation-

ally private information retrieval from anonymity or

trapdoor groups. In ISC.

SECRYPT 2017 - 14th International Conference on Security and Cryptography

400