OMS (Onion Messaging Server) Support about ricochet HOT 2 CLOSED

I'll begin by addressing the concept before we discuss specific implementations. In general, I don't see many compelling benefits in using message relays as a standard practice: it reintroduces many of the problems of server-based IM and shifts trust rather than eliminating it. Trying to solve those leads into building a higher latency anonymity network on top of Tor, and that's a place I wouldn't go.

1. A user's network might momentarily drop due to their ISP or VPN experiencing problems or a directed attack at them or their ISP/VPN. This is bad for anonymity as adversaries may use this to deanonymize the user.

I think it's helpful to split this attack into two variants: discovery and confirmation. Discovery would be using natural conditions (network instability, time of day) correlated with the peer's connectivity/latency to narrow down where they are, their guards, or their own connection. Confirmation is the ability to actively abuse a relay/router/clear internet target and observe the effect on your peer to validate your guesses.

Tor is naturally weak against the confirmation attack. Even in non-hidden-service usage, those attacks are very effective, especially on long-lived connections like IM. We can try to mitigate specific situations, but in many ways it's an inherent flaw of real-time communication.

I'd split the discovery attack into two categories: trusted attackers (your approved contacts) and untrusted attackers. It's most important to prevent an untrusted attacker from learning anything. Fortunately, that's something we can address with smarter treatment of hidden services and contact requests: as much as possible, I'd like to avoid exposing online state and latency to unapproved peers, at least in any useful detail.

A message relay can make it more difficult to conduct the discovery portion of this attack, but only when it completely obscures (at least within some grace period) your actual connection state. You also remain vulnerable to the same attack by (one of) your relay(s). The costs and complications are significant and the benefit is limited. A user who is very concerned about being deanonymized by their approved peers over time may be more comfortable with high-latency (email-like) services instead - where solving these problems is much more realistic.

We need more research on these topics, and how they apply to Tor and hidden services especially. There may be defenses we could use by throttling incoming circuits, introducing false latency, throttling reconnection, etc. We can't completely solve the situation, but I am certainly interested in how we can make attacks more obvious or more difficult.

2 . The user may wish to go offline for several hours (ex. school, work, sleep, etc) and still want to be able to receive messages without keeping their computer on.

This is the more compelling case for using (in some cases) message relays/servers. I'd be interested in discussing designs that would allow:

1. Storage and retrieval of messages for your peers without being simultaneously online
2. Without exposing, including over time, your relationships or any useful information about your communications
3. With the ability to detect message loss and tampering by the server
4. While maintaining the general principles and security model as they exist now

I think this could be addressed relatively simply with appropriate cryptography (Open WhisperSystems' work on asynchronous OTR is interesting) and without trusting message relay(s) with any useful information. That seems like an appropriate starting point for extending the design beyond simple peer-to-peer connections. And in the long term, with more research and understanding of the issues, it could build into helpful solutions for connectivity attacks.

What're your thoughts?

from ricochet.

There is a clear need to build a high-latency mixnet on top of Tor, but as @special said it remains a research topic. We're perhaps nearing the point where we can do it more-or-less right though.

If you want asynchronous messaging now, then you should use Pond : https://pond.imperialviolet.org/

from ricochet.