On 15/10/2021 01:09, PrivacyArms wrote:

To clarify my question: Is there an anonymous network (GPA) for secure/private messaging better than Tor?

Regarding the other question: What can criminals can do to stay anonymous which is outside the law (hacking/stealing computers/wifi), more?

Anonymity is hard, and low-latency anonymity is almost impossible. A brief history: In 1981 David Chaum described mix networks (including onion routing). This was only possible because of the then-recent invention of public key cryptography. This idea was then instantiated as the Cypherpunks anonymous remailer, then the Mixmaster remailer. A further development, Mixminion, was in the works in the early to mid noughties, but was derailed when its chief coder, Nick Matthewson, decided to work on TOR instead. Anonymous remailers could work, but they are pretty much moribund now. The same year, in "True Names", Vernor Vinge described a "feed", whereby short encrypted messages were aggregated and broadcast. Chaum described a similar idea, incorporating dummy traffic, and other plans involving private information retrieval. [2] None of these have come to fruition. So no, there are no "strict" anonymous networks in existence. By "strict" I mean mathematically provable, without requiring trusting another person. Nor are there any effective widely-deployed anonymous networks which only require trusting any one out of many people. There are several less-than-strict techniques, which may or may not work. You could "use other people's computers" by chaining through a few web proxies. You could internet cafes, hack into wifi (perhaps using a box connected via an IR link) or relay through a chain of pwned boxen. Sneaky people might well think of some more, but I wouldn't put them in an email. :) Secure messaging, as opposed to anonymous messaging, where confidentiality rather than anonymity is the requirement, is of course possible - there are several apps, or you could almost write your own (don't do it, I said "almost"!). Just make sure it is really end=to=end and there are NO dedicated [1] servers involved anywhere - there is no cryptographic need for a dedicated server in a secure messaging network. If there is one then you are trusting it to do something; and remember the 6th law: "Only those you trust can betray you." Peter Fairbrother [1] by dedicated I mean you have to use a particular server. If you have to use any one of several servers it might be OK if you (can) run your own server. Or it might not. No server is safer] [2] Chaum's 1981 MS thesis, "Untraceable Electronic Mail, Return Addresses, and Digital Pseudonyms" contains almost all the types of strict anonymous communication ever invented, worth a read. http://www.cs.utexas.edu/~shmat/courses/cs395t_fall04/chaum81.pdf Vernor Vinge's True Names is of course required reading: https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=2ahUKEwjqu4Pr7MvzAhVTglwKHRBJBfEQFnoECAIQAQ&url=http%3A%2F%2Fwww.scotswolf.com%2FTRUENAMES.pdf&usg=AOvVaw0u3GgYC_zdrgFmYrmP2DAA

On 15/10/2021 11:07, grarpamp wrote:

...

Anonymity is hard, and low-latency anonymity is almost impossible.

People keep throwing this "low latency" term around as if it's some kind of distinction, a proven generality, lesser capable to anonymity, than any other particular "latency" level. This is bogus.

There is a smigdin of truth in that, but there's probably more in the simple use of the term low-latency, or perhaps I should have said low-latency browsing. You might perhaps do a reasonably low latency anonymous twitter for instance, but not low-latency anonymous browsing.

Latency is just a timing measure, whether your traffic events, sessions, and characteristics occur over milliseconds, or days, traffic analysis doesn't give a shit.

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). You could drop a 1 year

store and forward packet buffer delay on every interface in the entire tor cloud and the NSA could still analyze it.

Not if it was a randomly-variable one year delay they couldn't. Or if you took the timing data away. 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.

That's because tor's design is hardly TA resistant, not because it's "low-latency".

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. And the reason for the lack of aggregation (and no fixed packet sizes) is because they wanted low latency.

They also use it as apology and to avoid doing dynamic base of chaff, because they are application layer7 people who don't understand how raw packet networks work at <=L3 and how to use them to run a base layer of dynamically yielding chaff to ride your wheat over on demand.

I think you are being overly optimistic/simplistic here. That is not the only way to go, though it was famously used in eg the US-USSR hotline. It is expensive. And a simple base layer wastes bandwidth. 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.

Fixed sizes of cells, etc.

Yeah, that's almost a requirement. Certainly makes life easier.

"Low latency" really just defines the point at which users switch from thinking "Hey this is fast enough to surf the web (or whatever their use case)", to "This shit's too damn slow to do anything, I'm out."

Which is about 4 seconds for web browsing today (a few studies have been published), .. though in the days of acoustic modems it was longer ..

...

Anonymous remailers could work

They're a bit harder since a "message" gets injected into a proper random mix/cloud/buffer, and is not an e2e stream tacked up across it. Yet without chaff on every link, message size controls, etc... they can still fall to TA the same way tor does.

Iirc Mixmaster has message size control. It doesn't have or need specific per-link chaff, but it does have chaff - nobody knows/knew how much, it was added by individual users. Per-link chaff might help against some injected traffic attacks, but it is not strictly necessary.

...

but they are pretty much moribund now.

Still useful if you want to use "E-Mail" addresses over "E-Mail" networks, and should continue to be developed and deployed for that legacy purpose. But for the general purpose of "messaging" they are largely now rightly replaced by dedicated p2p message network apps that don't have to compromise themselves to "E-Mail"s old protocol restrictions and trust model.

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

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.

On Sat, Oct 16, 2021 at 10:24 AM Peter Fairbrother <peter@tsto.co.uk> wrote:

...

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.

Examples?

https://nymtech.net/ Regards Stefan

On Sat, Oct 16, 2021 at 3:34 PM Peter Fairbrother <peter@tsto.co.uk> wrote:

I had a look at the whitepaper - Claudia has outdone herself in describing a system which could maybe work - but, and I quote, "The specific algorithms and implementation details of each part of the system will be fleshed out in separate documents."

There is no proof, or even enough details, to show that it will or even could work. It's all sweeping statements and claims, backed up by - nothing.

Thing is, I don't trust Claudia to get it right (we have a history... ).

The loopix part looks interesting, at first glance. Though "a measure of sender and receiver unobservability" is not exactly reassuring..

Well, I mentioned Nym, because, once in production, it could be an alternative to Tor. They already have a test net running, consisting of several thousand mix nodes and a couple of gateways. The funding they received this year was a couple of million, so let's see how this pans out. Regards Stefan

On Sat, 16 Oct 2021 14:34:40 +0100 Peter Fairbrother <peter@tsto.co.uk> wrote:

Thing is, I don't trust Claudia to get it right (we have a history... ).

Here's yet another chance to try to prove that you're not a governmetn shill =) Go ahead, 'leak' some information.

On 16/10/2021 12:00, grarpamp wrote:

On 10/16/21, Peter Fairbrother <peter@tsto.co.uk> wrote:

...

