OMS (Onion Messaging Server) Support

[xagifu]

Note: This is probably beyond the scope of Torsion's design goals, but in attempt to solve some anonymity problems here is a rather long winded idea.

This topic is discussing a theoretical feature/enhancement to solve two issues:

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.
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.

Technical/protocol changes:
A new mode OMS would require:

1. Server software or for the client to be able to optionally (at user's discretion) double as server software.
2. In the Torsion client when the users selects to activate OMS mode they locate three OMS servers with both a long uptime and reliable reachability.
3. A DHT or another means of the OMS servers of keeping record of uptime and reachability so that clients can discover them.

Scenario:

1. Bob wants to be able to receive messages even when is connection is lost or when he is offline for several hours.
2. Bob wants to be able to keep his torsion buddies from knowing when he is online and/or when is VPN/ISP has dropped his connection -- preventing correlation between his own location and his anonymous torsion identity.
3. Alice wants to talk to Bob or leave a message for Bob.
4. Carlie, Dave, Edith, Fanny, and Garth all decide to run the Onion Messaging Server (OMS) which means each of these are running their own Tor Hidden Services.
5. Bob, in torsion, changes his 'receive mode' from Onion Instant Messaging (OIM) to Onion Messaging Server (OMS).
6. Bob's client discovers (using DHT or another means) Carlie, Dave, Edith, Fanny, and Garth all running Onion Messaging Servers.
7. Bob's client selects the three most reliable with some randomization.
8. Bob's client notifies his friends which three servers his messages should be sent to.

In OMS mode:

1. Bob's Hidden Service goes offline, even if he is at his computer running Torsion.
2. Bob's Torsion no longer attempts to connect to his friends' Hidden Services.
3. Alice is no longer able to see him online, but once she gets the info on which three servers he is collecting messages from she can leave messages for him there.

Randomly between 6-12 hours the client sends out updated info to friends on which servers to reach them on. This could be directly or perhaps though those same servers with a signed message.

Basic layout idea:
Alice > Server1 >
Alice > Server2 > Bob
Alice > Server3 >

Message splitting, storage, and retrieval:

1. The message is encrypted so that only the Tor Hidden Service owner (of that private key) can read it.
2. Messages are similar to One Time Pad. The data-stream is randomly split into two streams that when combined reconstruct the original message.
3. Similar to the raid mechanism for reconstruction data when some of it is missing the two streams are both partly Xor'ed so that a third stream can be used to reconstruct the two streams in full data if one of them is lost.
4. Before sending the encrypted and split/Xor'ed message to a server the result is again encrypted with the public key of the recipients tor hidden Service and signed by the sender's key. This ensures that server will know who to give the message to and for the receiver to know the message is authentic before looking for the other parts and wasting time attempting to decrypt it.

Cons:
This method allows for the middle anonymous servers to hold encrypted message data. It is not ideal that the server can see quite a bit of info in this scenario. The server knows who sent the message, when they send it, can easily determine about how big the message is, to whom the message was sent, and when, if ever, the recipient retrieved that stored message.

Other thoughts:
After 50 hours a friend's three selected Onion Messaging Servers are considered outdated and no longer a trustworthy way to reach that friend. For example, if the user is offline for 20 hours the friends client and the receiver's servers should still allow incoming messages. The server's messages could time out after 50 hours and at the time also show that the peer is no longer available. This time would ideally be randomized by at least a few hours to prevent knowing exactly when a peer went offline (ex. exactly 50 hours ago, or always at 10pm).

An alternative to using three unknown servers is using a single or few friends to store the message. This has similar problems to the three unknown servers and goes back to giving your friends potentially a lot of info about you that you might prefer they didn't have.

If one of the three servers goes offline can the other two know about it? And if so can they recreate a new third server? This seems like an security issue as if the servers could know if one when offline they must know their address, which means they might be able to collude to recreate the source encrypted message. This is not critically bad, but it is not exactly great. I2P might be able to do this by having new tunnels with new b32 addresses that cannot be linked back to a particular host, but that might also have other problems.

[special]

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?

[burdges]

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/