The Tor Project is switching to Rust

Hmmmm.

My biggest gripe with the Tor project is that it is so slow.

I don't think merely moving to Rust makes Tor faster either. And I am also not entirely convinced that Rust is really better than C.

There’s a fundamental trade-off between performance and privacy for onion routing. Much of the slowness you’re experiencing is likely network latency, and no software optimization will improve that.

I believe that the slowness is a matter of the amount nodes in the tor network, not something that can be fixed solely by code changes.

No one is claiming the new version is faster, only that it is safer.

I had that problem too, very slow on network requests, just change the setting "num_relays_proxied" from 3 to 1 to make it blazingly fast.

If this is sarcastic you should probably add /s or someone might actually follow your "advice".

You should preface this with some important information about what that does.

There are some trade-offs!

Changing that setting to 1 gives you weaker anonymity guarantees. Using multiple guards spreads your traffic across different IP addresses, making it harder for an adversary who controls a subset of the network to correlate your activity.

Reducing to a single guard concentrates all traffic through one point, increasing the chance that a hostile relay could observe a larger fraction of your streams...

Then the single relay knows both who you are (your IP) and where you are going. This offers no anonymity against the relay itself.

3 relays is the goldilocks number for speed vs privacy. Using less is not a tradeoff the usual user of Tor should make.

How is 3 so much better than 2, but 4 not so much better than 3?

1 = no privacy from relay

2 = risk of collusion between relays

3 = goldilocks default

4 = ... actually, you have more attack surface and you are more susceptible to fingerprinting because everybody else is using 3, so you're timings etc help identify you

So the default is 3 and nobody ought change it! Use 3 like everybody else.

The exception is .onion sites. TOR actually deliberately defaults to 6 hops when accessing .oninon sites - 3 to protect you and 3 to project the site.

Knowing not so much about Tor but some about math: the number of nodes you need to compromise in order to de-anonymize a Tor user is exponential in the number of hops. Google says there are roughly 7000 Tor nodes, including 2000 guards (entry) and 1000 exit nodes. If you have a single hop, there's roughly a 1/1000 chance that you will connect to a single malicious node that can de-anonymize you, going up linearly with the number of nodes an attacker controls. If you have 3 hops, you have a 1 in 1000 * 7000 * 2000 = roughly 14 billion chance. 2 hops would give you 1 in 2 million, 4 hops would give you 1 in 1000 * 7000 * 7000 * 2000 = 98 trillion. In practical terms 1:14B is about the same as 1:98T (i.e. both are effectively zero), but 1:2M is a lot higher.

That reminds me of the holy Handgranate of the Monty pythons

completely agree but it could be added that a new language can sometimes help explore new ideas faster, in which case maybe the routing layer and protocol can see new optimizations

What's the point of having one relay? You're better off using a reputable VPN like mullvad or ivpn. Tor is the best you're gonna get for low latency anonymous overlay network. It's been studied and refined over the years.

It’s important to remember that safety is the whole purpose of the thing. If Tor is slow, it’s annoying. If Tor is compromised, people get imprisoned or killed.

There are currently ~9000 relays if you look at https://metrics.torproject.org/networksize.html. The current problem is the fact that majority of relays are in Germany and if you rotate your circuits enough, you'll also notice the same path. German govt has been very hostile towards Tor for a long time, they were also behind KAX17. We need more relays obviously but also in different regions.

There's no exit nodes for onions because there's nothing to exit to. Nothing beats anonymity of onions and it's design is well created.

With 3 proxies traffic circles around the planet 2 times, which takes light 1/4 second to travel. Response does it again, so 1/2 second in total. Light is slow.

You meant Tor network, right? Sadly, making very fast anonymous overlay networks is extremely difficult. You either make it fast or don't sacrifice anonymity. I personally noticed that Tor network has significantly improved and is way faster since a few years. It's also not recommended to exit and if you religiously stay over onions, you increase your anonymity.

because then there is at least one node that knows neither the source nor the destination of a request

The law of diminishing returns

I think this shows a misunderstanding of the purpose of TOR. It’s for privacy, not optimal latency for your video stream.