Except the increased bandwidth cost. And if you have to have padding between each node, or on each link, that becomes very expensive. ... [whatever FUD's/month]

Again, no, users have already bought whatever speed they like from their ISP, they can't shove any more over their link than that, thus there is zero increased expense, the most speed they can ever get is literally exactly what they paid for, they cannot push R bps or N B/m more beyond what they bought, period. And as before, endpoint users on stupid byte rape plans can just opt out of base-chaff, and miss out on the extra protection.

...

Suppose you want to download a bloated web page of 4MB in 4 seconds then Running that 24/7 for a month

No, you only have to run it during the time of your download / activity, plus maybe a few more minutes to sync network metadata, test wan conditions to peer nodes, negotiate overlay speeds and chaff contracts, and start running.

That's good - except an observer can see when you are sending real traffic, somewhere within the burst. And maybe correlate that with some other network i/o - in fact it almost negates any advantage of a base chaff rate.

...

Total size of transfer - compared between whom? UserA and .onion1? But some on userA's and most of .onion1's traffic will be to other people so how does comparing their total size of transfer over a year help?

A's usage may be to zero other people, and Eve runs onion1 which also has no such guarantee, thus whether its 1 minute or 1 decade it's game over for A.

yes, except no - assuming there is some other traffic on the network, how does the attacker know that A's solitary traffic is to onoin1 and not to someone else? And so on Peter Fairbrother

On Sat, 16 Oct 2021 09:23:27 +0100 Peter Fairbrother <peter@tsto.co.uk> wrote:

On 16/10/2021 06:45, grarpamp wrote:

...

On 10/15/21, Peter Fairbrother <peter@tsto.co.uk> wrote:

...

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

Except the increased bandwidth cost. And if you have to have padding between each node, or on each link, that becomes very expensive.

that bit of propaganda has been repeated ad nauseam. Notice that it's exactly what the tor mafia says.

Suppose you want to download a bloated web page of 4MB in 4 seconds then your base flow is >1MB/s. Running that 24/7 for a month, that's 2.5 TB per month. 500 times more than an average user's 50 GB/month..

that's technically correct, except, the point is not to allow some random asshole to download a bloated webpage in 4 seconds cause he's high on meth and can't wait. You are pretending that the only use case is the worst case. And even in that worst case, you can have high rate 'chaff' for a few hours, if the same user is, say, dowloading a movie. So his traffic would get 'mixed' for a few hours, and he would be part of some 'anonimity set'.

On 15/10/2021 19:24, Punk-BatSoup-Stasi 2.0 wrote:

Is that so? Cause if A and B are connected through a 'high speed' fully padded link, they can replace the 'chaff' with their data at will and with very 'low latency'...

And no anonymity whatsoever. Peter Fairbrother

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, October 15, 2021 12:09 AM, PrivacyArms <privacyarms@protonmail.com> wrote:

To clarify my question: Is there an anonymous network (GPA) for secure/private messaging better than Tor?

privacy loves company, so the unpleasant answer to your question is: no, there's nothing remotely as popular as Tor that is also a GPA resistant mix network. ... remember when people ran mixminion? :P [ https://github.com/mixminion/mixminion ]

Regarding the other question: What can criminals can do to stay anonymous which is outside the law (hacking/stealing computers/wifi), more?

one time, a retired person noticed someone connected to their WiFi that was not a client name nor MAC ID recognized. curious, they broke out the directional antenna and packet sniffer to find out the signal was coming from the next door neighbor. odd! being retired, and knowing that they neighbor, they went next door to ask if they were having network trouble, and how they managed to leach the WPA passphrase? alas, the neighbor was none the wiser! their computer was wired into the router. yes, it had a WiFi card, but Ethernet was easier. the neighbor not so technically savvy after all. the retired one taks a look at the desktop. behold! a trojan process. the retired one worked in tech, and knew how to use a disassembler. but it wasn't even that hard - it was a compiled script, and the source was sitting in memory. - --- next the retired person geolocated the command and control host. it was in europe, another country away, but our retired friend also has friends in many countries. time for a visit! arriving on a flight to brussels, a travel agency office was observed at the C&C end. they lease a dedicated line for internet, it was setup a decade ago by the owner's son. they don't know how it works, but it costs 160 euros a month. "mind if i take a look at your router?" the retired one asks? ' sure thing.' a static forward is provisioned between the public port and a private internal address. checking the DHCP/IP assignments (there is a static one assigned to a mystery client) the retired one finds a client associated over wireless, another hop: this one a coffee shop across the street. - --- in the cofeee shop our retired one followed the signal analyzer to its natural conclusion : a USB powered SoC under a table with an antenna in the direction from whence just travelled! but where does it go? a dual radio SoC, not unsimilar to a pineapple, the local side was leeching coffee house WiFi for upstream. *sigh* time to tear apart the sdcard ... [ break for refreshments ] "damnit! a wireguard tunnel to a bullet proof hosting server!" our retired person is again compelled to travel. this time a friend of a friend who runs the hosting service for bitcoin and monero. sheer luck we happened to have a contact! calling in a favor, our retired adventurer found the customer. there is no contact or registrar info, of course. but this IP address looked familiar! - --- back at the coffee shop, with a new MAC ID to hunt for, a woman in the rear corner of the store sticks out as signal source. "excuse me, are you a hacker?", our retired friend asks. 'yes.. i saw you looking for something. i thought it might be me', she says with a sly smile. 'how did you find me?' [ our retired subject explains the process of recusion ... after many minutes, reaching the terminus in this tale. ] 'ah, that explain it.' she says satisfied. 'my threat model was law enforcement, not batshit crazy!' THE END. -----BEGIN PGP SIGNATURE----- iNUEAREKAH0WIQRBwSuMMH1+IZiqV4FlqEfnwrk4DAUCYWm0FF8UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0NDFD MTJCOEMzMDdEN0UyMTk4QUE1NzgxNjVBODQ3RTdDMkI5MzgwQwAKCRBlqEfnwrk4 DCSEAP9pB8KNe7Ai4wJqIaObCbvThGP9efsbDVv5X+dDTs1YIgD+J/hBJICF+zhy uWrcEy4ToP28cd3cYZlMegBiOZaeCs4= =7dJX -----END PGP SIGNATURE-----

On 10/14/21, PrivacyArms <privacyarms@protonmail.com> wrote:

On Thursday, October 14, 2021 9:55 PM, Punk-BatSoup-Stasi 2.0 <punks@tfwno.gf> wrote:

...

As a side note, have you looked into freenet?

Whether GPA or cheap Sybil, traffic analysis, endpoint matching, etc works against most of todays different types of networks. And they all have similar types of things going on... https://hacker10.com/internet-anonymity/police-plants-own-computers-in-freen... https://www.reddit.com/r/Freenet/comments/4ebw9w/more_information_on_law_enf... https://retro64xyz.github.io/assets/pdf/blackice_project.pdf https://endchan.net/pedf/ https://duckduckgo.com/?q=black+ice+freenet WoT's are interesting and very useful, but do require rigorous adherence to the trust model and assertion levels, and are hard to quantify beyond various degrees of separation, entire regions of trust space can become corrupted, same as in real world.

https://therecord.media/a-mysterious-threat-actor-is-running-hundreds-of-mal... A mysterious threat actor is running hundreds of malicious Tor relays... If you knew how many nodes have been both removed since years, and how many are still running and coming every day, you would shit yourself. Not 10's, not 100's, not 1000's... But Tor Project censors and fails to disclose that because it wants to keep certain thing$ flowing in. People have tried pointing the problems out for safety of the tor users to consider on their own, but Tor Project censors that. Yes, it is true that Tor is subject to rampant node infestation and has been since decades... Tor Project even hired a CIA agent, and a wife of another agent, and military contractors, and more. People in that article are not first to find or speak of mass bad nodes, but Tor Project has liked to bury it. What is also true about Tor Project Incorporated, is that when people bring up the fact of Sybil and Traffic Analysis attacks on tor, bring that and many other problems with the Tor Project up in any of their public fora, the Tor Project and its staff people all freespeech hypocrites repeatedly CENSOR and prevent tor users from seeing that free speech, they kick you out of their little project, etc. Tor has literally in their own action item words "bricked up" their fora. Very much is wrong with Tor Project $ince years now. Latest was false advertising defrauding NFT buyer of $2M. It's long past due, not just to be forked away from all that mess, but for entirely new projects to startup from new people, develop new overlay networks with active fulltime anti-TA chaff in the base layer, WoT's and other anti-Sybil mechanisms, etc. All which can see by search the famously quote... "Tor Stinks -- NSA".

https://www.hackerfactor.com/blog/index.php?/archives/944-Tor-0day-Snowflake... https://www.hackerfactor.com/blog/index.php?/categories/19-Tor Tuesday, 21 December 2021 Back in 2020, I wrote nine blog entries about Tor that covered a wide range of vulnerabilities. Many of them were well-known to the Tor Project (some nearly a decade old!) but had never been addressed and had no viable mitigation options or alternatives. Other issues were brand new and first disclosed on my blog. (The last blog entry begins with a summary of the vulnerabilities.) Of all of the vulnerabilities and concerns that I raised in 2020, the Tor Project didn't address any of them. Zero. Over the past year, there were over a dozen updates for the Tor daemon (and that's not counting the pre-releases). There were also over a dozen updates to the Tor Browser (from version 10.0.8 to 11.0.3), but most of these were basically incorporating updates from Firefox. The main Tor-specific changes were the deprecation and removal of onion v2 support (replaced by v3 addresses) and the formal release of snowflake as a pluggable transport. Some of my "Tor 0day" blog entries mentioned a lack of good pluggable transports for when someone blocks direct and indirect (bridge) connections. Snowflake introduces another connection option, but it has its own serious limitations and is far too detectable. Still Viable Exploits My "Tor 0day" blog series focused on one specific scenario: Can someone watching the network traffic determine if you (specifically you) were using Tor? For example, many companies do not permit Tor within the corporate network. This restriction prevents malware from downloading past the corporate anti-virus scanners and deters someone from potentially leaking company-confidential information. These companies don't mind if you use Tor on your home network and home computer; just not on anything that touches the company's network. For these companies, it is one thing to have a rule about "no Tor", but it's another to enforce the rule by detecting and immediately blocking anyone who violates the rule. This threat vector is also seen when countries block access to Tor. Earlier this month, the Tor Project made an announcement that Russia was blocking Tor. What they didn't mention was that these blocks were made possible using the exact same methods disclosed in my blog series a year earlier. Moreover, the Tor Project had known about these issues for years. The Tor Project's alert about Russia was really just a complaint that people were blocking their service through exploits that the Tor Project hasn't felt like fixing. The Open Observatory of Network Interference (OONI) is an organization that tracks online censorship. About 10 days after the Tor Project's announcement, OONI posted their report. According to OONI, it wasn't all of Russia blocking Tor; it was 15 out of 65 subnets. Moreover, each censorship instance used a different blocking method: In some cases though (such as on AS42437), OONI data suggests that access to torproject.org is being interfered with by means of a TLS man-in-the-middle attack, while in other cases (such as on AS51570), we observe that the connection is reset once the TLS handshake has been initiated, suggesting the use of Deep Packet Inspection (DPI) technology. If the censorship was government-sponsored, as the Tor Project suggested, then I would expect it to be much more widespread and consistent. This looks like individual blocking efforts. As OONI noted, the blocks followed a "recent spike in the use of Tor bridges (used for circumventing Tor blocking) in Russia." To me, this looks like ISPs having a problem with Tor users. Tor is often viewed a bad neighborhood since it is often associated with other criminal activities, like human trafficking and drugs. By blocking Tor access, these services reduce the number of bad actors on their networks. This censorship also means that these ISPs could easily detect Tor bridges (as noted in my second Tor 0day blog entry.) If the Tor Project actually provided anonymous or less detectable bridges, then this filtering would never have happened. Similarly, this year Tor researcher Nusenu found that one persistent threat group (KAX17) had managed to create thousands of Tor nodes. With that many nodes, they can easily decloak hidden services and track individual users. This group has been around since at least 2017 and the Tor Project's efforts to remove them have been ineffective. (See my 6th blog entry for more details.) Pluggable Transports Tor uses pluggable transports as alternative protocols for connecting to the Tor network. My second blog entry shows how to detect and block all production pluggable transports. Moreover, code had been deployed and was working in real-time on high-volume networks. (As an aside: as far as I know, my code is not being used for those Russian blocks.) I had previously mentioned that the Tor Project had dropped support for all pluggable transports except obfs4 and meek, and meek was being shut down by various cloud providers. In effect, the Tor Project was putting all of their eggs in one basket (obfs4) and hoping that ISPs wouldn't block it -- even though it was trivial to detect and filter. Obfs4 acts as a trojan protocol. It sends encrypted communication over a known port, like 22/tcp (normally used by Secure Shell) or 443/tcp (normally used by HTTPS). It's a trojan protocol because it doesn't speak the right language when using a well-known port. Any kind of stateful packet inspection at the session or application layer will easily detect it. Meek depends on TLS tunneling. I currently have a couple of methods for easily detecting Tor's use of meek. The Tor Project's solution was to introduce a new pluggable transport: snowflake. Snowflake had been a work-in-progress since 2016 and takes a different tunneling approach. It pretends to be a WebRTC (video chat) communication stream. WebRTC relies on a couple of protocols, including STUN and ICE. (The name 'snowflake' is because it is related to the ICE communication protocol. It is not intended as a derogatory term.) Detecting Snowflake Of all of the pluggable transports that the Tor Project has released, I think snowflake is the easiest to detect. I'm not saying that the others were difficult to detect and filter. Rather, the other protocols (fte, obfs3, obfs4, meek, etc.) only had a few ways that they could be detected. Snowflake has literally dozens of trivial ways to detect it. For example, video chats rely on a protocol called STUN (Session Traversal Utilities for NAT; network address translation). Basically, STUN identifies your external network address. This is needed to establish any kind of video chat when you use a firewall. Snowflake uses a hard-coded list of available STUN servers. The current list is: stun.voip.blackberry.com:3478 stun:stun.altar.com.pl:3478 stun:stun.antisip.com:3478 stun:stun.bluesip.net:3478 stun:stun.dus.net:3478 stun:stun.epygi.com:3478 stun:stun.sonetel.com:3478 stun:stun.sonetel.net:3478 stun:stun.stunprotocol.org:3478 stun:stun.uls.co.za:3478 stun:stun.voipgate.com:3478 stun:stun.voys.nl:3478 When the snowflake client first starts up, it queries DNS for a randomly selected subset of these STUN servers. It looks for the hostname resolution using both IPv4 and IPv6 (DNS 'A' and 'AAAA' records). However, it doesn't just look up the hostnames; it checks if the name is on the local network. Like most companies, my lab uses a private network behind the firewall and runs an internal DNS server. All computers on my private network use the domain name "internal.lan". When I started snowflake, I immediately saw a set of DNS queries for the STUN servers: client -> dnsserver : DNS Query Type[28]=AAAA Name='stun.epygi.com' client -> dnsserver : DNS Query Type[28]=AAAA Name='stun.voipgate.com' client -> dnsserver : DNS Query Type[1]=A Name='stun.epygi.com' client -> dnsserver : DNS Query Type[28]=AAAA Name='stun.sonetel.net' client -> dnsserver : DNS Query Type[28]=AAAA Name='stun.epygi.com.internal.lan' client -> dnsserver : DNS Query Type[28]=AAAA Name='stun.voipgate.com.internal.lan' client -> dnsserver : DNS Query Type[28]=AAAA Name='stun.epygi.com.internal.lan' client -> dnsserver : DNS Query Type[28]=AAAA Name='stun.voipgate.com.internal.lan' Each line is one packet, and all of this happened in one second. This means that I have multiple ways to detect a Tor snowflake client before it even tries to connect to the Tor snowflake server! A single WebRTC client typically connects to one STUN server. If you see a single client immediately lookup multiple STUN servers and all of the servers are in the snowflake hard-coded list, then you've found a Tor snowflake client. Regular WebRTC clients do not do hostname lookups for remote STUN servers on the local network. If you see any DNS lookups for snowflake's STUN servers on the local network (stun.epygi.com.internal.lan, stun.voipgate.com.internal.lan, etc.) then you've found a Tor snowflake client. About a second later -- after doing the DNS lookups -- there are queries for the snowflake hard-coded domain fronting server: client -> dnsserver : DNS Query Type[1]=A Name='cdn.sstatic.net' client -> dnsserver : DNS Query Type[1]=AAAA Name='cdn.sstatic.net' Again, if you see any IP address that first does a DNS lookup for a snowflake STUN server and then does a lookup for the snowflake domain fronting service, then you've found a Tor snowflake client. These are just 3 ways for an administrator to watch DNS in order to detect or block Tor snowflake users before they can connect to the Tor network. There are another dozen ways to detect snowflake (zero false positives, zero false negatives) if you start looking at how it uses STUN and ICE. In addition, a snowflake client can be used to identify the IP addresses of other Tor users because other Tor users provide the snowflake proxies. (The entire snowflake protocol strikes me as a project created by a group that put no consideration into how an adversary might detect or block this pluggable transport.) I want to emphasize the warning from my earlier blog entries: If you are in a location where using Tor can result in an arrest, being tracked by government agents, or losing your job, then do not rely on snowflake for anonymity or to protect your privacy. The Tor Project provides zero solutions if you are located in a repressive location. Tor: State of the Onion Earlier this year, I attended the Tor Project's online "State of the Onion" presentation. During the presentation, different members spoke about all of the great things that the Tor Project was doing to advance online privacy, anonymity, and anti-censorship. They even praised snowflake as a success. If you didn't know the technical details, then you might get the impression that this was very positive and incredible forward movement. The amount of spin from the Tor Project was as good as any nation-state or political announcement. But behind the scenes? They haven't addressed any of their core issues. If someone wants to track you through Tor, deanonymize your network activity, or prevent you from accessing Tor, then they can do it and you cannot stop them. And if you do something illegal over Tor and you haven't been arrested, then it's only because there are bigger villains than you; you're not a high priority -- yet. Today, the Tor Project seems to be more focused on fund raising than actual privacy, anonymity, or anti-censorship. I wonder if they will ever start fixing these known issues.

The NSA actively targets projects like Tor, to reduce and coopt their effectiveness. Appelbaum wrote about and cited this in his thesis.

It would be no surprise if spy agency workers were employed in Tor. It is no surprise if they are also employed in other anonymity, privacy, security, and software and hardware freedom projects. It is of interest how much, where, and to what ends.

...

Appelbaum wrote about and cited this in his thesis.

applebaum is an asshole who was paid 100k per year to promote the tor cyberweapon and US imperialism. Like you do.

Karl is so stupid, I don't even think he's reading that thesis.I don't think he'd understand even if he read the thesis.And he still says Tor has been targeted. The Tor project is targeting people.He doesn't understand privacy, but he talks here. He's just talking to be talked to.Tor team leader Gus asked me a few questions, and then the Tor project blocked me.Lol.Tor never gave anonymity, they just followed people.

"Tor Stinks -- NSA, known since before 2012"

Tor Project: Still Infested With Many Conflicts Of Interest, and with many problems that have been outlined for decade, not weeks, that Tor Project and its minions still put users at risk by refusing to mention, not least because it wouldn't be good for business. People should write code for new overlay networks to route around them. The Role of the Tor Project Board and Conflicts of Interest https://blog.torproject.org/role-tor-project-board-conflicts-interest/ by isabela | October 3, 2022 Over the last couple of weeks, friends of the Tor Project have been raising questions about how Tor Project thinks of conflicts of interest and its board members, in light of the reporting from Motherboard about Team Cymru. I understand why folks would have questions, and so I want to write a bit about how the board of directors interacts with the Tor Project, and how our conflict of interest process works. The Role of the Board First off, a word about non-profit boards of directors. Although every non-profit is unique in its own way, the purpose of a board of an organization like The Tor Project, with a substantial staff and community, is not to set day-to-day policy or make engineering decisions for the organization. The board's primary role is a fiduciary one: to ensure that Tor is meeting its obligations under its bylaws and charter, and “hire/fire” power over the executive director. Although staff members may consult board members with relevant expertise over strategic decisions, and board members are selected in part for their background in the space, the board is separate from the maintenance and decision-making on Tor's code, and a board seat doesn't come with any special privileges over the Tor network. Board members may be consulted on technical decisions, but they don't make them. The Tor Project's staff and volunteers do. The Tor Project also has a social contract which everyone at Tor, including board members, has to comply with. When we invite a person to join the Board, we are looking at the overall individual, their experience, expertise, character, and other qualities. We are not looking at them as representatives of another organization. But because Board members have fiduciary duties, they are are required to agree to a conflict of interest policy. That policy defines a conflict as “...the signee has an economic interest in, or acts as an officer or a director of, any outside entity whose financial interests would reasonably appear to be affected by the signee's relationship with The Tor Project, Inc. The signee should also disclose any personal, business, or volunteer affiliations that may give rise to a real or apparent conflict of interest.” Handling Conflicts of Interest Like most conflict processes under United States law, non-profit conflicts rely on individuals to assess their own interests and the degree to which they might diverge. The onus is often on individual board members, who know the extent of their obligations, to raise questions about conflicts to the rest of the board, or to recuse themselves from decisions. It also means that conflicts, and perceived conflicts, change over time. In the case of Rob Thomas's work with Team Cymru, the Tor Project staff and volunteers expressed concerns to me at the end of 2021, spurring internal conversations. I believe it is important to listen to the community, and so I worked to facilitate discussions and surface questions that we could try to address. During these conversations, it became clear that although Team Cymru may offer services that run counter to the mission of Tor, there was no indication that Rob Thomas's role in the provision of those services created any direct risk to Tor users, which was our primary concern. This was also discussed by the Board in March and the Board came to the same conclusion. But of course, not actively endangering our users is a low bar. It is reasonable to raise questions about the inherent disconnection between the business model of Team Cymru and the mission of Tor which consists of private and anonymous internet access for all. Rob Thomas's reasons for choosing to resign from the board are his own, but it has become more clear over the months since our initial conversation how Team Cymru's work is at odds with the Tor Project's mission. What's Next We at Tor, me, the board, staff and volunteers, will continue these conversations to identify how to do better from what we have learned here. I have been working with the board to see where things can be done better in general. One of these initiatives is changing the Tor Project's board recruitment process. Historically, recruitment for board slots has been ad hoc - with current board members or project staff suggesting potential new candidates. This selection process has limited the pool of who has joined the board, and meant that we do not always reflect the diversity of experiences or perspectives of Tor users. For the first time we are running an open call for our board seats. Although this may seem unrelated to the idea of conflicts, we believe that more formalized processes create healthier boards that are able to work through potential conflict issues from a number of different angles. Finally, let's talk about infrastructure for a moment. Our community has, rightly so, also raised concerns regarding the Tor Project usage of Team Cymru infrastructure. Team Cymru has donated hardware, and significant amounts of bandwidth to Tor over the years. These were mostly web mirrors and for internal projects like build and simulation machines. Like all hardware that the Tor Project uses, we cannot guarantee perfect security when there is physical access, so we operate from a position of mistrust and rely on cryptographically verifiable reproducibility of our code to keep our users safe. As we would with machines hosted anywhere, the machines hosted at Cymru were cleanly installed using full disk encryption. This means that the set up with Team Cymru was not different from any other provider we would be using. So the level of risk for our users was the same when we used other providers. But given the discussion of conflicts above, it's not tenable to continue to accept Team Cymru's donations of infrastructure. We have already been planning to move things out since early 2022. It is not a simple, or cheap task to move everything to some other location, so this process is going to take some time. We've already moved the web mirrors away, and are working on the next steps of this plan to completely move all services away from Team Cymru infrastructure. We thank the community for its patience with this process. We encourage respectful, on-topic comments. Comments that violate our Code of Conduct will be deleted. Off-topic comments may be deleted at the discretion of the moderators. Please do not comment as a way to receive support or to report bugs on a post unrelated to a release. If you are looking for support, please see our FAQ, user support forum or ways to get in touch with us. 1 reply Without wishing to sound ignorant, could somebody please tell me what the disagreeing specifically surrounds?

https://www.techdirt.com/2014/10/06/documents-released-silk-road-case-add-mo... https://nusenu.medium.com/is-kax17-performing-de-anonymization-attacks-again... https://www.courtlistener.com/?q=%22tor%22%20%22foreign%20law%20enforcement%22%20%22fla%22&type=r&order_by=score%20desc&filed_after=05%2F05%2F2019 https://casetext.com/case/united-states-v-anzalone-16 https://casetext.com/case/united-states-v-bateman-22 https://blog.torproject.org/tor-security-advisory-relay-early-traffic-confir... https://www.vice.com/en/article/qjp7eq/fbi-paid-charity-for-hacking-tools-ni https://www.washingtontimes.com/news/2023/jan/10/fbi-reveals-it-uses-cia-and... The FBI Won't Say Whether It Hacked Dark Web ISIS Site https://www.vice.com/en/article/z34dx3/fbi-wont-say-hacked-dark-web-isis-sit... The FBI somehow obtained the IP address of someone who allegedly visited an ISIS-related site on the dark web. The DOJ is blocking discussion of the issue from entering the public docket. by Joseph Cox January 11, 2023, 2:00pm Hacking. Disinformation. Surveillance. CYBER is Motherboard's podcast and reporting on the dark underbelly of the internet. See More → U.S. government lawyers are hampering efforts that could reveal how the FBI managed to obtain the real IP address of an alleged visitor to an ISIS website on the dark web, according to court records reviewed by Motherboard. The case involves Muhammed Momtaz Al-Azhari, who was charged in May 2020 with attempting to provide material support to ISIS. According to the complaint against him, Al-Azhari allegedly visited a dark web site that hosts "unofficial propaganda and photographs related to ISIS" multiple times on May 14, 2019. In virtue of being a dark web site--that is, one hosted on the Tor anonymity network--it should have been difficult for the site owner's or a third party to determine the real IP address of any of the site's visitors. Advertisement Do you know anything else about the FBI's use of NITs? We'd love to hear from you. Using a non-work phone or computer, you can contact Joseph Cox securely on Signal on +44 20 8133 5190, Wickr on josephcox, or email joseph.cox@vice.com. Yet, that's exactly what the FBI did. It found Al-Azhari allegedly visited the site from an IP address associated with Al-Azhari's grandmother's house in Riverside, California. The FBI also found what specific pages Al-Azhari visited, including a section on donating Bitcoin; another focused on military operations conducted by ISIS fighters in Iraq, Syria, and Nigeria; and another page that provided links to material from ISIS's media arm. Without the FBI deploying some form of surveillance technique, or Al-Azhari using another method to visit the site which exposed their IP address, this should not have been possible. Now, in a recent series of filings, Department of Justice lawyers won`t say how the agency accessed Al-Azhari`s IP address, and are blocking discussion of the issue from entering the public docket. "In discovery, the Government has declined to provide any information related to its TOR operation," Samuel E. Landes, the defense attorney working on the case, wrote in a filing published Tuesday. The news highlights the Department of Justice`s continued and intense secrecy about its use of hacking tools, despite them becoming more popular in a wide range of types of criminal investigations. The knock-on effects of that secrecy can be that defendants do not have access to details of how they were identified, and don't have an opportunity to effectively challenge its legal basis. In some cases, prosecutors have also lost chances of convictions because keeping the tools secret was deemed more important than winning a case. Advertisement In the motion filed Tuesday, Landes writes that government prosecutors have successfully demanded his motion to compel for more information be marked as a "highly sensitive document." That designation is used for documents that may be of interest to the intelligence service of a hostile foreign government, and use of which by the foreign government would likely cause significant harm, Landes filing says. Landes' latest filing is a subsequent motion asking the court to reconsider giving that designation to his earlier motion. Tech The FBI Hacked Over 8,000 Computers In 120 Countries Based on One Warrant Joseph Cox 11.22.16 [IMG] Landes points to how the FBI's use of network investigative techniques (NITS)--the DOJ's euphemism for hacking tools--is far from a secret, having been used in multiple cases over the years. He says he also found an exhibit filed in other cases with similar issues and is widely available on the internet. Despite the public availability of this information, the government asked the court to treat the motion to compel as a highly sensitive document, Landes writes. The Department of Justice declined to comment. In other cases, the DOJ has decided to stop pursuing convictions altogether rather than provide defendants with more information on how they were identified. In 2015 the FBI took over, and hacked thousands of visitors to, a dark web child abuse site. While the operation did ultimately secure many convictions, prosecutors refused to abide by an order from the court to provide the defense team with the NIT exploit code. The judge threw out the evidence in response, killing the case. The NIT was based on a "non-public" vulnerability. https://www.cnet.com/tech/tech-industry/fbi-wants-to-eavesdrop-on-fiber-link... https://www.cnet.com/news/privacy/fbi-said-to-be-taking-a-hacker-approach-to... https://www.cnet.com/tech/services-and-software/fbi-may-widely-monitor-compu... https://www.cnet.com/tech/tech-industry/fbi-pressures-internet-providers-to-... https://www.cnet.com/culture/fbi-wants-widespread-monitoring-of-illegal-inte... https://www.cnet.com/tech/tech-industry/transcript-fbi-director-on-surveilla... https://www.cnet.com/news/privacy/fbi-quietly-forms-secretive-net-surveillan... https://www.cnet.com/tech/mobile/the-fbi-wants-to-read-your-email/ https://www.cnet.com/news/privacy/nsa-likely-targets-anybody-whos-tor-curiou... https://www.cnet.com/news/privacy/accessing-your-internet-browsing-history-i... https://www.cnet.com/tech/services-and-software/fbi-digs-deeper-into-the-web...

/2 https://arxiv.org/pdf/1801.02265.pdf https://arxiv.org/pdf/1808.07285v1.pdf These two papers are over five years old. Tor Project Incorporated knew about them and their classes of attacks and refused to tell their users about them and the risks to their safety. Tor Project Incorporated also refused to tell their $donors about these papers and Tor's failure to bother addressing them. Yet no media ever wonders why or bothers to call them out. https://twitter.com/NameRedacted247 #TwitterFiles In fact, the media, which have been proven to be agents of the deep state, often cheers Tor, and media like the NYT run onion leak drop sites, while correlators watch their connections like hawks. "... they can correlate ... this was understood ... not just when we first made Tor, but for pre-Tor versions of onion routing. ... the paper being discussed substantially improves [attacks] ... ... reduce your sense of alarm ... ... the novelty is somewhat overstated -- Paul Syverson US Military Employee 2023/02" Lol Tor Project Executives and Principal devs knew, yet still foisted, and are still foisting, Tor upon the world anyway. And Tor Project Inc removed all warnings about tor from their frontpage and other places over decade ago. Tor Project Inc has placed tor users at risk.

So you wouldn't say that Tor is good since it is the least worst way for people to browse? It is definitely not perfect but perhaps it could generate more noise in which to bury the few signals that are out there? On Wed, 5 Apr 2023, grarpamp wrote:

"Download Tor Browser to experience real private browsing without tracking, surveillance, or censorship. -- Tor Project Homepage, April 2023"

The Tor Project Incorporated is flat out lying and has been putting its users at risk since decade+.

"Tor Stinks -- NSA, vulns known since before 2012"

On Thu, 6 Apr 2023, grarpamp wrote:

On 4/5/23, efc@swisscows.email <efc@swisscows.email> wrote:

...

So you wouldn't say that Tor is good since it is the least worst way for people to browse?

Users getting jailed or murdered by the State's traffic analysis and sybil systems is for them perhaps the worst way to die. Does voting for least worst politicians get you much of anything in your lifetime, vs ignoring, defunding, routing around and removing them all permanently.

I think want does not exclude the other. I could vote for the least worst, at the same time I could tax plan aggressively and route around. I don't work at the moment, but I have managed to plan my way down to around 9% taxes or so. The same goes for users. Some do get jailed but at the same time I am convinced that low profile targets benefit even though it is not perfect. But I do give you this much, no one should use this service in the belief that it is a foolproof way to hide your tracks and I think the project should be very clear about that. I like the principle "free, informed, consent" and if there is no information, there can be no free, informed consent.

...

It is definitely not perfect but perhaps it could generate more noise in which to bury the few signals that are out there?

The real solution is to both fork tor, and also to design and compete entirely new network overlays.

"Tor Stinks -- NSA, vulns known since before 2012"

I was not aware of this, so thank you very much for informing. When it comes to forking tor there is another problem though, and that is all the infrastructure. Like FB, tor has some strong networking effects so starting from scratch would be tough. I do hope that someone does fork though, and that a new, stronger and less woke project might take over instead. As a fun side note though, I do know how quirky the tor guys can be. Many years ago I tried to reach out to persuade them to develop an "addon" or separate project utilizing parts of tor that would be a global, decentralized DNS system without the hops to reduce latency. I was met with complete silence, so I would not be surprised if things get ignored. ;)

