Building a completely p2p (no servers) e2ee messaging app is not hard except one big problem: contacts discovery. I looked through briar website and it seems the solution is to constantly ping all contacts and hope that everyone is online plus at least one of IPs stays the same between pings. Did I miss something more interesting?
Tor hosts a directory service, a (de)centralized repository of rendezvous nodes from which the Onion Service (server) can be reached, thus the IP address is not lost, but since the circuit is rebuilt every 10 minutes or so, the connection will probably get cut every now and then.
I'm not sure if this really works, but if it's a short message and you periodically check the server if there's a reply and the service responds with short reply, the Tor cell padding (to 500 bytes IIRC) would make it harder to observe metadata about when communication takes place. This all of course goes out the window if it's a large packet that requires multiple cells, or if it's the client that just POSTs the outgoing messages to the server over an established connection.
Thanks, this is basically combination of somewhat central servers plus nearly always online model. I need to think about it - on the first glance I am not 100% sure the role Tor plays in this model.
Is this described somewhere in more details? As I said, I clicked around but didn’t see any docs about this.
The role of Tor is it facilitates anonymous, end-to-end encrypted connection between client and server, each messaging app is both a client (or a set of clients) and a server (a Tor Onion Service) that talk to each other through the Tor network. This way the traffic never exists the Tor network*.
The laptop/phone is the client, and Secure Drop is the server. With Briar the client-side Tor socket connects to the messaging app instead of browser, and on server side the socket again connects to the messaging app instead of web server. Whether messages flow from client to server (via POST request) or server to client (GET request) is doesn't really matter. The architecture where each user runs both server and client makes it effectively peer-to-peer.
Because messaging apps are these days expected to be always online, you pretty much need to have the server and client (and thus the app) always running.
---
*This is in contrast to Tor Messenger that, while it defaulted to Tor, used exit nodes unless the XMPP server was also a Tor Onion Service. While with Tor Messenger you were anonymous, XMPP server was usually not self-hosted thus a third party might have aggregated some metadata about when conversations between two accounts took place etc.
Things used to be even worse before Tor Messenger. With Pidgin it was possible to forget to configure Tor (unless you used XMPP Onion Service), and even worse, forget to enable OTR end-to-end encryption for every session, and if that happened the content could easily deanonymize you.
With Onion Service messaging, provided you verified the authenticity of the V3 onion address (or E2EE protocol's key fingerprint), you can be rest assured
1) connection is always E2EE
2) always inside Tor with no possibility to F up by connecting over 'clearnet'
3) no third party has access to communications metadata
Separate topic so replying in a separate sub thread
The clients are not always on, iOS and Android don’t like background processes, connections go down, battery runs out, etc. I understand how to build always on clients but it’s not a practical solution.
The directory service only receives an anonymous notification behind Tor proxyt chain that "hey, if someone asks for this .onion URL, point them to this node as it can provide further directions". It doesn't know "everything". The point of Tor has been from the beginning to compartmentalize what each node knows the the bare minimum.
It's not hard for IRC-style chats, but it gets harder if you want to handle:
* Asynchronous messaging: what if the two devices are not online at the same time, or on disjointed networks? Store the message on a server somewhere? Secure Scuttlebutt[1] relies on devices pulling encrypted data that does not belong to them.
* NAT or firewall hole-punching, though it can be remediated by leveraging other nodes. Some implementations use a DHT[2], but you're often relying on other servers of some sort.
* What you call contact discovery is also typically handled through a DHT of some kind. Yggdrasil-like (or hyperboria, cjdns, .onion) overlay networks are usually able to route to a public key, regardless of how it moves around on the network.
* Push notifications. Either you accept the use of an external server (like the Tox client TRIfA, which has an add-on[3] that also supports UnifiedPush), or you have to rely on a separate persistent connection that will drain your battery faster, especially if there's some computation involved.
The last point is why I uninstalled Briar: I had almost no contacts, and didn't want an extra battery-draining service.
If contacts discovery is somehow solved, then I can see potential options of using short range comms (eg bluetooth) for connectivity. Basically all ideas I have are:
1) somewhat central server(s)
2) always on plus constant updates (what briar seems to be doing)
3) every node knows large part of topology (not very scalable)
I am wondering if I am missing something in briar’s architecture
