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.
The app hosts a Tor hidden service which other peers can connect to. No NAT punch through required as Tor will relay messages instead of a direct P2P connection.
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.
Ricochet sits over Tor and doesn't require much or any in the way of education. The implementation details and use of Tor is virtually invisible to the end-user. It's nothing like using public key encryption to send an email for instance, and more akin to AOL Instant Messenger from a user perspective.
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.
Every user is their own Tor onion service, so you get E2E encryption and no centralized servers. The whole thing hinges on the security of Tor itself which is probably a safe enough bet.
XMPP is better than anything else I have seen for this sort of thing in that it is federated and gives you a choice of servers. There is no single point of failure.
Here is what that looks like using Conversations on Android:
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.
I’m amazed the tor browser itself even allows any http connections, ever. Seems like a terrible idea 100% of the time to allow them at all when the whole thing relies on passing your data through an untrusted party.
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).
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.
Apparently Tor hidden services works well for this- there's a mode where the hidden service authenticates clients, so you even get some security for free.
Cool project. It shows the power of Tor hidden services here: you can have peer to peer communication regardless of either side's network topology. It just needs to connect to the Tor network and you're good to go. (And yes, Tor can connect through "fascist" firewalls, as the configuration itself puts it[1].)
If you think about it, it's dead simple to make: run the tor binaries, run a netcat binary that listens on a certain port, and configure tor (two lines of config) to run a hidden service connecting to that netcat port. Then read the generated hostname file for the .onion address and display it to the user. Reverse thing on the other side.
I don't mean to say that OnionShare is not useful, OnionShare to the above script is what Firefox is to Lynx (to take an example). I just mean to say that it's interesting how easily this can be done with just five commands.
- NAT hole-punching for free
- end-to-end encrypted for free
- peers identified by a hash of their public key, so no CA or similar required
- no metadata leakage
It seems like the perfect solution, but hardly anyone does it.
https://ricochet.im/ is a chat program that works this way, but the client is pretty minimal.
reply