On 4/6/23, efc@swisscows.email <efc@swisscows.email> wrote:

On Thu, 6 Apr 2023, grarpamp wrote:

...

On 4/5/23, efc@swisscows.email <efc@swisscows.email> wrote:

...

So you wouldn't say that Tor is good since it is the least worst way for people to browse?

Users getting jailed or murdered by the State's traffic analysis and sybil systems is for them perhaps the worst way to die. Does voting for least worst politicians get you much of anything in your lifetime, vs ignoring, defunding, routing around and removing them all permanently.

The same goes for users. Some do get jailed

If has been repeatedly suggested for years that people start a canary project to search for any suspected "analytical breakthroughs [William Binney]". Start collating and dissecting all court cases involving Tor and other leading supposedly resistant protocols and cryptoprivacy. Analyze cases, Interview the subjects. A Jewel that is used, is a Jewel that can be discovered, and you can bet that many Jewels are being used, in a trivially discoverable haphazard fashion, so as to guide infer as to what the current state and use of the real Family Jewels are.

From Wikileaks to Snowden to the recent Twitter Files and even more revelations of mass political corruption and info operations, only fools would believe there is nothing in operation worth finding... or at least worth rationally speculating on in yearly Symposium dedicated to that.

An approximate to some degree on "information" can be derived by careful postulation and calculatory estimates supported by history, current facts, funds, intents, trends, open sourced info, etc. History shows these have often wrote what later turned out to be true.

