Whither Tor? Building the Next Generation of Anonymity Tools (arstechnica.com)

"Tor hasn't changed, it's the world that's changed," says Aaron Johnson, the lead researcher on a 2013 paper which reported that 80% of Tor users could be de-anonymized within six months, and that today's users may want protection from different threats. An anonymous Slashdot reader quotes Ars Technica: The most probable future we face is a world in which Tor continues to offer a good-but-not-perfect, general-purpose anonymity system, while new anonymity networks arrive offering stronger anonymity optimised for particular use-cases, like anonymous messaging, anonymous filesharing, anonymous microblogging, and anonymous voice-over-IP. Nor is the Tor Project standing still. Tor today is very different from the first public release more than a decade ago, [Tor project cofounder Nick] Mathewson is quick to point out. That evolution will continue.

"It's been my sense for ages that the Tor we use in five years will look very different from the Tor we use today," he says. "Whether that's still called Tor or not is largely a question of who builds and deploys it first. We are not stepping back from innovation. I want better solutions than we have today that are easier to use and protect people's privacy."
The article lists five projects that are "breaking new ground in developing stronger anonymity systems," including the Dissent Project, the Aqua and Herd projects (for filesharing and voice over IP), Vuvuzela/Alpenhorn (for anonymous chat), Riffle (filesharing), and Riposte (anonymous microblogging). Tor project cofounder Nick Mathewson is urging anonymity developers to begin using their own software. "What you learn about software from running it is like what you learn from food by tasting it... You can't actually know whether you've made a working solution for humans unless you give it to humans, including yourself."

Comments

Tor and VPN weakness is packet size.

[adolf]

Maybe for TOR, and certainly for VPN (as-implemented), is a specific vulnerability for packet sizes.

If 208.230.30.20 sends packets of 9098, 3039, and 3030 bytes, and I receive similar packets of the same size (plus or minus VPN headers), then I am already identifiable.

Is this different for Tor?

Re:Tor and VPN weakness is packet size.

[dns_server]

Tor works by setting up multiple layers of vpn's between nodes in laters in a way that traffic is passed between nodes without them knowing the contents.
You want to connect to c so you set up a vpn between a and b then b and c and use both of those vpn to set up another vpn between a and c.

That is the a kind of traffic analysis that can be done if you are a government and can monitor enough nodes.
While any one node may not know what is being transmitted and to where you could see that a series of packets came through in to one node and a few seconds later a similar amount of data was transmitter do another node.
If you are unlucky one of these bad nodes could also be an entrance or exit node and they would see what you are sending.

There has also been research that showed that if you monitor a voip call transmitted through a vpn you can guess what they are saying by the traffic spikes as words are spoken.

Re:Security cleared

[MartinG]

> RFC6520-- WHY THE FUCK DOES THIS EXIST? Because it's too computationally expensive for clients to re-establish SSL sessions...?! Really? My dual core 2.15ghz smart phone begs to differ.

No. It's not about CPU time, but about the time taken to establish a connection due to the TLS and TCP handshakes. I think it's only a single round trip for the TLS part (someone will surely correct me if not) but that's on top of the TCP 3 way handshake, which all adds up. You can't mitigate network latency with a faster CPU.

These are partly the same reasons for http2 by the way. Re-using a single connection means avoiding the TCP and TLS setup happening more than once.

Finally, keeping a connection open for a long time and re-using it goes some small way to avoid revealing as much metadata to snoopers, as does multiplexing a single TLS connection rather than creating many.

Re:TOR's already looking different, Nick.

[cryptizard]

What a bunch of baseless FUD. The new board was picked precisely because they are beyond reproach. If you think Bruce Schneier and Matt Blaze are government stooges then you might as well just give up trying because no researcher can be trusted.

Hiding Tor

[grumbel5969]

Focus an anonymity is all nice and good, but from my experience the biggest problem with Tor is that the exit nodes are so limited that the fact that you are using Tor is obvious for the server. Meaning websites will block you or become unusable due to requesting a CAPTCHA every few clicks. Thus you have anonymity, but your web access is so drastically limited that it becomes impractical to use Tor as every day Internet access, thus you switch back to a non-Tor browser and are left with no anonymity.

HORNET, next gen Tor @ 93Gb/s

[saibot834]

It's worth looking at HORNET, which is at this point not much more than a research paper, but it could point in the right direction. Instead of having anonymity for very few people (because of disadvantages to using anonymity tools, e.g. speed and latency), increase the anonymity pool by making anonymous communication less disadvantagous. With HORNET high throughput is achieved by providing Tor-like routing at the network layer (something which is currently not possible in the internet, but it might come with SCION, a BGP replacement that's in the works). I'm not saying that this will be ready anytime soon, but I think it's certainly an interesting idea. [full disclosure: I'm a researcher working on SCION]

I also think that Tor still is the best thing we have. The rumors about Tor's death are greatly exaggerated.

Re:HORNET, next gen Tor @ 93Gb/s

[ewanm89]

The problem with Tor is not throughput but latency, and the latency issue in Tor exists as a protection against timing attacks. Basically, Tor nodes capture several requests to pass on, then wait, only sending in batches on a given interval, they also shuffle the order of the batches, 3 hops later and all these waits add up. Without this method, one could easily watch packets going into and coming out of the network and just match them up, as they come out in the same order a few milliseconds later, with the batching you have no idea which packet matches with which one going in.