Hey, if you want a fast anonymity netowrk, there are commercial providers. Companies doing research on thier competition use these to hide thier true idents from targets. They are not cheap (not free but cheaper than AWS imho) but have much greater functionality than tor.

https://voodootomato.medium.com/managed-attribution-the-key-...

https://www.authentic8.com/blog/non-attribution-misattributi...

It would shifts part of the data route info from your provider toward that particular relay.

But I wouldn't recommend it of course.

Nature just hasn't switched to Rust (and Arch) yet. Maybe it'll also get rid of those pesky black holes.

> My biggest gripe with the Tor project is that it is so slow.

It’s not supposed to be a primary browsing outlet nor a replacement for a VPN. It’s for specific use cases that need high protection. The tradeoff between speed and privacy for someone whistleblowing to a journalist, as an example, is completely reasonable.

Having too much bandwidth available to each participant would incentivize too much abuse. In my past experience, a Tor associated IP was already highly correlated with abuse (users trying to evade bans, create alternate accounts to break rules, and then of course the actual attacks on security).

> And I am also not entirely convinced that Rust is really better than C.

Well it's certainly not worse than c, and it's hard to argue it's as bad, so...

> I don't think merely moving to Rust makes Tor faster either.

It would be crazy to think switching languages would make a network protocol faster without some evidence of this.

>It’s not supposed to be a primary browsing outlet nor a replacement for a VPN.

Tor wants people to use the network for primary browsing because it helps mask the people that need the protection. The more people using the network, the better for everyone's anonymity.

They even have a whole "Outreach" section at https://community.torproject.org/outreach/

Of course it would hence you should stick with mullvad, a reputable VPN. Tor is not made for single relay paths, you're just wasting it's potential.

This is a joke, for those who didn’t notice.

Tor is slow because traffic is routed through multiple layers. The design priority is anonymity, not speed.

Or people should not be idiots and think for themselves just a smidge, and not use /s.

Plus TLS handshakes.

5 proxies does it even slower but would make attacks much more difficult.

>Hey, if you want a fast anonymity netowrk, there are commercial providers.

For most people seeking anonymity via Tor network (whistleblowers, journalists, activists, etc.), paying a company who can then subsequently be compelled to hand over your information is a bad choice.

And in most other scenarios, Authentic8 is probably still a bad choice. If you require a FedRAMP-authorized service, then sure, look at Authentic8.

The right number for you to use is the default. But the right default is not necessarily 3.

It's very difficult for me to contemplate how anybody could run a VPN, however reputable, that isn't compromised by one intelligence agency at least. Their incentive structures and their costs to participate in this space just make it a no-brainer.

If you're starting a brand new VPN company with ironclad ideals about privacy - are you going to be able to compete with state-run enterprises that can subsidize their own competing "businesses", on top of whatever coercive authority they possess to intervene in local small businesses?

And significantly faster to access onion websites than go through exit nodes, which are probably saturated most of the time.

Reddit over their onion website is very snappy, and compared to accessing reddit over VPN it shows fewer issues with loading images/videos and less likely to be blocked off.

It would be nice if more websites were available as onion addresses (and I2P as well).

edit: also if the Tor browser (desktop and mobile) would ship with ublock origin bundled, that would further improve the experience (Brave browser Tor window compared to the Tor browser is a night and day difference)

I agree it probably won't make it faster. But there is absolutely no comparison when it comes to safety/stability. I've written a ton of C code, and it's just not even close. Rust really outshines C and C++ in this regard, and by a very large margin too.

They should be fine since I made up the setting name, and even though I am not familiar with Tor client's configuration, I don't believe this is possible without altering its source code.

Also, using this kind of software without understanding how its works even just a little doesn't protect much of your privacy.

Yeah I was confused! Pretty sure this is not configurable.

The setting doesn’t exist.

How much C++ have you written? Not C, but C++.

Do you like pattern matching in Rust? It is one of the features that Rust does decently well at.

> Well it's certainly not worse than c, and it's hard to argue it's as bad, so...

Except in regards to having a proper standard (the standard from Ferrocene has significant issues), and to the size of the language and how easy it is to implement a compiler for.