But I do give you this much, no one should use this service in the belief that it is a foolproof way to hide your tracks and I think the project should be very clear about that.

Watch Tor's videos, some say a roomfull of canaries could drop dead and TPI would still not include any potentially embarrassing clarity about adversarial attacks in their talks. In fact, in the rare times when TPI ever mention this fact of the slide deck "Tor Stinks -- NSA, vulns known since before 2012" they twist it and dodge and weasel around the obvious between the lines fact of that slide deck regarding the adversaries existing and advancing attacks. And how many times in last year did Tor Project disclose these at least 11+ year old facts, among others, to its users... ZERO. Tor Project literally committed changes to their front page and other pages that removed long standing warnings to their users, yet the design and security of the tor network did not improve in any manner that would support the removal of such warnings. In fact, some analysts would say that tor has grown continually weaker, relatively speaking, at the feet of advances in its adversaries analytical and active capabilities.

I like the principle "free, informed, consent" and if there is no information, there can be no free, informed consent.

Again, in just this month alone, TPI has yet again, completely censored information that users could use to help determine their own risk and consent. Not only did TPI censor it, they made no attempt to refute it, thus crediting it by default.

...

The real solution is to both fork tor, and also to design and compete entirely new network overlays.

"Tor Stinks -- NSA, vulns known since before 2012"

