Hacker News Reader

Comment by Nrsolis | Hacker News Reader

I won't go into detail here, but consider how de-anonymization of TOR network users is done with multiple layers of onion routing and encryption. All that needs to happen is that you correlate the injection of traffic to a particular node and then watch the actual traffic from a cable modem. You don't need to see the decrypted packets, you just need to know that when I inject N packets into a particular node, I get N packets out. Synchronized over a sufficiently long time series in a pattern that's only known to the attacker and you'll get a statistical certainty that a particular cable modem is being used for this kind of application and presto, your household is banned from the service.

Like I said, trivial.

View on HN

Of course there's a solution to that too:

For the VPN, choose a fixed packet size, and maximum bandwidth in packets per second (evenly spaced "ticks"). Every tick, if there is a packet waiting to transmit, send it with padding to the max size. Otherwise, send a dummy packet that is discarded by the remote.

That's right telcos - we can reinvent circuit switching too!

Is this just your idea? Or is it an actual working solution?

Because people have known about padding for a while and yet we still have methods to de-anonymize TOR networks. When you use those techniques on a minor mesh network like this, it's an order of magnitude easier.

Keep in mind that the cable company or broadband provider doesn't have to have much in the way of proof, just a suspicion and your connection will be terminated.

It's a very simplistic idea I threw out there, and it should stand on its own - if the only thing the intermediate network ever sees is uniformly distributed packets at uniformly distributed times regardless of contents, there's simply no signal for correlation attacks. But it's clearly inefficient as fuck.

> broadband provider doesn't have to have much in the way of proof

This pretty much goes for any software that doesn't just visit Facialbook et al. Barring any sort of public utility regulation, the only way to push back against that is to get software widely deployed.

That means you have to pay for peak bandwidth 100% of the time.

I wouldn't exactly call that trivial if it needs to be "synchronized over a sufficiently long time series."

Reply on news.ycombinator.com