Tor Stinks re Traffic Analysis and Sybil (as do other networks)

[Zenaan Harkness]

On Mon, Nov 25, 2019 at 03:27:30PM -0300, Punk-Stasi 2.0 wrote:
> On Mon, 25 Nov 2019 06:03:38 -0500
> grarpamp <grarpamp at gmail.com> wrote:
> 
> > > 	by 'low latency' they mean two things :
> > >
> > > 	1) 'efficient' use of data transmission capacity, i.e. whether chaff is
> > > sent(expensive)  or not.
> > 
> > Chaff might be really only "expensive" if
> > 1) Monetary, user chose to pay for it under metered plan,
> 
> 	except, unmetered plans are a scam. And that's the whole point. I think it's safe to assume that 'backbones' can't carry chaff traffic. If a substantial number of ppl tried  to use their 'unmetered' plans to transmit chaff the nsa-network would grind to a halt. 


This sounds correct to a degree.

"At purchased capacity, for 'unmetered' plans."

In other words under utilized long-duration chaff filled links,
ought be incentivized against.  This is natural for a friend to
friend link - I know my friend by name/nick, and holler at him if his
usage pattern is causing me to burn significant chaff which he simply
does not use.

Remember, we're attempting to create at least somewhat of a switch
based overlay net - so the primary connection is a link between 2
peer nodes A and B.

Of course, onion routing is onion routing, and so the p2p node link
is just a first hop - a 2nd hop must onion across B, e.g. A B C,
but now C receives packets "from B" which are really from A, and C is
still going to get annoyed if the B C link is "significantly" under
utilized.

(In practice of course "get annoyed" is a misnomer - only tech folks
 even bother to look at e.g. wheat/chaff utilization stats, and so
 the incentivization algos must be (as far as possible) built into
 link bandwidth management, i.e., automatically shape up and down as
 needed yet according to "user specified + random" hysteresis conf.

 May still have a "You might want to get annoyed at peer X" dialog
 too :)
)



> > or refuses to buildout free p2p, guerilla, mesh networks.
> 
> 	...yeah chaff wouldn't be a problem in a network with no backbones. Too bad such mesh  network doesn't exist. 


Steve Schear - perhaps you are inclined to include some links and
possibly a write up, into text files in the iqnets/doc/ dir (or new
git proj if you think that's better)?

Some of us see an alt phys net as foundational to our goals here ...
and to this end intend iqnets to use and facilitate such links at
core protocol... permanent ("stable" "backhaul") dark links, as well
as ephemeral temporary e.g. mobile phone ad hoc wireless meshe links.

Steve, in these early (design, info gathering) days, a big part of
our work is scouring the webs for possibly useful info and dumping
such into a links file (e.g. urls-alt-phys-net.txt), and, as
inspiration grabs you, write up that which needs to be written up.


> > > 	2) actual low latency. In order to prevent timing attacks,
> > > 	    packets need to be reclocked, which means adding delay,
> > > 	    which results in higher 'latency'.
> 
> > Also, depending on nature of input, reclocking may not
> > necessarily imply additional average delay, as packets
> > and gaps between them might be simply normalized.
> > randomized and or distributed within the same overall sum.
> 
> 	the only way to do that is by introducing more delay. Which is
> 	fine as far I'm concerned. Because the biggest problem is
> 	fucktards who want to download 100mbs in 2 seconds with no
> 	'latency'. Such assholes need re-education. 


It's not a binary - any type of link that two peer nodes agree to
establish, within the bounds of their config, is just fine.

Depending on my utilitization of a link to a peer, I may then hand
out portions of that link for T time period etc...


> > > any low-latency web onion router - could not defeat The Man
> > 
> > This seems yet to be lacking proof and perhaps
> > cannot actually be said without it.
> 
> 	That's not what I quoted from scum-master syverson. As to how much 'latency' would a better system introduce, that's an 'open question'.

You and grarpamp appear to be saying the same thing...


> 	Also, I forgot to mention the obvious fact that using 3 chained proxies aka 'onion routing' instead of a direct connection generates an amount of 'latency' that can't be avoided. 

Yes, every extra hop is extra inherent latency.

The only challenge I've seen to that is certain fibre optic repeater
kit which simply aplifies and repeats an incoming signal - due to
their funky excitation block, which is analog, there is either
actually no introduced latency, or it's so small as to be not
measurable or something... been a while since I read about that.