I was not aware of this, so thank you very much for informing. When it comes to forking tor there is another problem though, and that is all the infrastructure. Like FB, tor has some strong networking effects so starting from scratch would be tough. I do hope that someone does fork though, and that a new, stronger and less woke project might take over instead.

As to forks, if forks want an instant nodebase, for so long as the protocol of the new fork is able without safety compromise to remain backward compatible with the old tor, the new fork can simply do API module to import old tor's live nodelist and route its traffic over old tor nodes as desired. Besides, at this point Tor Project is so bad as a project that any well announced fork (and any entirely new competing network designs) would have volunteer node operators showing up in no time. TPI has been so busy vacuuming up all the Money Talk and Conferences in the room, which is a suspect in itself how that [psyop] has happened, that some Devs Users Operators and Funders have forgot they have the Right and Freedom and Imperative to Code and Launch and Fund competing projects. And to speak freely about and critique elephants in rooms.

I tried to reach out to persuade them to develop an "addon"

Another addon called OnionCat is being killed by Tor (hardly under any non-nebulous reasons that cannot be acceptably modularized) thus killing all users apps that do use, and all development of all future apps that could use, the protocols it provides. Given capacity and security were rationales that users contested, again without response, could there be speculations on why there is killing off of an entire protocol stack of potential future privacy enhanced apps...

