[p2p-hackers] Ways of enforcing "property rights" for data published to a DHT

[Sean C. Rhea]

On Apr 22, 2005, at 4:44 AM, Enzo Michelangeli wrote:
> I wonder if other DHT's implement mechanisms to make a record protected
> from being overwritten by unauthorized parties. A simple way could be
> based on adding to the data an unguessable "cookie" (say, another 
> 128-bit
> string with randoly-generated content) that would be stored in the DHT 
> but
> NOT returned as result of a successful search; republishing a record 
> with
> a different dictionary would result in the replacement of one 
> previously
> existing ONLY if also the cookie were the same. Unfortunately this
> improvement cannot be put in place while preserving interoperability 
> with
> the existing Overnet network, but I wonder if and how other DHT's have
> tackled this issue.

In OpenDHT, we store all records for a certain time-to-live (TLL), 
specified by the client that puts the record, and capped at one week 
(although we're going to push the cap up to a month soon).  If two 
clients store under the same key, and the values are different, we 
store both values.  If the values are the same, we store just one, but 
for the longest of the two TTLs specified.

The problem, of course, is that some people want to remove their values 
from time to time.  We could handle this with public key crypto (and we 
have a planned interface that does so), but a lot of people want 
something more simple for now.  Here's our planned interface, which we 
should be rolling out in the next few weeks:

The idea is to use one-way functions.  For example, with each put, you 
give OpenDHT a key k, a value v, and some number y.  To remove, you 
provide k and SHA(v) (in order to specify which value you want to 
remove, in case there are more than one), plus the value x such that 
f(x)=y, where f is a well-known one-way function, such as SHA (recent 
results aside).  Gets on k will also return y in addition to v.

Once a remove is issued, it's stored in the DHT for a TTL just like any 
other k,v pair, and an OpenDHT node won't return k,v pairs for which it 
has a remove.  The semantics are simple and consistent with the current 
eventually-consistent model.  We'll leave 0 as the "null y", so that 
you can specify that some k,v pairs cannot be removed.  (You could just 
pick a random y for which you can't compute the pre-image under f, but 
that's annoying.)

Moreover, you can build client-side extensions so that one client can 
remove another's puts, and you don't really need a different secret for 
each put.  Consider a set of clients who all share some secret key s.  
For each put, a client picks a random number x, computes y=f(x), and 
computes x'=x encrypted with s.  It then does put(k,(v,x'),y).  If one 
of its friends wants to remove the value, it does get(k) to learn x', 
decrypts it using s to get x, and then does remove(k,v,x).  But s is 
never sent over the wire, so there's no eavesdropping problem as there 
would be with the cookie idea you mentioned above.

The source code for OpenDHT is all available on the Bamboo web site 
(bamboo-dht.org), so you can use it in projects of your own if you 
don't want to use the public deployment on PlanetLab.  I should have 
this new remove functionality in there in the next few weeks.

Sean
-- 
      I contend that we are both atheists. I just believe in one fewer
     god than you do. When you understand why you dismiss all the other
           possible gods, you will understand why I dismiss yours.
                              -- Stephen Roberts

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://zgp.org/pipermail/p2p-hackers/attachments/20050422/e6abf71d/PGP.pgp