►
Description
This talk was given at IPFS Camp 2022 in Lisbon, Portugal.
A
Hello:
everyone,
my
name
is
mithi
majmuda
and
I'm.
A
PhD
student
in
the
cresp
lab
at
the
University
of
Waterloo.
Today
I
will
be
presenting
our
work
dhtpir,
which
was
done
in
collaboration
with
Stan
garler
and
Ian
Goldberg
from
the
cresp
lab.
Here
we
provide
an
interface
to
privately
retrieve
documents
over
distributed
hash
tables
or
dhts.
A
We
have
published
a
short
paper
in
the
double
pass
Workshop
as
a
part
of
CCS
2021
and
we'll
also
published
an
extended
archive
report.
Protocol
Labs
has
called
for
proposals
on
private
retrieval
of
data
and
Shannon
Russell
and
I
have
submitted
an
application
and,
at
the
end
of
this
talk,
I'll
be
discussing
extending
dhdpir
into
ipfs.
Through
this
proposal,
I
thank
will
and
Janice
for
providing
me
with
this
opportunity
to
present
the
httpir.
A
So
everyone
here
knows
that
ipfs
is
a
peer-to-peer
application
that
is
based
on
distributed
hash
tables
or
dhts.
The
content
that
we
store
on
ipfs
is
distributed
across
ipfs
nodes
information
on
how
to
get
to
a
node
that
serves
the
content
or
the
routing
information
is
also
distributed
across
nodes.
A
In
this
diagram,
we
visualize
the
DHT
virtual
address
space
as
a
circle,
so
consider
node
P
that
wants
to
fetch
a
block
acting
as
a
client.
We
can
see
node
P's
routing
table
and
we
can
see
that
it
has
routes
to
nodes,
r
s,
t
and
X.
The
client
P
conducts
a
query
for
that
block,
which
we
will
refer
to
as
a
Content
query
in
the
process.
It
may
contact
many
other
nodes,
such
as
node
R,
and
ask
for
the
routing
information
to
iteratively
get
closer
to
the
nodes
that
store
the
block.
A
Suppose
that's
node
B,
so
the
client
may
also
conduct
routing
queries
in
order
to
respond
to
a
Content
query.
Whenever
a
client
fetches
a
block
from
the
DHT
intermediate
nodes,
such
as
node
R,
can
learn
that
the
client
is
looking
up
routes
for
a
node
with
the
given
node
identifier
or
that
it
is
looking
for
a
block
with
a
given
contact
identifier
or
CID.
The
server
nodes,
such
as
node
B,
learns
that
the
client
has
asked
for
and
retrieved
a
block
with
the
CID.
A
The
client
may
have
looked
up
sensitive
content,
so
the
client
may
not
want
the
server
node
to
know
that
it
has
looked
up
this
block
ID.
The
intermediate
nodes
also
ought
to
not
know
what
the
client
is
looking
up
or
which
nodes
the
client
is
trying
to
contact.
More
people
may
be
inclined
to
use
ipfs
to
search
for
sensitive
content
when
they're
assured
that
the
content
of
their
queries
is
not
known
to
other
nodes,
so
conducting
routing
and
content
queries
privately
directly
benefits,
client
nodes.
A
Additionally,
more
nodes
May
participate
as
server
nodes
if
ipfs
further
minimizes
information
that
they
are
exposed
to.
This
is
the
notion
of
plausible
deniability.
Let's
talk
a
bit
more
about
that,
so
consider
ipfs,
node
operators
who
may
store
sensitive
content
and
are
in
a
sensors
region
of
influence.
So
these
node
operators
may
be
compelled
by
the
sensor
to
reveal
what
block
identifiers
were
retrieved
in
a
Content
query
by
a
given
user,
for
example.
Consider
a
sensor
who
requires
node
operators
to
log
content,
queries
in
plain
text
form
and
forward
them
to
the
sensor.
A
Suppose
that
a
Content
query
is
constructed
carefully
such
that
a
node
operator
cannot
determine
the
content,
identifier
or
CID,
and
yet
they
can
answer
the
content
query
successfully.
Then
the
node
operator
can
plausibly
deny
knowing
what
a
given
user
asked
for
through
that
query.
In
turn,
a
sensor
can
no
longer
learn
which
blocks
were
requested
via
the
ipfs
node
operator,
so
providing
possible
deniability
over
query.
Content
can
incentivize
more
users
within
a
sensors
region
of
influence
to
contribute
their
disk
space
and
bandwidth
to
serve
as
ipfs
nodes.
A
Ipfs
has
been
used
to
evade
censorship,
and
our
work
can
benefit
ipfs
node
operators
in
a
censored
regime
right.
So
our
work
dhtpr
allows
users
to
retrieve
documents
from
the
network
without
revealing
what
document
was
retrieved
to
the
Target
node
that
stores
the
document
nor
to
any
impact
nodes.
We
provide
a
complete
algorithm
for
users
to
query
privately
for
for
files,
as
well
as
an
algorithm
for
Publishers
to
store
copies
of
the
file
in
a
way
that
supports
private
querying
note
that
we
do
not
provide
anonymity
to
any
node.
A
That
is,
we
do
not
protect
the
network
identity
of
the
client
peer.
The
adversary
can
see
that
the
client
is
communicating
with
a
given
set
of
nodes.
All
right,
our
interface
can
be
integrated
within
a
distributed
file
system
such
as
ipfs
for
this
integration
to
work.
The
underlying
DHT
first
needs
to
be
strengthened
with
additional
security
and
privacy
building
blocks,
such
as
quorums
and
quorums
based
secure
routing
I'm,
going
to
start
with
the
background
for
our
work
and
proceed
to
the
design
of
our
protocols.
A
A
So
we
showed
these
various
building
blocks
for
our
system.
Here
we
begin
with
a
brief
background
on
private
information
retrieval
or
PIR,
as
it
naturally
provides
the
data
minimization
and
privacy
guarantees
that
we
seek.
We
focus
on
itpir
schemes
which
require
quorums
of
server
node
operators.
Quorum
constructions
have
been
separately
proposed
to
harden
dhts
they've
been
used
in
robust
routing
such
as
young
adults,
robust
communication
protocols
to
provide
Integrity
of
routing
entries
and
prevent
Eclipse
attacks.
A
A
Pir
schemes
are
classified
into
one
of
two
types
depending
on
their
threat:
model,
computational
or
information.
Theoretic
schemes,
computational
PIR
or
cpir
schemes
rely
on
the
hardness
of
cryptographic,
problems,
information,
theoretic
or
itpir
schemes
require
two
or
more
servers
that
host
the
same
content.
The
Trap
model
of
itpr
schemes
requires
that
all
of
these
servers
do
not
communicate
or
collude
with
each
other.
Itpir
schemes
are
preferable
to
CPR
schemes
in
terms
of
performance.
Specifically,
they
have
a
lower
computational
complexity.
A
So
here
four
servers
and
a
client
node
engage
in
a
simple
itpir
scheme.
The
client
wants
to
retrieve
an
index
at
an
item
K
from
the
server's
shared
database.
It
first
constructs
a
non-private
unit,
Vector
ik,
with
the
one
at
this
index
and
0.
Otherwise,
the
client
generates
four
random
index
vectors
R
sub
I
such
that
by
themselves.
A
They
reveal
nothing
about
the
client's
desired
index,
but
when
they
are
combined
in
some
special
way,
so
through
the
zor
operation
here,
the
client
gets
back
the
unit
vector,
so
the
client
sends
one
random
index
Vector
to
each
server.
Each
server
uses
its
index
Vector
to
look
up
the
database
and
returns
with
the
PIR
response.
Here.
The
PIR
response
is
simply
the
product
of
the
PIR
request,
Vector
with
the
database
in
the
Reconstruction
step,
when
the
client
puts
all
prr
responses
together
in
the
same
special
way,
it
will
get
back.
A
The
desired
item
note
that
if
all
of
the
four
servers
shared
their
respective
index
vectors
with
each
other,
then
by
zoring
the
four
index
vectors
together,
they
can
tell
what
row
the
client
looked
up.
So
itpir
schemes
make
the
assumption
that
the
servers
will
not
team
up
and
collude
with
each
other
to
learn
what
the
client's
request
was.
This
is
known
as
a
non-collusion
assumption
in
this
simple
scheme,
all
four
nodes
need
to
be
available
online
for
the
client
to
be
able
to
reconstruct
the
desired
Row
in
general.
A
So
going
back
to
the
DHT
setting
suppose
that
we
can
trust
a
group
of
DHT
nodes
to
not
collude
with
each
other.
With
this
assumption,
we
can
arrange
for
these
nodes
to
share
the
same
database
and
conduct
Byzantine
robust
idpir,
to
enable
a
client
node
to
retrieve
files
privately,
as
it
turns
out,
some
security
properties
for
dhts,
just
such
as
robust
routing
require
that
most
of
a
node's
neighbors
are
not
Byzantine
nodes.
That
is
that
they
are
honest
nodes.
A
Many
constructions
have
been
proposed
to
organize
nodes
in
different
dhts
into
small
groups
such
that
most
nodes
in
each
group
are
honest.
So
essentially,
we
have
these
threshold,
honest
groups
for
some
high
threshold
example.
Qualm
constructions
include
escademia,
which
is
Bomb
guard
and
mises
extension
over
cademlia.
My
understanding
is
that
there
is
work
in
progress
to
incorporate
eskidemia
into
lip
P2P.
While
developing
our
system,
we
had
focused
on
Shannon,
Friedman's,
commensal
cuckoo
rule
or
CCR
for
Quorum
Construction.
A
A
Now
the
CCR
allocates
a
joining
node,
which
may
be
honest
or
Byzantine
to
a
particular
Quorum
in
the
DHT
such
that
no
Quorum
has
more
than
a
certain
local
fraction
of
Byzantine
nodes.
So
this
local
fraction
may
be
much
higher
than
the
global
fraction
that
I
just
mentioned,
which
was
0.16.
So,
for
example,
you
can
see
that
the
maximum
local
fraction
of
bad
nodes
in
any
Quorum
is
two
by
five
or
forty
percent
for
Quorum
6..
A
Now
that
we
have
these
threshold,
honest
quorums,
let's
look
at
how
nodes
in
a
quorum
can
communicate
with
each
other.
So,
instead
of
maintaining
a
routing
entry
for
a
peer
with
the
given
prid,
each
node
maintains
links
to
quorums
of
peers.
That
span
a
small
virtual
address
space
right,
so
Quorum
one
here
can
communicate
directly
with
quorums
3,
7,
10
and
12..
A
So,
for
example,
each
node
in
Quorum
1
maintains
routing
entries
of
network
addresses
for
each
node
in
Quorum
7,
as
well
as
their
public
encryption
keys,
so
suppose
that
node
p
in
Quorum
1
wanted
to
talk
to
Quorum
6..
The
fourth
step
would
be
to
look
up
its
own
routing
table
for
the
Quorum
that
spans
the
closest
address
space
to
the
Target
Quorum.
Here,
that's
quorum,
7.,
so
node
P
could
ask
a
node
in
Quorum
7
for
its
closest
routing
entry
to
the
Target
Quorum
6.
A
So
Eclipse
attacks
pose
a
threat
to
dhts
and
need
to
be
prevented
through
an
efficient
scheme.
One
can
imagine
a
majority
filtering
based
rule
in
order
to
drop
invalid
routing
responses
from
Byzantine
notes
to
do
this
more
efficiently.
If
we
look
at
young
adults
robust
communication
protocols,
so
these
protocols
use
threshold
cryptography
to
provide
Integrity
over
routing
table
entries
and
prevent
this
attack
at
a
very
high
level.
Integrity
is
provided
using
a
special
type
of
digital
signatures
that
is,
threshold
signatures.
A
A
Second,
each
node
also
maintains
threshold
signatures
over
each
element
of
the
routing
table
entry.
So
that's
the
node
Network
addresses
and
the
public
encryption
Keys,
as
well
as
the
Quorum
verification
key.
So
this
is
shown
by
the
square
brackets
around
the
routing
table
entry
with
the
subscript
of
the
signing
Quorum.
So
that's
a
quorum
one
here
for
node
p,
a
note
that
knows
any
quorum's
public
verification
key
can
verify
a
threshold
signature
from
that
Quorum,
so
Quorum
one's
nodes
can
verify
messages
signed
by
quorums,
3,
7,
10
or
12..
A
Essentially,
as
long
as
there
are
enough
good
nodes
in
each
Quorum,
we
can
use
threshold
signatures
to
propagate
verified
routing
entries
in
the
first
step
of
the
robust
communication
protocol,
node
P
requests
for
the
routing
entry
for
Quorum
6
as
usual
in
the
RCP
request
message
here
in
step:
two:
it
obtains
the
routing
entry
as
well
as
a
threshold
signature
over
this
entry.
So
this
would
be
a
threshold
signature
by
the
intermediate
Quorum,
which
is
Quorum
7
here
in
step.
A
3
node
P
can
verify
the
routing
entries
for
Quorum
6's
nodes
using
Quorum,
7's
verification
key
from
its
own
routing
table.
So
the
earlier
attack
does
not
work
given
Byzantine
nodes
such
as
node,
R
and
Quorum.
7
cannot
convince
enough
honest
nodes
in
its
own
quorum
to
construct
a
valid
threshold.
Signature
over
fake
routing
entries
also
node
P
can
now
communicate
with
the
target
Quorum
through
application.
Level
messages
such
as
a
dhtpr
messages
in
steps
four
and
five
here
in
step,
5
node
P,
gets
assigned
application
response
from
Quorum
6.
A
node
P
can
verify
this
response
using
Quorum
6's
verification
key,
as
shown
in
stop
6
here.
So
all
that
you
need
to
know
for
your
rpfs
application
messages
is
that
you
can
now
verify
the
responses
from
a
Target
Quorum,
using
its
public
verification,
key
that
that
we
obtained
during
routing
these
RCP
protocols
provide
Integrity
of
routing
responses.
They
do
not
provide
confidentiality
over
routing
query
content,
for
example,
in
step.
1
all
nodes
in
Quorum
7
know
that
node
P
wants
to
communicate
with
quorum,
6.
A
factors
at
all's,
query
privacy
protocols
hide
which
Target
Quorum
was
looked
up
from
all
intermediate
nodes
and
path
to
the
Target
core.
So
there
are
two
crucial
differences
between
QP
and
RCP.
First,
the
QP
request
to
an
intermediate
Quorum
and
does
not
reveal
the
target
Quorum,
that's
being
looked
up,
so
that's
Quorum,
6
here.
A
Second
for
the
QP
response,
each
intermediate
Quorum
such
as
Quorum
7,
encrypts
its
entire
routing
table
following
an
oblivious
transfer
or
OT
protocol,
so
in
Step
2.
Here
the
ciphertext
table
is
encrypted
again
for
transit
to
the
client
node.
The
special
thing
about
the
OT
protocol
is
that
the
client
can
only
decrypt
a
single
Quorum
routing
entry
of
its
Choice
from
this
innermost
encrypted
routing
table.
A
Again
it
can
verify
the
signature
on
that
routing
entry
that
it
shows
using
the
verification
key
for
Quorum
7.,
keep
in
mind
that
none
of
the
nodes
in
Quorum
7
know
which
quorum's
routing
entry,
the
client
ended
up
decrypting.
So
the
next
steps
that
a
P2P
application
takes
to
communicate
with
the
target
Quorum
that's
steps.
A
Four
five
and
six
here
remain
the
same
as
in
the
RCP
case,
since
we
built
on
top
of
Packers
at
all,
the
client
reaches
the
target
quorum
quorum,
sex
following
the
QP
protocol,
so
steps
one
two
and
three
remain
the
same
here.
This
is
when
both
of
our
protocols
come
into
play,
so
we
perform
steps
four,
five
and
six
here
with
dhg
PIR
application
requests
and
responses.
A
So
for
a
private
file
retrieval
protocol,
each
Quorum
shares
the
same
PIR
database.
Each
database
entry
corresponds
to
a
file
and
the
database
is
indexed
by
file
identifiers.
The
client
wants
to
find
a
file
with
a
given
identifier
in
order
to
conduct
in
order
to
conduct
itpir
the
client
node
P
works
with
index
vectors,
as
I
mentioned
earlier.
The
index
Vector
is
a
unique
Vector
with
the
one
at
the
index
of
the
block
that
is
being
retrieved
from
the
database.
A
So
the
client
node
P
needs
to
be
able
to
first
map
the
file
identifier
to
an
index
in
the
database
from
the
target
Quorum.
And
to
do
so
we
use
a
perfect
cache
function
or
a
phf,
and
here
we
can
see
the
steps
of
our
private
file
retrieval
protocol
at
a
glance.
First,
the
client
node
requests
the
target
Quorum
for
its
phf
and
then
receives
a
phf
in
response.
A
A
The
client
picks
a
node
at
random
from
the
target
Quorum,
and
we
refer
to
this
node
as
a
delicate
node
suppose
the
client
chose
the
Byzantine
node
B,
the
client
encrypts,
a
phf
request
to
the
delegate
node,
which
then
decrypts
the
message
now
I've
said
that
each
Quorum
maintains
a
phf
to
guarantee
freshness.
Phfs
are
associated
with
logical
timestamps
that
increase
with
every
new
insert
into
the
shared
database,
so
a
node
in
a
quorum
can
quickly
compute
a
phf
for
the
shared
database.
A
So
in
the
phf
response
tab,
the
delegate
node
responds
back
with
the
phf
timestamp
pair
to
assure
node
P
of
the
Integrity
of
the
phf.
The
delegate
node
also
returns
a
threshold
signature
over
this
pair
node
P
can
now
confirm
the
Integrity
of
the
phf
by
verifying
the
signature
over
it
using
Quorum
6s
public
verification
key
and
which
it
obtained
during
the
QP
protocol.
The
RCP
threshold
needs
to
be
calibrated
carefully
for
the
phf
response
verification.
A
Okay,
so
now
the
client
gets
a
valid
fresh
phf
and
it
looks
up
the
file
hash
in
the
phf
and
obtains
the
index
of
the
file
in
the
database.
We
now
follow
a
usual
itpir
protocol.
The
client
constructs
a
unit
PIR
the
request,
Vector
that
would
retrieve
the
file
at
that
index
not
privately,
and
it
then
generates
one
random
PIR
request:
Vector
for
each
node
in
the
Target
Quorum
such
that
when
these
vectors
are
combined,
we
get
back
the
non-profit
request
Factor,
as
we
discussed
earlier.
A
A
The
client
then
reconstructs
the
desired
file
using
these
responses
again.
Byzantine
server
nodes
in
the
Target
Quorum
May
mess
with
the
privacy
and
availability
guarantees
for
this
step.
So
the
Byzantine
nodes
here,
nodes,
B
and
M,
for
example-
May
collude
and
share
their
PIR
responses
in
an
attempt
to
determine
which
item
the
client,
retrieved
and
second,
these
nodes
may
send
incorrect
responses
or
just
simply
drop
file.
Retrieval
requests,
so
Byzantine
robots,
itpr
schemes
prevent
these
attacks,
though
we
do
need
to
parameterize
the
threshold
for
these
atpr
schemes
to
work
correctly.
A
We
have
two
constraints:
we
need
to
ensure
that
the
itpr
threshold
is
high
enough
that
these
bad
nodes
cannot
successfully
reconstruct
a
PR
response
by
colluding
amongst
each
other
to
prevent
the
availability
attack.
The
idpr
threshold
should
be
low
enough,
such
that
using
only
the
PIR
responses
from
the
honest
nodes,
the
client
should
be
able
to
reconstruct
the
desired
file,
and
so
that
concludes
our
file
retrieval
protocol.
A
A
A
A
The
client
node
P
encrypts
the
file
to
that
node.
Now
perhaps
node
P
ended
up
contacting
our
Byzantine
node
B,
which
might
just
drop
the
file
silently
without
letting
any
of
its
honest
peers
know
it
could
also
corrupt
the
file
before
passing
it
along
to
honest
nodes,
and
so
the
client
should
be
assured
that
the
file
was
shared
with
the
threshold
of
enough
honest
nodes,
and
so
for
this
reason
we
required
the
delegate
node
to
respond
back
to
the
client
node
with
the
threshold
signature
over
the
hash
of
the
file.
A
A
For
our
protections
to
work,
we
express
constraints
on
the
RCP
threshold
and
itpir
threshold
in
terms
of
the
fraction
of
Byzantine
nodes
per
Quorum.
We
arrive
at
the
maximum
number
of
Byzantine
nodes
per
Quorum,
as
well
as
across
a
network
that
our
scheme
can
withstand
and
we
find
that
quorums
in
dhtpir
can
tolerate
less
than
a
quarter
of
their
nodes
being
Byzantine.
A
So
what
is
the
corresponding
Global
fraction
of
Byzantine
nodes
across
the
network?
To
answer
this
question,
we
simulated
the
commensal
cuckoo
rule
while
ensuring
that
each
Quorum
always
had
less
than
a
quarter
of
Byzantine
nodes.
This
local
bound
of
a
quarter
translates
to
a
global
bound
of
at
most
two
percent
of
the
network,
in
other
words,
at
most
1
in
50.
Nodes
in
the
network
could
be
Byzantine
nodes,
we've
simulated
large
networks
of
about
10
million
nodes
and
maintained
quorums
of
an
average
of
20
nodes
and
at
most
75
nodes.
A
So
we
have
simulated
our
system
and
compared
it
to
the
best
related
work
as
well
as
baselines
in
this
talk,
I'll
focus
on
the
dhtpir
simulation,
in
contrast
with
the
Baseline
of
a
hardened
DHT,
that
is
the
RCP
and
the
QP
protocols
as
applied
to
routing
entries
over
quorums,
but
no
privacy
over
file.
Retrieval
queries.
A
We've
assessed
the
scalability
of
our
system
as
more
blocks
are
stored
across
the
DHT,
as
well
as
with
increasing
numbers
of
peers
and
larger
quorums.
For
this
talk,
I'll
focus
on
scalability
as
more
blocks
are
stored
in
the
DHT.
We
simulate
one
node,
inserting
many
files
into
each
system
and
then
retrieving
them.
We
focus
on
the
performance
of
our
private
file,
retrieval
algorithm.
A
A
The
client
communicates
with
all
of
the
s
nodes
in
the
Target
Quorum,
twice
once
for
each
PR
request
and
once
for
the
prr
response.
So
we
have
a
total
communication
complexity
of
2s
times
the
square
root
of
T.
Given
that
the
Quorum
size
is
kept
constant,
we
can
see
that
the
dhdpr
total
communication
complexity,
which
here
is
shown
in
the
red,
dashed
lines
scales
with
the
square
root
of
the
number
of
files
per
Quorum.
As
expected.
A
With
that
I'll
briefly
talk
about
our
proposal,
submission
towards
the
protocol,
Labs
RFP,
on
private
retrieval
of
data.
Our
goal
is
to
produce
an
ipfs
integrated
design
for
dhcpir
and
its
underlying
protocols
towards
this
goal.
We'll
first
need
to
analyze
the
compatibility
interoperability
of
our
protocols
with
the
ipfs
model
and
architecture.
A
We
may
need
to
revise
some
protocols
and
parameterize
them.
I'll
talk
more
about
these
compatibility
questions
soon
towards
our
second
goal,
we'll
first
associate
relevant
ipfs
libraries
that
will
need
to
be
changed.
We
will
then
develop
a
private
or
secure
interface
over
the
respective
ipfs
libraries
for
that
protocol.
A
A
A
Finally,
we
will
develop
apir
interface
that
extends
the
relevant
ipfs
libraries
such
as
the
bit
swap
protocol
for
a
client
node
to
fetch
a
block
from
one
or
more
server
nodes.
Privately,
we
will
also
Implement
and
test
this
interest
in
comparison
to
the
non-private
version,
so
we
formed
quorums
using
the
commensal
cuckoo
Rule
and
we
conducted
routing
with
integrity
and
confidentiality
guarantees
through
the
RCP
and
QP
protocols
respectively.
Ascademia
has
been
proposed
to
secure
the
underlying
Academia
DHT
used
in
ipfs
and
workers
in
progress
to
integrate
ascademia
into
the
P2P.
A
We
use
the
commensal
cuckoo
rule
to
form
quorums,
so
an
interoperability
question
is,
can
ascademia's
sibling
lists
be
used
to
form
threshold
on
as
quorums
as
in
CCR
does
not
require
coordination
between
existing
nodes
as
a
new
node
joins
the
DHT,
whereas
CCR
does
so.
We
may
want
to
compare
the
communication
overhead
for
a
new
node
joining
the
DHT,
including
sharing
database
State
under
CCR
and
under
Academia
and
in
terms
of
robust
routing.
Academia
includes
a
multiple
disjoint
path,
algorithm
to
deter
Eclipse
attacks.
A
In
contrast,
RCP
provides
a
somewhat
stronger
guarantee
of
preventing
Eclipse
attacks,
so
we
may
wish
to
strength
and
Academia
by
integrating
RCP,
and
we
will
assess
whether
escademia's
multiple
destroying
path
algorithm
can
be
replaced
with
RCP.
We
would
answer
questions
such
as
what
communication
overhead
would
ascademia
with
RCP,
incur
for
conducting
a
routing
query
and
compare
this
overhead
to
escademia,
with
the
multiple
destroying
path,
algorithm
and
codemia
itself,
and
so
with
that
I'll
summarized
the
kind
of
questions
and
challenges
that
we
outlined
in
our
proposal.
A
So
to
summarize,
we
provide
plausible
deniability
over
query
content
for
dhts
by
integrating
private
information
retrieval
or
PIR
into
hard-on
dhts.
Our
architecture
allows
the
user
to
privately
retrieve
a
document
from
the
network
without
the
nodes
in
the
Target
Quorum
or
any
impact
nodes
learning.
What
document
was
retrieved?
A
We
conduct
a
security
analysis
and
a
simulation
for
our
systems
performance.
We
have
submitted
a
proposal
to
integrate
dhdpir
into
ipfs
and
have
described
some
relevant
challenges
in
this
talk,
our
paper,
including
an
extended
version
as
well
as
code
for
our
simulations,
is
available
on
this
link.
Thank
you
for
listening
and
I.
Look
forward
to
your
questions.