I was met with complete silence

Your various experiences and observations with Tor are not unique. There are others who have discovered problems with Tor. But they may be afraid to speak out, or from their industry, or simply don't know that there are others to stand with, because Tor censors all their fora, so where would they go to find each other. TPI has even kicked people out of Tor Project for speaking freely in the interest of tor users, and or maintaining a different independence from the Tor Mob, and TPI even manufactured lies to them about why. And where can users go to find "information", because what competing review services have mentioned project issues and adversarial risks. That's another review project people could do :) Regarding this entire thread and many others on Tor here and elsewhere over years... On 5/18/23, Undescribed Horrific Abuse, One Victim & Survivor of Many <gmkarl@gmail.com> wrote:

it's really heartening to see this post to the tor lists

If you actually bothered to check the tor archives, you would discover that in fact the "moderator [1]" aka Tor Project Incorporated has blocked the post off all four of its lists. So no one on them saw it on any of them. In fact, Tor Project Incorporated has blocked and refused to post dozens of perfectly legitimate open posts and points made by multiple people over the years. Clearly, Tor Project Incorporated is defrauding its users from seeing discussing and gaining potential knowledge and protections regarding tor's not broadly known to users, intentionally disadvertised and whitewashed away from sight, fatal design flaws and conflicts of interest, among other problems. Tor Project Incorporated is thus putting its users at substantial risk. Tor Project Incorporated is plainly resorting to CENSORSHIP to hide some embarassing things... including its GovMil designed funded and operationally governed software, and Govt funded programs and Govt funded staff's career monied interests above users, and certainly now many might say is suspect of keeping its design weak perhaps to support any ties to user adversaries such as the GovMil NSA CIA and partner entities incl ISP's. Tor design has stayed 25 years old, while threats advanced light years, yet Tor Project Incorporated chooses silence refusing to even publicly speculating on design weakness in such wide public needed and vocal manner so as to inform warn users of some real issues. Yet CIA and more now advertise to "Use Tor". Such SpyVeillors, DataMiners, and agencies and entities are not willfully in the habit of globally recommending to the world that which they cannot crack. Tor Project is presenting a growing discongruence with at least now what are surely huge advancements in adversarial capabilities if not dire abject realworld application of same... and no one is talking about it. TPI is so afraid of embarassing things that even after declaring themselves to be hypocrites "bricking up" fora counter to their faux professed free speech principles, thus killing their lists, that they still laughably CENSOR those dead lists. Must be damning info to go to all that effort. Tor Project has been caught disencouraging vulnerability researchers. And caught acknowledging its intentional extensive censorship of its fora. TPI must be held to account. tor needs to be forked. And other completely new overlay network designs need to be created, coded, openly competed, and rolled out into operation. [1] Moderator: noun, one who facilitates free open conversations, not one who total blanket CENSORBANS all conversations and topics off all channels entirely. "Tor Stinks -- NSA, vulns known since before 2012" Censorship loses, Freedom wins.

