Dishonest Tor relay math question - tor-talk is to lazy

[grarpamp]

On 10/15/21, Peter Fairbrother <peter at tsto.co.uk> wrote:
> perhaps I should have said low-latency browsing.

Defining what the end user application is, is required
if you want to design a net to carry it.
If the subject is about tor's feature as currently implemented,
the application scope is therefore narrow, one of only moving
TCP streams across the internet between client and server.
(Users can move UDP and even raw IP over top of that with
OnionCat, but that's no different, and is covered in other threads.)

Nothing about a base layer of chaff prevents
"low-latency browsing" as an application.

> You might perhaps do a reasonably low latency anonymous twitter for
> instance but not low-latency anonymous browsing.

Hardly anyone has developed, released, run, and iterated
over any chaffed or other designs than tor for that browsing
use case, so that probably cannot yet be said.

Tor has vacuumed up, propagandized, sucked the funds from,
steered via proceedings, and effectively killed all the competitive
research and development in the space for last 20 years.
That must end, ignore and stop worshipping Tor, go compete.

> It can matter if traffic is aggregated and an adversary can only see the
> aggregated traffic. It can matter if the adversary uses timing
> information to correlate the input and output traffic to a network
> (which he almost inevitably does).

Self contradicted, so then don't say they can only see the aggregate,
define the cases being for the suggested answers.

An entire class of TA is solely based on matching up i/o
across all nodes to find matches. Certain things don't
matter to such matching engines.

> Not if it was a randomly-variable one year delay they couldn't.

If your app is "browsing", or doing any other TCP stream,
yes they can, such streams have other identifiable
traffic characteristics than just arrival and inter packet timing,
such as total size of transfer, TCP ramps, backoffs, etc.

Tor's hidden services are especially sitting ducks.

> Or if you took the timing data away.

Already explained reclocking as being useful.

> If it was like that, Tor could (and probably would) add a little bit of
> packet size restriction, and that would probably be enough to make it TA
> resistant.

No, TCP streams, their bulk data, etc... endpoints still characterizable.

> It's not TA-resistant because the design requirement for low latency
> buggered the design. You could add lots of covertraffic but it wouldn't
> help much - the lack of aggregation kills it as far as TA goes.

No, a network running a base of chaff already serves the purpose that
these "aggregation" functions tries to do... ie: such as networks with voids
keep scheming up ways to avoid their own voids such as by steering clients
to internal aggregating gravity wells, msg buffer stores, etc based upon
bandwidth weight consensus or other mechanisms.

> And the reason for the lack of aggregation (and no fixed packet sizes)
> is because they wanted low latency.

ATM networks were both low-latency, and fixed packet sizes,
and millions of happy users browsed the web over them,
a prior art proven and in use well before and after tor's birth.

So Tor's design assumptions and direction may well have
been buggered by something else...

Opensource projects are as subject to rat infestation and
influence as are miracle closed source commercial $nakeoil
crypto hardware from fabulously and errantly trusted US and Euro
locations and GovCorps, then just look at Debian, the internet's
history of corrupt "standards" bodies, TOP SECRET nudges
yet curiously missing the non-beneficial ones that are applied, etc...

> That is not the only way to go, though it was famously used in eg the
> US-USSR hotline. It is expensive.

No, the hotline was made up of leased circuits,
they paid the same leased line rate to the telcos whether
they were sending wheat, chaff, or nothing at all over them.
And they could pass precisely no more than the line rate
of the circuit that they provisioned allowed, regardless of
what they were sending.

> And a simple base layer wastes bandwidth.

Explained many times that it doesn't, chaff gets out
of the way and uses the wheat as chaff replacement
while wheat is present.

And if an edge user stuck on stupid limited byte based billing
wants to opt out of the constant chaff base, they can, they
just don't get its benefits and have to fall back on whatever
other defenses the network provides.

> Techniques like
> randomly-variable base rates, traffic aggregation, end-user sharing
> (which among other things blurs the edges of the network), directed
> covertraffic (where the covertraffic looks "guilty"), route splitting,
> latency jittering and so on are available to defeat TA at lesser
> bandwidth cost.

Except the techniques don't necessarily work when your use
case is TCP data streams... "browsing", file transfer, etc...
all have patterns of matching i/o characteristics between endpoints
and/or nodes.

End-users are still end-users at the edge, regardless of
what they share up through, or who else's traffic is moving
through them... without base chaff they are still originating
or terminating their own component of i/o pattern between
them that is unique to only two endpoints.

Streams are notoriously intolerant of failed split routes.
And because their endpoint i/o is still characterizable
and matchable regardless how you randomly or otherwise
spray them across the cloud, that may be of little utility there.

One could talk about broadcast traffic models too...

But again the usage case model application
purpose of the network needs stated.

And herein re tor, it's essentially about carrying TCP streams
of whatever duration and size.

> .. though in the days of acoustic modems it was longer ..

The packet latency / timing of the various physical network
line technologies and their transport inherencies are always
consistant and yes have dropped over time, yet that should not
be confused with the wall time it takes users to stuff some
bloated page, or tera dataset across them.

Inter packet timing, time latency for them traverse a distance,
bandwidth that can be stuffed... are all different, and specific.

> Iirc Mixmaster
> ...
> Per-link chaff might help against some injected traffic attacks, but it
> is not strictly necessary.

Another rather mixing up of use cases and potential designs
between "browsing" and "messaging" (and by extension file
storage and sharing, voice, etc) herein.


The theory proffered by some, and herein and elsewhere,
is that a proper generic base chaff network can address
all of their needs for a TA resistant transport. At least more
resistant, to a net beneficial factor of improvement (say at
least a decimal worth of odds shift more), when compared
to non base-of-chaff networks.

Problem is people keep (dishonestly / fud ...?) trying to dissuade
with "bandwidth" and "unusable non low-latency" claims.

Cypherpunks would actually say fuck that 20 years of noise
and go code up and deploy a few different approaches to
doing base-chaff for testing, just to see and prove out what
is really possible today. Just how well can today's cpu's and
new overlay network software code packet the internet.

> I don't know of any strict anonymity p2p apps.

Not sure what you mean.

Though there's no such thing as 100% anonymity, security, etc...
there are certainly different comparative magnitudes of it available
today, and higher ones are probably quite achievable with some
work on new alternative models.