--- Tom Kaitchuck <[EMAIL PROTECTED]> wrote: > On Thursday 30 October 2003 03:20 pm, Tom Kaitchuck wrote: > > On Thursday 30 October 2003 01:46 pm, Toad wrote: > > > On Thu, Oct 30, 2003 at 01:15:23PM -0600, Tom Kaitchuck wrote: > > > > Why not? For CHK: > > > > [EMAIL PROTECTED],<hash>,<decrypt key> > > > > where <Decrypt key> decrypts > > > > and H(hash) routes > > > > and H(hash+XXX) verifies. > > > > All you have to send is hash and XXX. > > > > For SSK: > > > > [EMAIL PROTECTED],<key>,<name> > > > > where <key> decrypts > > > > and H(H(key+name)) routes > > > > and H(H(key+name)+XXX) verifies. > > > > All you have to send is H(key+name) and XXX. > > > > > > > > Why wouldn't this work? > > > > > > Because if XXX is common, the attacker only needs to compute it once. > > Yeah, you right I'm an idiot. :-) No you're not. If you or Toad or I came up with this, we rock. The problems are fixable.
> But if you route based on the h(hash+xxx) then you can't keep upping XXX. :-( > and because we are limited to a fixed table size they only need to generate > that many keys. :-( > So in the end anyone with access to a hundred or so PCs could censor any > content in Freenet within a couple of weeks :-( > So anyone have any other idea? I always thought of Hash Cash working like this. You pick your route, and then you pay the toll. What we've discovered today is: If you base the route only on the hashcash and things the hashcash's validity is based on, the adversary is forced to pay first and then get the routing key. That's a big Ah-ha idea for me. I hadn't thought of including the hash cache with the URL at all. I thought we'd make both sides pay. They use about the same bandwidth resources. Then again it seems kind of natural to make the inserter pay to store stuff. Good spotting with the SSK problem Toad. Here's some ways around the problem: 1) don't include the hash cash with the URL, make both sides do the work 2) route everything in the same subspace to the same place, limit update rate/subspace 3) make everyone use global links 4) make an insertion tool which makes the global links and does the hash cache once 4 is probably best. ----Scaling up key sizes and what not Ok, so CPU power will get cheaper. If memory/diskspace gets cheaper in proportion it won't matter. Today 1*CPU second is worth 32KB space. In 4 years 0.2CPU*s might be worth 32KB of space. Ok, what about some node farm creating tons of junk data, won't he eventually have enough to do his DNS attack? If you have some religious belief in Moore's Law (I don't) you could argue that no matter what CPU time today will be worth a certain amount of memory for all eternity. You just have to assume memory prices in the long haul decrease exponentially. Here's a fun idea: Could we take the routing key and before using it run it through a special function which changes slowly over time, in a yet to be determined fasion? For example in the future take some of the insignificant bits and mutiply them by constants and add that to the original hash. The idea would be that objects wander around in hashspace just a little over different versions of freenet. In a weeks time an object might only move a node or two, but in a few years it could be completely somewhere else. This should make such adversary's stock pile of ammo deteriorate, hopefully faster than he can generate it. We could incrementally change hash cash formats. If it wasn't in the URL, or old URLs just force the user to calculate the hash cache himself the system could slowly invent newer harder cashes and devaluate the old ones. Make the 10 bit caches standard and drop the 8 bit ones. Later make 11 bit standard and drop the 9 bit ones. I could try my request on all the accepted versions and if I succeed reinsert under the newest version. We might also think about using better hash cache to give extra priority to certains posts that should stay longer or go deeper, and requests which should go faster and farther. Guys this conversation rocked!!! Sorry I always miss the good bits. Now all we have to do is fix the cancer node problems and iron this stuff out. __________________________________________________________________ Gesendet von Yahoo! Mail - http://mail.yahoo.de Logos und Klingelt�ne f�rs Handy bei http://sms.yahoo.de _______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