The hypocrite anti-freespeech frauds at Tor Project Incorporated have deleted frontend mailman links to the Tor-Talk Archives and shutdown the tor-talk mailing list claiming that it was "unused". However any search for "tor-talk" on this list will prove that that's a straight up fucking LIE. The TRUTH is that the TPI has CENSORED dozens of messages off their list to prevent embarrassing truths and valid conversations about TPI and tor from reaching their users, funders, devs, and the press. And now they've deleted frontdoor from view thus burying archives which contained some valuable embarassing proofs over the years. FreeSpeech and users and others did not "unuse" the tor-talk list, TPI are the ones who censorbanned everyone off it, especially those critique in favor of users, thus making it useless for users. TPI dictators were too cowardly to even post tor-talk to ask subs if they still wanted use it, doesn't matter, the TPI doctrine would have censored and ignored all the replies seeking to keep it anyways. Freedom of Speech used to exist at TPI, now they're dangerous hypocrites. Gus and pals and all the rest at TPI are censors who are putting tor users at risk. TPI is obviously so desperate of being publicly exposed of tor's flaws and conflicts of interest and everything else that they have waged censorship for years. Shame on Tor and all its cowardly cabal. ps: Links and files full of tor internal comms are always welcomed here and to this inbox.

So, the Tor Project Incorporated just censored 1000+ independent nodes off of the legacy tor network, and TPI is so cowardly they can't even mention the name of and link to the competing project on their blog. Wherein, the woke socialists at TPI also attempted to take a swipe at how Free-Market Voluntary Crypto Economics can help get needed things built, which is funny thing to do, because TPI rakes $Millions Fiat per year for decades into its centralized coffers and still has only a weak 20+ year old network to show for it, but in under one year this competing project is pathing many both potential, and now operational, ways forward. Speaking of money... Remember the time TPI accepted $2M in ETH from a donor after fraudulently claiming that the v2 onion key NFT that TPI was selling was the first publicly known hidden service operating on the network and was thus a prized auction item... that was a lie, it was not the first. Speaking of censorship... Remember the time when TPI spoke of tor-talk as a list where people could speak freely and critique tor... that was a lie, TPI censored dozens of people and messages critiqueing tor and Tor, and admitted to bricking up their lists, and then permanently shutdown the list. Speaking of diversity... Remember when you could Speak Freely in your node's Contact Field and on Social Media and be welcome at tor conventions because everyone of all kinds was there simply for tor... not anymore. Tor Project censorbans nodes and operators whose opinions they don't like off of the network and out of the project, talented coders contributors analysts etc... for exposing inconvenient truths, and for refusing to be conformed to their non-diversity of virtue-signalling thought police. And now for utilizing the opensource tor protocol. Anyway... after 10+ years of the Truth About TPI and tor getting out, the Tor Project Incorporated is now being routed around at all levels, new projects have found their voice and no longer defer to TPI. TPI's attempts to market and retain its funding stream are being questioned by donors regarding the issues within TPI and tor. While tor is good at what it can do, and stinks at what it can't, the Tor Project itself is no longer the only game in town for what the future of comms networks will look like. And the forks of tor and competing networks are now being formed and rolled out. The future has potential again. Some design elements of the tor software protocol will live on into the Next Generation of Overlay Networks, and in the new Global Distributed P2P-owned Fibre/RF Nets that are being built out. And the Tor Project Inc, which has ever since been trending more like a closed-source Corporation, has been marked as deprecated by many. Speaking of the time when Individual, Corp, or Govt whitepapers and attackers were thwarted against Traffic Analysis and Sybil of the Tor Network... "Tor Stinks -- NSA, vulns known since before 2012" You can now build a better Overlay Network than Tor, and a better P2P Private Electronic Cash System than Bitcoin.

