I've pondered p2p apps that are secure from traffic analysis, sniffing, and leaking metadata. Chat being the easiest. Chat is low bandwidth and tolerates latencies well, much more so than audio or video streaming.
Tor has a much harder job, it's trying to handle full TCP communications, low latency, variable packet sizes, efficiency (no fake traffic), and high bandwidth all compound to make it very challenging.
However you can make the challenge much simpler. First nix TCP, variable packet sizes, and low latency. Pick a packet size like 256 bytes, send packets every 300 ms, and use any spare traffic to maintain the health of a DHT.
Then clients would use the same onion approach, decide the number of hops, and encrypt for those hops like an onion.
So each node would receive messages, decrypt it, if it's a DHT update handle that, if they are the intended recipient decrypt, if it's a forward request decrypt it and queue it for sending on the next free 300ms boundary.
Suddenly it's much harder to track traffic through the network, even with perfect knowledge of each packet's source and destination. Timing attacks don't work because everyone sends 256 bytes ever 300ms. Using packet size to watch traffic go through relays doesn't work.
So much less useful than Tor, but also more resistant to traffic analysis, and plenty of bandwidth for chat.
I've been using another chat app that uses tor (briar) to chat with my family and the chatting app has been working flawlessly for us so far.
Tor curcomvents the nonsensical restrictions that isps place on users and makes it very easy to build p2p applications. No need for stuff like nat stun turn. Just exchange public keys and go!
If anything, I find it weird that other p2p chat apps don't use tor given how easy and reliable it makes the chatting UX.
Please, do not run this on Tor. The p2p aspect will definitely help, as it will be harder to locate a single server with traffic analysis, but it isn't enough. Run this on bitmessage (or a fork thereof) which broadcast messages to all peers, making traffic analysis futile for an attacker.
True. But Tor is the large anonymity network that we have. I2P is cool, but it's too small. For high latency, perhaps Mixmaster remailers via alt.anonymous.messages is still workable. Last I checked, there was a Tor onion news server.
I agree about unworkability for real-time communication. But there, you want to keep messages small. And use padding. Trying to make live streaming anonymous is nontrivial.
The problem here is that tor is largely focused on realtime communications, and stuffing packets through e.g. facebook chat would probably be too slow. It would work great for another anonymity network that was more message-focused with no realtime needs.
Essentially, the idea is that someone buys a VPS hosted on a cloud service with common ingress IPs (such as Google App Engine, Microsoft Azure, etc). Tor clients then connect to it, sending an innocent-looking domain (gmail.com or something) in the TLS SNI header, and then only in the datastream protected by TLS do they expose the tor protocol.
This is of course useless against NSA and GCHQ, which have access to all these cloud providers, but it's very useful for example for people behind restrictive country-level firewalls as the authorities are reluctant to block such large services and it's hard for them to distinguish this from normal traffic.
Skype wouldn't work, but all you need is a 12kps stream. The problem with tor is sometimes the nodes are very slow, you could probably pick a path that showed to be faster but as far as I know it's non trivial.
Cool project. I'm curious why you don't use Tor to provide peer-to-peer connectivity? It gives you NAT hole-punching and encryption for free. It seems the obvious choice.
I believe Tor is underrated in P2P systems. Many networks consider NAT traversal mostly (or partially) unsolved. Routing between nodes over Tor immediately solves your NAT traversal problems allowing any device to tunnel to any device (at the expense of latency).
Cool, I'll check it out. I was thinking more along the lines of hiding messages in the Tor protocol itself, rather than hiding Tor traffic (which is desperately needed.)
Tor is a big problem. It gives you anonymity, but, it still requires someone to forward your traffic, or multiple forward hops. You really need a proxy dedicated server like what The Pirate Bay has (you pay for it) which does not keep logs. Otherwise everything is incredibly slow. And I mean 56k speeds slow or worse.
Slightly disagree, Tor hidden services are fantastic to implement decentral signal/rendevous services with no single point of failure. I'm using this in my app https://cryonet.io
Love the fact that it works in many places where plain UDP solutions fail.
Once two nodes are connected via a Tor hidden service, other p2p channels can be established and are more appropriate to transfere large files.
There is also I2P which is just like Tor but unlike it is designed to withstand the traffic from bittorrent clients (useful for people living in dorms on in America) and can also tunnel UDP (unlike Tor which can only tunnel TCP).
That being said, I really like the new onion-v3 protocol that Tor added as it moves from the outdated 1024-bit rsa + sha1 addresses with 1024-bit DH and AES-128 to the state-of-the-art ed25519 for addresses and handshake as well as chacha20-poly1305 for encryption.
I have toyed with DHTs successfully over Tor and it works work fine, but that's just peer discovery. If large data transfer doesn't go over Tor, you're still exposing your IP. If large data transfer does go over Tor you're potentially harming the network (even if it's just to onion service) by over using relays (and Tor actively discouraged BT use over the network). There are alternatives like Tribbler, but none popular enough.
Also onion service v3 addresses, which are entire ed25519 public keys, won't fit in an ipv6 address (haven't checked base 32/36/whatever for v2 onion addresses, but surely also won't fit in, say, a /64).
You should look up i2psnark in particular, that was the first big one I'm aware of, but there are plenty of others too.
Tor has a large critical mass - which makes it safer in general, through pure volume - but I2P is more suited to this for a bunch of technical reasons I'm not going to go into in detail right now, but they involve garlic routing vs onion routing, end-to-end correlation, single-ended vs double-ended tunnels/circuits... basically, Tor hidden services are okay, but I2P is actually designed for more generalised use like this.
Tor has a much harder job, it's trying to handle full TCP communications, low latency, variable packet sizes, efficiency (no fake traffic), and high bandwidth all compound to make it very challenging.
However you can make the challenge much simpler. First nix TCP, variable packet sizes, and low latency. Pick a packet size like 256 bytes, send packets every 300 ms, and use any spare traffic to maintain the health of a DHT.
Then clients would use the same onion approach, decide the number of hops, and encrypt for those hops like an onion.
So each node would receive messages, decrypt it, if it's a DHT update handle that, if they are the intended recipient decrypt, if it's a forward request decrypt it and queue it for sending on the next free 300ms boundary.
Suddenly it's much harder to track traffic through the network, even with perfect knowledge of each packet's source and destination. Timing attacks don't work because everyone sends 256 bytes ever 300ms. Using packet size to watch traffic go through relays doesn't work.
So much less useful than Tor, but also more resistant to traffic analysis, and plenty of bandwidth for chat.
reply