[chord] dhash ctypes

[Emil Sit]

Adrian,

On Sat, 22 May 2004 at 02:39 (+0300), adrian at softnet.tuc.gr wrote:
> I have rode test_types.C and I am still a little confused.
> In my apps, dictionary, I need a kind of "light" authorization, so if
> you can rough explain me the properties of each
> one(PUB_KEY,CONTENT_HASH,NOAUTH), that will be very helpfull. Mainly,
> differences between last two.

Here's the theory.  Every piece of data in DHash has a key
associated with it.  The question is, what key?

* For public key blocks, the DHash key is the SHA-1 of a public key
  and a nonce.  The nonce introduced last July by Mike Walfish
  allows for multiple blocks signed by the same key.  In this
  case, the block contents are to be signed by the private key,
  corresponding to the public key from which the DHash key
  was derived.

* Content hash blocks have a key corresponding to the SHA-1 of
  the contents of the block.  You have to write down somewhere
  else the content hash of the blocks that you want to get at
  later.  Often, we encode these content hashes the contents
  of other blocks, allowing us to construct things like the
  i-nodes in CFS.

* The theory behind noauth blocks is that the user is allowed
  to specify the key as well as the block.  Thus, DHash doesn't
  do any verification.

I believe that each different ctype (the above three) is stored in a
separate DHash key space.  That is, I think that you can have a public
key block that happens to be keyed to 0x123450000...  as well as a
content hash block with the same key.  (I may be wrong about this part;
I've never worked on this part of the code.) 

Perhaps the right thing to do would be to provide a user interface
(e.g. at the dhashclient level) that is always what the noauth blocks
are supposed to be --- no enforced correlation between key and data.
Then just allow the user to have whatever sort of enforcement desired.
But, that would collapse the multiple namespaces, so you wouldn't
be able to store a content hash block whose contents are
"public key + nonce".

> I have already seen a post,  Date:17/7/2003 by mwalish at lcs.mit.edu and
> some replies, but still I am not sure about what is really true.

Yeah... perhaps the best way to get at "what is really true" would
be to read the source code, unfortunately.

I'd be happy to look at patches to improve the situation, but
I don't have a lot of time right now to work on it.

Hope this helps.

-- 
Emil Sit / MIT LCS PDOS / http://pdos.lcs.mit.edu/chord/