On Thu, Oct 26, 2017 at 12:01:22PM -0400, Nathan Freitas wrote:
On 10/26/2017 03:47 AM, Georg Koppen wrote:
- It should support onion service-based chat protocols. Those are a
good showcase for metadata-free chat/messaging and we should support that + convince users to switch to them.
What if took a step back, and actually design and implemented a native Tor protocol reliable messaging layer, within the Onion Service protocol? There a lot of issues related to presence, offline delivery, asynchronous nature of messaging, and encryption that Ricochet ran into as part of their work.
I know there was talk of mix networks on top of Tor, and other DHT/blockchain style efforts like BitMessage can work well over Tor, too.
This could maybe dovetail with a suggestion I made long ago to many Tor developers and researchers, but neither myself nor anybody else has had enough time/inclination to explore: Tor mostly builds circuits pre-emptively rather than on-demand. Tor circuits could be built in a simple timed-mix style. Every relay holds circuit extension requests for N seconds (order tens of milliseconds?) and then forwards all extend cells from the last N seconds.
Questions include: what should N be? How much would this actually raise the load on a approximately GPA (adversary that is trying to just hoover up all (non-relay) timing info to associate circuits from network observations? Would it in fact raise the load for relevant adversaries any significant amount at all or is it pointless? What fraction of circuits must be on-demand (or on-demand for all hops)? What are the usability trade-offs of making all/some circuit builds conform to this? What are the security trade-offs of making all/some circuit builds conform to this? Is the simple timed-mix the best we can practically do here?
If messaging errr? cells could conform to the same (or compatible a la tau-mixing) mixing constraints this could help with anonymity sets on both sides. Now do lots of research and/or wave hand as needed.
Ultimately, just moving to HTTP over Onion peer-to-peer messaging, doesn't seem like enough, and definitely would expose a lot of issues on mobile, where expecting a user to be online all of the time is just not a reality.
This might also help with that issue, or maybe make it harder ;>)
aloha, Paul