At one of the PET workshops {these discussed much of the academic background to the technology behind TOR, Mixminion etc} someone presented a paper on how long a user would wait for a reply to a web request. Up jumps an attendee who says he and some colleagues had already done a paper on this, and the answer was 5 seconds. Ooops.

Now for a 5 second maximum response time it is technologically infeasable to implement an untrusted onion network which resists attack by a global persistent threat like the NSA or GCHQ.The APT just temporally correlates data exiting the endpoints.

The network can introduce timing jitter and packet size standardisation or variation in order to make this harder, but with cost-limited dummy traffic and a maximum 5 seconds response time it can't reliably stop it.

It cain't be done.

This is such an old discussion that I am also not up to date on, but I don't see why snail mail and constant bandwidth were not effective counterarguments to user expectations and timing correlation.

As to constant bandwidth/covertraffic, that is expensive even today. For constant bandwidth to get a 5 second response time for a smallish say 3MB web page you need to have 3 MB of covertraffic every 5 seconds, or 50GB per day, per link. Ouch.

I thought about this a little bit, and the concern doesn't add up to me. As a consumer and participant in small businesses, I've only ever seen bandwidth that is metered per availability, not per use. The price is the same whether I use it or not. The amount of bandwidth available to a set of people who stream videos with or without filling the downtime with cover traffic is exactly the same. A low-end consumer link that provides 1MB/s bandwidth does indeed provide 84GB of transfer every day. The idea of constant bandwidth could of course be extended to manage changing bandwidth conditions without providing for timing correlation, so long as the use of the bandwidth is unrelated to the actual requests, it could have any arbitrary shape to fit within availability.

On 06/06/2023 07:41, Undescribed Horrific Abuse, One Victim & Survivor of Many wrote:

...

As to constant bandwidth/covertraffic, that is expensive even today. For constant bandwidth to get a 5 second response time for a smallish say 3MB web page you need to have 3 MB of covertraffic every 5 seconds, or 50GB per day, per link. Ouch.

I thought about this a little bit, and the concern doesn't add up to me.

As a consumer and participant in small businesses, I've only ever seen bandwidth that is metered per availability, not per use. The price is the same whether I use it or not.

Up to a point, yes. In most cases that point is 25GB/month, after which your traffic gets throttled. Unmetered lower bandwidth contracts also exist, but don't help enough. However, you miss my point - the requirement is 50GB per day, *per link*. Imagine you are a TOR entry node. If you are serving 1,000 people - which is not a whole lot - you need to serve 50 TB of dummy traffic per day. For free. Big ouch. Plus you need links to intermediate nodes - to do this properly you need a link to every possible intermediate node, which should be in the tens of thousands or more. 550 TB per day. So not happening. As for low latency highly anonymous traffic, well we had remailers, which worked up to a point, and which were getting better - until TOR came along and took up all the science and coolness and innocent cover traffic and the cypherpunks who actually wrote code; and remailer development basically stopped. Peter Fairbrother

...

Up to a point, yes. In most cases that point is 25GB/month, after which your traffic gets throttled. Unmetered lower bandwidth contracts also exist, but don't help enough.

However, you miss my point - the requirement is 50GB per day, *per link*.

Imagine you are a TOR entry node. If you are serving 1,000 people - which is not a whole lot - you need to serve 50 TB of dummy traffic per day.

This is only true if these people are all using the network at precisely the same time and are all given 1MB/s at that same time. The maximum total bandwidth needed at any given moment is the same with or without cover traffic: it is the sum of the most bandwidth needed by people simultaneously. At this maximal moment, no cover traffic is needed: the users are each others’ cover traffic.

At other moments you need to provide enough cover traffic such that that moment is indistinguishable from any other. But it’s still maximally that same amount of bandwidth with or without cover traffic. I proposed making all moments be that maximal moment, because the network transceiver is powered and capable anyway.

When i responded to this, I didn’t understand that Peter was referring to the “last mile” of connection to each user, where users are distinguishable by their different source ips, with each user engaging constant bandwidth to hide themselves. To provide for constant bandwidth in this area the network would need to have users split their transfers among multiple entry nodes, such that each one has less bandwidth connected total, or otherwise anonymize its users. If each user connected to 10 entry nodes, for example, then each entry node would only have to hold 1/10th the maximum bandwidth per user to have constant bandwidth with them. In comparison, P2P apps might have 100 or 1000 connections. Noting also that tor used to place users as first class routers, although whenever I left this running bad things would happen to my machine while I was away. And that constant bandwidth is the extreme ideal situation that could be compromised with other distributions in areas where existing network architecture (identifiable user connections) make the system more challenging.