Skip to Content.
Sympa Menu

bluesky - self-authenticating URLs (Re: Freenet's hashing algorithm)

bluesky AT lists.ibiblio.org

Subject: Global-Scale Distributed Storage Systems

List archive

Chronological Thread  
  • From: Adam Back <adam AT cypherspace.org>
  • To: graydon AT venge.net
  • Cc: bluesky AT franklin.oit.unc.edu
  • Subject: self-authenticating URLs (Re: Freenet's hashing algorithm)
  • Date: Fri, 16 Feb 2001 02:16:35 -0500



It seems there are a number of approaches to URLs. There are
arguments for making them readable, persistent across versions, not
persistent across versions, self authenticating and so on. Some of
the systems with not directly readable URLs are presuming there will
be a name resolution server on top. (eg. TAZ/rewebber)

(Making URLs self authenticating in a way which requires URLs to
change with versions creates it's own problems with hyperlinked docs
-- the publius docs describe some of these problems -- they had to go
through some complex path to even change one doc because of this, as
all references to it had to change, and they had to deal with loops).

I read the use in FreeNet to be just an attempt to cheaply
authenticate the URL, as the URL is tied to the document. I'd guess
the authentication token in FreeNet was re-used as the lookup key just
to make URLs small. (If I recall dimly I think I may have suggested
using the hash of the file as the URL on the FreeNet list back at the
beginning of FreeNets prototyping phase).

If someone sends you a URL in a signed PGP mail, or refers to a URL in
another document, you may want to know what version of the document
they were thinking of. Probably you also want to be able to get to
the current version, perhaps you even want the current version
authenticated as being by the same author to be the default and just
be able to go back to the old version, or navigate around in old
versions to avoid revisionism and attempts to silence an author by
having him change a later version to say something against his will.

So my only argument in this is it's another requirement to be able to
get at old versions to avoid revisionism. That may conflict with
somone's perceived right to revise information they once made
available. However I'm not sure the author can reasonably demand that
machines acting in common interest allow him to revise something he
once said.

I think one should analyse what properties the system should offer,
what choices the user will want and try to arrange those properties.

Anderson et al have a paper on the Eternal Resource Locator (see above
URL for ref) which is interesting about authenticating URLs and
hypertext links.

My little link farm on these systems includes publius, ERLs and all
the rest.

http://www.cypherspace.org/links.html

Adam

> this strikes me as a conflation of matters, with serious drawbacks.
>
> * lack of friendly names
> * inability to change data without renaming/moving it
> * no actual improvement in security. the fact that the data satisfies
> the hash is vaccuous; any data will satisfy a CHK pointing to it,
> regardless of who put it there or how "true" it is. what you care
> about is that the data you retrieved is the data some party intended
> you to receive, and if you read a CHK off a tee shirt there is no
> reason to believe this CHK is any more trustworthy than a press
> release from the government of EvilLand.
>
> certainly a good hash algorithm is useful for stretching a friendly
> name into some fixed-size, uniformly distributed keyspace for finding
> the associated block. but hashing the content is a security issue, not
> a retrieval issue. freenet seems to be fiddling around with a variety
> of key types to get the balance of pragmatics right. chained hashes
> signed by some sort of pre-existing security association key makes
> sense for verifying a stream piecemeal, but I still wouldn't use that
> for locating, in case you want to update the data. you really don't
> want to relocate all the blocks just because you change 1 byte
> somewhere.




  • self-authenticating URLs (Re: Freenet's hashing algorithm), Adam Back, 02/16/2001

Archive powered by MHonArc 2.6.24.

Top of Page