[p2p-hackers] References for using hashes as unique identifiers?

[Mark S. Miller]

At 12:02 AM 3/8/2004  Monday, Brad Neuberg wrote:

>> I believe the concept originated at Xanadu around
>> 1990 or so, but was never 
>> implemented or published.
>
>That's an interesting reference to Xanadu.  Can you
>talk more about how and why the Xanadu team came up
>with this concept in regards to their own vision of a
>hypertext web?

A link from document X to document Y must somehow designate document Y. It 
had never occurred to us that the designator should depend on specifying 
what machine Y is hosted on. That would obviously be insane. Documents must 
survive longer than their hosting machine and their hosting organization. 
Besides, popular documents would make for hotspots in the network -- an 
obviously unscalable architecture.

The goals of the Xanadu project had long been to make a decentralized 
secure medium, robust against attack, including censorship attempts by 
governments, and able to scale to hold mankind's literature. We all felt 
that large scale electronic publishing was coming, expected and hoped that 
it would be hypertext, and realized that this transition would make 
mankind's literature either much more vulnerable or much less vulnerable to 
abuse, depending on the architecture. One of our slogans: "We want to build 
a medium Thomas Jefferson would be proud of."

The architecture now known as Udanax Gold 
http://udanax.com/gold/index.html 
http://www.sunless-sea.net/forum 
http://www.caplet.com/papers/open-media.html 
has two concepts corresponding to what we mean by "document": The "work" and 
the "edition". A link can link to either kind of thing.

The version of Udanax Gold that was actually built was not distributed, and 
so did not need a cryptographic basis for its integrity (or other security) 
properties. But it was designed to have a semantics that could be preserved 
by a decentralized implementation, where the decentralized implementation 
would necessarily depend on cryptographic controls to enforce the integrity 
specified by the semantics, in order to prevent abuse.

An edition is an immutable snapshot of the contents of a document as of some 
moment. We planned to eventually designate an edition by the cryptohash of 
its contents. Nevermind that we made other decisions that would have made this 
impossible -- we didn't notice the conflicts at the time. Though we didn't 
yet know Zooko's phrase "self-authenticating designator", we had the 
concept, and we thought we were on a course to achieve it.

A work is a mutable designator of a particular edition. It represents the 
notion of a living document, as in "the current rev of the biz plan". To 
read a work is to obtain access to its current edition. To revise a work is 
to set its current edition to an edition you specify.

We planned to represent a work by a pair of a signing key and a signature 
verification key. The work would be designated by the signature verification 
key (or a fingerprint of this key). The right to revise a work would be 
based on knowledge of the signing key. To revise a work is to sign the hash 
of an edition (plus some meta info, perhaps identifying predecessor 
editions, I don't remember) as being an edition of this work, and to make 
the resulting signature available. Note that both editions and signed 
revision records can be replicated freely and are location independent.

Within just these notions, one can't reliably read the *current* state of a 
work. Rather, the best you can do is to get the most recent of those you 
could find. We expected to have something like a netnews flooding algorithm, 
so that this would normally be recent enough for many purposes.

In addition, we did have a location dependent notion of a work's current 
true home -- its hosting machine. To reliably get the work's *current* edition
required a round trip to that machine, and the notion of current was still 
subject to abuse by the proprietors of that machine. We didn't like it, but 
the only way we knew to avoid this kind of per-work centralization was to 
give up the notion of "current", which we were unwilling to do.

In any case, I'm proud to say that most of the notions stated above, 
including (I think) these same cryptographic integrity controls, are now 
part of OpenCM and used for decentralized high assurance configuration 
management.
http://opencm.org/
This set of ideas actually works together much better than we had any right 
to expect ;). But the price of "current" remains location dependence. This 
constraint is even harder to escape than we'd feared. The only escape I know 
of is quorum systems of some kind (such as 
http://szabo.best.vwh.net/securetitle.html ), and, IMHO, these may still be 
too complex to be practical.


-- 
Text by me above is hereby placed in the public domain

        Cheers,
        --MarkM