-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > CBR links only hide information from external adversaries. They're > > transparent to internal adversaries. > > True enough. But there are ways to prevent internal attackers > masquerading as zillions of nodes: > - Costly identity via hash- and think- cash.
Agreed, there are methods for minimizing Sybil with regards to the P = (c/n)^h here. > - Darknets, with cellular tunnel selection. Depending on darknets for the peer selection is the same as saying "dunno, let the user figure it out". But, thats a topic for another discussion. > > > 1. Pure CBR. All node links are exactly 1kB/sec. Not practical for I2P, > > > very wasteful for freenet. > > > > (1) is a nonstarter. You've just jacked the queueing times into > > *hours* for most uses. That is, assuming people stop adding to the > > queues and it doesn't fall into congestion collapse. > > Feasible for Freenet, including distributed pub/sub streams using > passive requests. Not so sure about 1:1 streams! Remember that we've > probably only got 20kB/sec or so upstream. We've already had these discussions about whether Freenet's routing can deal with congestion, with the net result being "we'll see". Now you're saying you'll enforce a maximum link capacity of 1KBps? Well, there are enough details not specified yet for us to continue with the "we'll see" response, I suppose. > > For 2-4, how are the CBR rates negotiated? > > Sorry, below you're talking tunnels; I was talking links, to prevent > external attackers (both passive and active) from exposing traffic. Ah, you're right, though the above question still stands. Let me revise my questions: > > In any case, 2-4 must use a CBR no higher than the individual nodes' > > free capacity, and the rate selected reduces the anonymity set of > > the traffic carried to the order of other links with similar rates. Still pertinent for CBR links. > > (2), if I understand correctly, means the tunnel stays constant at > > the tunnel's negotiated CBR rate at all times. This fails pretty > > clearly in the same way pipenet does. Still pertinent for CBR links, replacing "tunnel" with "link". > > (3), if I understand correctly, means the tunnel doesn't do any CBR, > > beyond some algorithm that verifies that by the end of the tunnel's > > lifetime, the total number of messages transmitted equals what it > > would have transmitted if it were CBR'ed like (2). Right? > > > > > > Off the top of my head, I don't see a simple algorithm for achieving > > reasonable CBR without leaking the flow. For instance, I2P uses a > > token bucket for bandwidth limiting - every 100ms, we add in some > > new tokens, and whenever we want to send out a packet, we wait until > > we can grab enough tokens from the bucket. The 'always active' > > state of such a scheme is CBR, but its patterns of downtime (when > > tokens accumulate in the bucket) as well as its patterns of bursting > > (when excess tokens are pulled from the bucket faster than they are > > added) are visible. Needs adjustment for CBR links, but only by replacing the "tunnel lifetime" variable with duration of the "long term" averaging. > > I'm not sure I understand (4). Still pertinent for CBR links :) =jr -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDYRRvWYfZ3rPnHH0RAh0nAJ9bCqtbKjdw+nyGk1BkcU22x3TFpACfd+GN RifkHu6BKCYEpFTR251QDEc= =PgXU -----END PGP SIGNATURE----- _______________________________________________ chat mailing list chat@freenetproject.org Archived: http://news.gmane.org/gmane.network.freenet.general Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/chat Or mailto:[EMAIL PROTECTED]
