Re: Burning bridges was Re: [i2p] I2P's security from global passive traffic analysis

On Thu, Oct 27, 2005 at 01:23:48PM -0400, [email protected] wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> > > > - Both dark and open (maybe) freenet can be insulated from this via CBR
> > > >   links because nodes are of low order and links change slowly. - IF there
> > > >   is no fundamental problem with CBR links. I2P probably can't be.
> > >
> > > I'd posit that "IF" is appropriately questionable ;)
> >
> > I'm not sure why. There is a big problem with CBR *tunnels*. What is the
> > big problem with CBR *links* ?
> 
> 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.
- Darknets, with cellular tunnel selection.
> 
> In addition, you've got pipenet-esque issues.  For the four
> scenarios you described:
> 
> > 1. Pure CBR. All node links are exactly 1kB/sec. Not practical for I2P,
> >    very wasteful for freenet.
> > 2. Negotiated CBR based on current traffic level.
> > 3. Negotiated CBR based on average long-term traffic level.
> > 4. Negotiated CBR based on hosts available capacity. ~= #1, but more
> >    friendly to slower nodes.
> >
> > I think what jr is critiquing here is #2. I was thinking more #3.
> 
> (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.
> 
> 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.
> 
> 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.
> 
> (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.
> 
> (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.
> 
> I'm not sure I understand (4).
> 
> =jr
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
> 
> iD8DBQFDYQrTWYfZ3rPnHH0RAgYQAJ4m8vROjE6J5tIFf/DqrPVB599LqgCfbwfO
> X97OYyerUGjuU3ZR2P/YEQk=
> =xOMM
> -----END PGP SIGNATURE-----

-- 
Matthew J Toseland - toad-EI5O+8PHWbJeeLb3ft/[email protected]
Freenet Project Official Codemonkey - http://freenetproject.org/
ICTHUS - Nothing is impossible. Our Boss says so.

_______________________________________________
chat mailing list
[email protected]
Archived: http://news.gmane.org/gmane.network.freenet.general
Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/chat
Or mailto:[email protected]?subject=unsubscribe

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD4DBQFDYQy0HzsuOmVUoi0RAlfIAJoDzQiewmnavKa/pAs03hzPzeiFDACXZUYF
Cq07L7Hqo5Q3e4MZwSdcDA==
=GtpG
-----END PGP SIGNATURE-----