Is there an alternative to TOR, which has some kind of immunity against time correlation? Like something that adds a random delay at each hop?
I think the world needs this and if it doesn't exist I might develop it (and I also have access to a few resources to get more people).
IIRC correctly I2P is resistent to time correlation because when your packet hits a node, the node waits for other packets, then sends them all at once. I could be wrong, though. I haven't used I2P in years.
I2P is different however. The main usecases of TOR I am interested in is evading censorship and anonymously leaking data. As I2P has it's own content, it does not solve 1 and it is not so good for 2 either as most whistleblowers want to deliver their data to a specific target, not just dump it on the deep web.
there are eep2tor gateways for acessing the clearnet. Assuming what I said about I2P is even correct, then this would add a layer of random timing to your tor usage.
Time correlation is not very effective for NSA, according to NSA themselves in documents leaked by Snowden.
- they can't control/monitor enough in/out nodes, or even keep track of them all
- the exit nodes keeps changing
- a lot of users' traffic can be leaving an exit node
- people use unlisted bridges sometimes
- they've had limited success in unmasking tor users with that approach
- they prefer simpler, less resource intensive methods
Just don't click their phishing email links, etc.
T.not secret agent
You are full of shit. You need to give a stasi approved email to receive listed bridges for tor i.e kikemail or yakike. That makes it laughably easy for them to correlate who goes to what bridge.
Now pretend they got that information with a burner email by some miracle in cy+1.
But you have had some success so you admit. Which means even if you used super l33t opsec and got a burner phone or computer on public wifi with no cameras. Mr not secret up there still has a chance of correlating your position and identity using timing correlation.
I wonder if using IPFS adds random to the timing of packets being sent out.
Im so fed up with the tor devs im about 2 seconds away from forking the whole goddamn project.
Ill gladly add a random time function to the relay switch and also make everyone a router by default and disable JS by default.
I'm liking this idea.
What I wonder is there any academic research about this? What is the problem with random delays? Just have 0 - 200 ms delay at each hop, so your roundtrip time increases by just up to 1.2 seconds or likely around 0.6 seconds. It is ok while browsing and the data rate is not affected, so even video streaming is fine.
It might get annoying while doing a phone call, but that can be solved by deciding the delays at the source and sending them in the onion. For phone calls use smaller delays, it is fine as long as most people have a bit higher ones.
If you do this, you destroy the correlation attacks and stuff like the 100k pages of research into guard node switching become irrelevant.
Tor is a protocol.
That doesn't matter in this regard, we can discuss about the whole ecosystem including the Tor browser and Tails.
The problem with making everyone a router is, that all the people being censored can't run routers efficiently. You need routers with large bandwidth, low ping and long uptime or it becomes a clusterfuck of not working stuff. There is not really anything wrong with people like CCC running the servers, TOR doesn't have a problem with too few servers. Actually you don't even want too many servers, as you rely on other traffic to hide your circuit. You want to have busy relays to interleave traffic.
Already in the new Tor stable build:
modprobe netem
It's obvious you have no idea what you're talking about. I doubt that you've ever even used Tor. Stop reading Skiddy Comix. Or lurk until you turn at least 14.
that meme died over 10 years ago
Give a link to the tor bridges website. You can't access information on bridges without using/enabling javascript or emailing them with a stasi approved email.
You can get bridges from the Tor bridges website without an email and without javascript. Are you retarded?
I don't think you know what IPFS is.
Would you look at that, another OP who didn't research something at all before complaining about it.
This is only padding, not randomized delays. It has some use, but fingerprinting services when you have the full traffic metadata will still work. Things like tempora can do this.
Sorry for not knowing about a feature that was released a week ago. Also not the feature I asked for. This is adding something small that should have been there for years.
Randomized delays go against Tor's relatively low latency design model. Just use Freenet and be done with it.
Freenet has some major issues. A single malicious node can find true originators of requests.
Yes I have read that. OP would do more trying to help the Freenet team fix this issue instead, rather than creating a Tor-like system just to add some latency. Freenet desperately needs more developers compared to Tor which has lots of brains and funding combined.
Although it has been around the block for a long time, freenet is a damn fine good idea (current issues asside.) Freenet is the technology that should be getting all the money and development possible but it suspiciously is not. It reminds me of operation orchestra (search youtube), the spooks can influence foss projects by simply controlling consensus to destabilize them or turn people away by smearing mud (such as cp.)
I wish i could contribute to freenet but i'm a brainlet.
Haha, pedos are retarded.
It is a shame. Freenet has been around a long time and I used it heavily for about 5 years before police started vanning people for just running the software (Missouri LEA). The sense I got was that it didn't get more attention because of what is a real or percieved difficulty in setting it up and using it. People just seem to think it's too hard to use as opposed to Tor which tends to be fairly "plug-and-play". The project also really never did a good job publisizing itself.
Really though at this point, I'm not optimistic about the future of anonymity networks in general. LEA/DeepState knows they are in a loosing arms race with technology, particularly encryption, and to beat us they need to essentialy pass laws that restrict those technologies they can't compromise, and punish those that use it; except themselves of course. They also know they can exploit the ignorance of juries and judges with techno-jargon and complex explanations to get thier way in a court room when there was zero legal basis for obtaining a search warrent or pressing charges to begin with. Just buy a gun a do what you have to do if they come.
Slanderous lies
That isn't padding in the sense of "padding that makes traffic confirmation not work," it's padding that makes dragnet log collection not work. The client sends out one cell every 1.5-9.5 seconds. This prevents your ISP's netflow logs from accurately separating your Tor traffic into individual connections, rendering dragnet traffic confirmation infeasible.
In case you're not aware how they work, netflow logs separate flows of TCP packets into "streams" corresponding to different connections by counting each set of TCP syn/syn-ack/ack packets to new IPs as different connections. This way, they can say "here are all the packets that the user sent to this destination" and "here are all the packets that the user sent to this other destination" even if you're sending them both at the same time. From Tor's perspective, this would allow law enforcement to perform after-the-face traffic confirmation attacks by subpoenaing your ISP for their netflow logs corresponding to your IP address, singling out your Tor related flows (because all non-bridge Tor nodes being publicly listed, non-bridge Tor traffic is easy to identify), and correlating the size of your outgoing Tor traffic for a particular flow in a particular time to the size of a suspect server's incoming traffic from one single flow at around the same time, deanonymizing you.
Tor nominally frustrates this, because all connections are multiplexed over one TCP connection to your entry node, and that connection to your entry node lasts for ten minutes. Because of this, any netflow logs should just separate your traffic into ten minute long flows that don't actually correspond to you actually connecting to individual websites, because the actual TCP syn/syn-ack/ack packets are encapsulated in Tor cells and encrypted, and they are all sent over the same TCP connection to the same IP address for the length of time that that particular circuit is being used (ten minutes). So, if you visit five websites during those ten minutes, your netflow logs would show that you sent all that traffic over one connection and one flow, and the traffic size from that flow would not correspond whatsoever to the traffic size to any particular one of the servers you had connected to. This would render netflow log analysis unusable from the perspective of performing traffic confirmation.
However, most netflow logging software considers a flow to be ended after 10 seconds of inactivity, and splits any new traffic into a separate flow even if this new traffic is going to the same IP address and no TCP syn/syn-ack/ack/rst packets have been sent. So unless you're visiting a new site every ten seconds, Tor's multiplexing of TCP connections over one circuit would not prevent the netflow logs from showing each individual connection to a new website, and it would therefore still be possible to use netflow logs to perform traffic confirmation.
Tor fixes this by sending a cell every 1.5-9.5 seconds, so there is never a ten second period of inactivity over a circuit even if you never actually use the circuit. As a result, netflow logs will just show one large ten minute connection instead of a bunch of individual connections corresponding to you connecting to different websites over Tor, as the logging software will see that Tor circuit as one long active connection. This makes the use of netflow logs for traffic confirmation infeasible, as the number of bytes sent over any one netflow flow will not correspond whatsoever to the number of bytes of traffic sent to any given server that you visit.
This does not prevent traffic confirmation if the NSA/FBI has specifically singled out your internet connection and is actively monitoring you. If they are doing that, they can just collect all of your traffic and perform traffic confirmation with the same level of difficulty as they had before this feature was added. 586 bytes of cover traffic every couple seconds is not enough to significantly hinder traffic confirmation, as the average website is two megabytes in size, and even with some of the content stripped out (javascript, flash, etc), the percentage of cover traffic to non cover traffic will still be far less than 1% -- inconsequential.
All this feature does is prevent the NSA/FBI from investigating a past event by calling up your ISP and getting the netflow logs they keep for all their users and using that to break Tor. It makes it infeasible to perform traffic confirmation after the fact. But it does not prevent someone who is actively monitoring your connection specifically from performing traffic confirmation.
what did he mean by this?
