On Fri, May 16, 2003 at 05:03:22AM +0000, jrandom wrote: > Ok, lots of chatting on IRC today about updatable keys, spawned by > "<toad_> we must do something about this silly edition site prejudice" > Almost two hours later, I think we've got something. > > Proposal: > Add a new key type that supports secure sites that: > - are like edition sites that can be bookmarked > - are like DBR sites, but don't dissapear when they aren't inserted > - doesn't allow people to delete their content > - allows people to backtrack to old versions without much trouble > > Summary: > There are two parts to the proposal - a new key type and some supporting > metadata. The new Time Updatable Key (TUK) contains in its payload > only the latest site edition number. The TUK itself is signed by > the site's owner, and nodes throughout freenet have access to the update > date through standard datastore/FNP mechanisms. Whenever a TUK > collision occurs, the one with the latest timestamp wins, replacing the > old version.
Important point: this occurs not only on inserts, but also, when we make a request, we keep going, fetching later versions if they are available, until we run out of HTL or reach the desired timestamp. > > So, here we are with a new key containing a value that can be updated. > Typical (proper) usage would have the TUK contain an ever increasing > edition number (or milliseconds since epoch, for you DBR fans). Right, TUKs must only contain a 32-bit integer, encrypted, and the updated time, plaintext (but obviously rounded up by the client), for optimizing queries. > > The way the TUK would be made useful would be by adding support for > TUKs to SSKs, ala > DateRedirect.UseTUK=true > or > Redirect.UseTUK=true > > The TUK itself is located at TUK@<pk>,<entropy>/<name>-TUK/ > where <pk> and <name> are the same as from the SSK > (this we didn't discuss on IRC, or maybe we did and I missed it. toad?) > > This way, when a site is inserted at SSK@<key>,<entropy>/<name>// > containing Redirect.UseTUK=true, fred looks for > TUK@<key>,<entropy>/<name>-TUK/ > Once it finds a TUK it redirects the action to > SSK@<key>,<entropy>/<TUKvalue>-<name>/ > where TUKvalue is the content in the TUK. > > People can go to the beginning by attempting to fetch > SSK@<key>,<entropy>/0-<name>/ > (or, for that damn Colours author, SSK@<key>,<entropy>/f640c0-<name>/) > > While a malicious author attempting to make backtracking hard can do so > (by not using monotonously incrementing 0 originated numbers as TUK values), > normal freesite authors should have a link to their explicit edition (ala > movable > type permalinks): > <a href="/SSK@<pk>,<entropy>/<TUKvalue>-<name>//index.html">this version</a> > and a link to the bookmarkable, updating page: > <a href="/SSK@<pk>,<entropy>/<name>//index.html">this site</a> > > The threat of Big Scary Dood coming over and forcing the normal freesite > author > to update their TUK pointing at content they don't approve of to a "cleansed" > version is minimal, as reasonably normal people can decrement to previous > version > (e.g. SSK@<pk>,<entropy>/5-<name>// to SSK@<pk>,<entropy>/4-<name>//) > Malicious TUK-based freesites however aren't necessarily so easy to decrement. > > Is there anything I've missed toad? Does anyone have any questions, > problems, or > suggestions? I know TUKs have been discussed off and on for long periods of > time - > does this address the qualms people had with previous proposals? This is all > based > on the point of view of the normal freesite development - anyone care to > comment from > the perspective of FMB/Frost? > > -jrandom > (btw, I have the irc log from this afternoon discussing this that I > can post up on a freesite (if toad has no objections). Its only 24k.) > > !+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+ > CryptoMail provides free end-to-end message encryption. > http://www.cryptomail.org/ Ensure your right to privacy. > Traditional email messages are not secure. They are sent as > clear-text and thus are readable by anyone with the motivation > to acquire a copy. > !+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+!+ > > _______________________________________________ > devl mailing list > devl at freenetproject.org > http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
