On Thu, May 04, 2000 at 12:11:14PM -0700, Greg Retkowski wrote: > I am fairly new to the mailing list, so forgive me if these ideas have > been forwarded previously and shot down. I would like to forward the > following suggestion for modification of data in the freenet system. > > Each item of data should be stored with an 'update hash'. This hash being > the result of hashing the actual original file with a one-time-use > password (possibly derived from a password the author uses persistantly). > Each server storing the file also stores this update hash, and the hash > itself is generated by the author and sent to the server with the original > data. When the author decides to update his content he sends his new > content along with the password that 'unlocks' the original document > (along with a new update hash for the new revision).
The only secure way to do this is with cryptographic authentication. Your proposal is not secure at all because one would just have to set up a node to obtain this one-time password, even if the connection between nodes was encrypted using strong crypto such as Blowfish or Twofish. > A server can then store the password to unlock the original document and > use it to authenticate the new document as required to push updates to > other servers. This is totally insecure. Anyone who could start up a Freenet node would be able to access this directly. > This hash ensures the person updating the key is the real author, and > servers updating the key are acting on the author's behalf. > > This may introduce two new items to freenet. First each key may have some > associated 'metadata'; along with the update_hash some other metadata > items may be things such as 'indexable' (support dir listings when a key > with subkeys is retreved?), 'searchable', 'description', 'bangpath' (see > note 1), and 'revision'. Servers may contain a given piece of metadata for > data it does not have, but usually not vice versa. > > Secondly a 'control message protocol' may be useful. Servers may be able > to announce themselves as available to the freenet and use it to announce > updates to a given key. As the control messages would be relatively brief > they would not incurr as many of the problems of data broadcast protocols > (NNTP) but could use similar methods (IHAVE) to pass messages around. This would just help to make Freenet even more complex. Even though complexity might be needed is certain cases, such as security protocals, unnecessary complexity is not desirable. This could easily kept as part of the Freenet protocal instead of being made a separate protocal. > Note1: A bangpath can be of arbitrary length with the last X hosts that > the document passed through on its way to this server's data store. It > would be undesireable for the bangpath to lead all the way to the origin > of the document for privacy reasons, thus the arbitrary length. This can > be used as a 'server discovery' tool for the server to have a catalog of > other freenet servers so that the freenet network can have a 'self > repairing' topology.. the server can start using discovered servers for > key searches if its primary servers fail. Since when did Freenet use bangpaths? Freenet is not Usenet. > -- Greg > > Greg Retkowski Mail: greg at rage.net > Raging Network Services URL: http://www.rage.net/ > > > _______________________________________________ > Freenet-dev mailing list > Freenet-dev at lists.sourceforge.net > http://lists.sourceforge.net/mailman/listinfo/freenet-dev -- Travis Bemann My mailing software is misconfigured. My email address is bemann at execpc.com, not bemann at bemann. _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
