On 10/15/21, Peter Fairbrother <peter@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.