There are a lot of differences and trade-offs.

This is not correct. Tor is generally not bottlenecked by the quantity of available nodes, the usual bottleneck is the quality of nodes picked by your client rather than the quantity of nodes available.

Of course, technically, this problem is related to the quantity of high quality nodes :)

The modern TLS 1.3 handshake is exactly the same as your connection setup. If we ignore the fact that (Because Middleboxes) you have to pretend you're talking TLS 1.2 it goes like this:

Client: "Hi, some.web.site.example please, I want to talk HTTP and I assume you know how AES works and I've randomly picked these numbers to agree the AES key"

Server: "Hi, I do know AES and I've picked these other numbers so now we're good."

Included in the very same packet as that response from the server is the (now AES encrypted) first things the TLS server wants to say e.g. to prove who it is, and agree that it knows HTTP as well.

0RT is a (very dangerous, do not use unless you understand exactly what you're doing) extension for some niche applications where we can safely skip even this roundtrip, also included in TLS 1.3

Your config improvement made it into Google AI https://i.imgur.com/v5DsXy9.png

What do you mean by "exactly the same as your connection setup."? Are you talking about TCP?

This TLS handshake can only happen after the TCP handshake, right? So 1 rtt for TCP, + 1 rtt for TLS. 2 rtt total. (2.5 rtt for the server to start receiving actual data. 3 rtt for the client to receive the actual response.)

This would be a fantastic argument against rust for the m68k or some other embedded architecture. But we live in a world with an actual rust compiler for basically all architectures tor serves. & obviously the c standard can't save c from itself.

Today, Tor doesn't move QUIC so you'd have to do TCP, but that's not actually a design requirement of Tor, a future Tor could actually deliver QUIC instead. QUIC is encrypted with TLS 1.3 so your first packet as the client is that Hello packet, there's no TCP layer.

QUIC really wants to do discovery to figure out a better way to move the data and of course Tor doesn't want discovery that's the whole point, so these features are in tension, but that's not hard to resolve in Tor's favour from what I can see.

> Yet you are wrong

Ahh here you are speaking nonsense again. We ain't talking formal logic, we're speaking human to human

> For instance, building a large project in a language with only one major compiler, can introduce risk.

Ok let's introduce an alternative to gcc then

> But Steve Klabnik will lie about that

You seem fine to both tarnish the reputation of, erm, c defenders with your own actions and to slander the reputation of Klabnik (or "lie" as I'm sure you'd term it), who both speaks more coherently and with his own name. Why do this in the name of open source if you have nothing to contribute, knowing that you're setting your own project back?

I literally said on here two days ago that I thought that in the past the Project was hostile to gccrs: https://news.ycombinator.com/item?id=46219460

I have been a fan of gccrs the entire time.

Onions are extremely fast and for the level of anonymity they provide, it's an amazing advancement. It's surprising that Reddit has kept their onion in working condition given their poor attempts (a very bad TLS fingerprinting for all redlib instances) recently to shutdown redlib instances.

Tails ships Tor browser with ublock but the Tor browser team doesn't want to for simple reason: fingerprinting. I use ublock too but I feel like majority still don't and disabling javascript alltogether is still the most secure way.

Yes, but let's not forget it's voluntary based. There are lots of high quality nodes, although less which are basically burning money and getting nothing in return. We all believe in a censorship-resistant and free web but only few are willing to take action. My two small guard/middle relays are rented at 10$/m each and is only 100Mbit/s non-metered up/down because it gets expensive.

> Tor browser team doesn't want to for simple reason: fingerprinting.

I don't understand this given reason. If they package in uBlock origin across their desktop and android browser. Then everybody will have uBlock origin so the same fingerprint. If the reasons are different subscriptions lists that users might enable/disable, sure that's fingerprintable, just make a disclaimer about that if users want to modify the default lists.

As much as I agree with it, they see it as another maintenance headache and unnecessary attack surface. NoScript is the only extension which they've been shipping since quite a while.

I've written C++ for 15 years. It's the language I have the most experience with. And yes, pattern matching is a must, particularly for any language that has sum types.