Skip to Content.
Sympa Menu

bluesky - Re: Freenet's hashing algorithm

bluesky AT lists.ibiblio.org

Subject: Global-Scale Distributed Storage Systems

List archive

Chronological Thread  
  • From: graydon AT venge.net
  • To: Global-Scale Distributed Storage Systems <bluesky AT franklin.oit.unc.edu>
  • Subject: Re: Freenet's hashing algorithm
  • Date: Fri, 16 Feb 2001 19:23:25 -0500


On Thu, Feb 15, 2001 at 10:32:11PM -0800, hal AT finney.org wrote:

> A content hash should be thought of as a shorthand or abbreviation for
> the document it represents. It is an unforgeable short-name, and in
> principle an unforgeable address. Whether via Freenet or via some more
> conventional lookup system, you can have a system to go from hash to data.

yeah, I get the general idea, but I think you're seriously misapplying
the concept of a hash as a trust device. a hash of a chunk of data tells
you nothing about the trustworthyness of the chunk. you need a trust
relationship with a signing key, and a signature, and a simple hash
doesn't give you this.

if I get a CHK from a tee-shirt, I've no reason to believe the data I
get at that CHK is trustworthy. what or whom I trust is my own business,
to be established by verifying signatures against keys I personally
acquire.

to paint the orthogonality of these matters more concretely: suppose,
for instance, that EvilCorp put up a page saying "we are totally
legitimate people". I would not trust that, because I am a suspicious
guy and have heared some bad stuff about them before. I would know
the page was put up by EvilCorp because their signature checks out,
but I would not _trust_ what they are saying. if someone then broke
the EvilCorp security system, or indeed broke the complete freenet
security system, hit every machine storing copies, updated the page with
officially (wrt EvilCorp) "wrong" data about the evils of EvilCorp, and
then signed the "wrong" page with a key from some activist organization
I have a trust relationship with, the page has actually become _more_
trustworthy to me than it was before it was doctored.

> There are good uses for such documents. Not all documents need to be
> updated; sometimes you want documents which *can't* be updated: legal
> agreements, for example.

this seems to always come up when discussing distributed storage
systems. I think the image of someone "changing" or "censoring" your
speech overwhelms the technical fact of the matter: it is exactly the
same to have a flag you can set on a document saying "don't accept any
updates for me" as it is to have a "non-changeable" document. the two
concepts are functionally identical:

* any conformant server will reject attempts to change the document
* any wrong, evil server will just screw around with the data anyway
* any signature-type information, whether used to "locate" the data
or simply validate it as it's retrieved, will be broken by an evil,
editing server, so the unauthorized edit is detectable by any client

I mean, imagine you have "non-changeable" documents. I get one, I put
it on my disk, I open a hex editor (if the source is nonfree) and
edit the file. I recompute a CHK, I spam the whole universe with the
new CHK, posting it on CNN, getting it printed on coke cans, etc.
until everyone thinks my CHK is the original. in what way is this any
different from someone illicitly updating a document in a system which
"allows" updates? it takes roughly as much effort as I'd need to put in
to defeat the trust relationship someone has with a signing key they
consider relatively "authoritative" anyways. in other words, what does
it even mean to "allow" vs. "disallow" updates? imho it's nothing more
than a recommendation anyways. compliance is always up to the retriever,
with the trust relationship and signature, to ensure.

-graydon




Archive powered by MHonArc 2.6.24.

Top of Page