Time Updatable Keys notes file =============================================================================== From: jrand0m Subject: [freenet-dev] TUK (redux) Ok, lots of chatting on IRC today about updatable keys, spawned by " 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. 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). 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@,/-TUK/ where and 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@,/// containing Redirect.UseTUK=true, fred looks for TUK@,/-TUK/ Once it finds a TUK it redirects the action to SSK@,/-/ where TUKvalue is the content in the TUK. People can go to the beginning by attempting to fetch SSK@,/0-/ (or, for that damn Colours author, SSK@,/f640c0-/) 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): this version and a link to the bookmarkable, updating page: this site 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@,/5-// to SSK@,/4-//) 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.) =============================================================================== On Fri, May 16, 2003 at 05:03:22AM +0000, jrandom wrote: > Ok, lots of chatting on IRC today about updatable keys, spawned by > " 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@,/-TUK/ > where and 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@,/// > containing Redirect.UseTUK=true, fred looks for TUK@,/-TUK/ > Once it finds a TUK it redirects the action to SSK@,/-/ > where TUKvalue is the content in the TUK. > > People can go to the beginning by attempting to fetch SSK@,/0-/ > (or, for that damn Colours author, SSK@,/f640c0-/) > > 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): > this version > and a link to the bookmarkable, updating page: > this site > > 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@,/5-// to SSK@,/4-//) > 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.) ============================================================================== Subject: Re: [freenet-dev] TUK (redux) From: Scott Young To: devl@freenetproject.org .... Updatable keys have been debated over, and over, and over again for the past several years, so I'll weigh in on what I've gathered so far. The problem of going the entire HTL is, of course, the time lag that every request for updatable content must suffer. Oskar's Interval Pass-Through Update scheme from September of 2000 was an early idea to solve this problem: http://www.geocrawler.com/archives/3/928/2000/9/50/4421682/ One change that I would make to his scheme, though, is to use a formula that would make the next-time-to-allow-pass-through the same throughout the network, so that there isn't a mess with nodes mismatching update windows and continually re-propagating old content. Another scheme would be to do the request, return the first TUK that the request hits immediately, but still continue the request on until the most recent one is found, and return that if it exists. A "reload" in the browser window would give the new content once it was received. This scheme would be much quicker at distributing new content, but it would cause more network traffic. Although, TUKs would only be a few bytes long so traffic might not be so much of a problem. Both of these schemes require a key that will always route to the same area of the keyspace for all keys updating the same content. A node needs to know where the updates will be located in order to find them, which becomes difficult if an update redirect keeps changing routing location. This is the main reason why a new key type and a modification to the FNP is needed for these two schemes. ============================================================================== From: Nick Tarleton To: devl@freenetproject.org Subject: Re: [freenet-dev] TUK (redux) On Friday 16 May 2003 02:50 pm, Toad wrote: > > This way, when a site is inserted at SSK@,/// > > containing Redirect.UseTUK=true, fred looks for > > TUK@,/-TUK/ Once it finds a TUK it redirects the > > action to SSK@,/-/ where TUKvalue is the > > content in the TUK. > > Or, TUK@,/-TUK/ could just be linked to. Come to think of it, you don't even need the -TUK. What is entropy? Also, could you have KSK-like TUKs, or would you have to share the private key? > > This is all based on the point of view of the normal > > freesite development - anyone care to comment from the perspective of > > FMB/Frost? FMB idea: TUK@/fmb points to the most recent channel update: SSK@/fmb//. =============================================================================== From: jrandom To: devl@freenetproject.org Subject: [freenet-dev] re: TUK (redux) So as soon as I got home last night I remembered something. What may be helpful is that perhaps the content at the TUK contains both an expected update date as well as the content previously discussed. This way, if a TUK is retrieved after only a few hops, but the expected update date has not yet occurred, the value in that TUK version is used. However, if the expected update date has passed, another request goes out (at HTL 15? at an HTL specified in the SSK via TUK.updateSearchHTL=?), and the most recent TUK value is found. This way, TUKs won't necessarily be searched for at a full HTL depth always, but in the case that the TUK isn't retrievable or the suggested update date has passed, the full HTL will be used. Also, I don't think the TUK content should be limited by fred to be a small size (e.g. 1k as discussed on IRC). For normal freenet publishing purposes, yes it should be severely limited when interpreted through the .UseTUK= metadata flag to be a single value ([0-9a-zA-Z]*), but I can imagine FMB and other similar systems using a single inbox or outbox containing their messages, rather than relying on the SSK@,/fmb// (yikes, I can't believe it took over a full hour for my post last night to go through. damn thee mailmain && / || cryptomail!) So, um, er, thoughts? -jrandom ============================================================================== Add more notes on TUKs here.