How strong is the privacy requirement?
Currently, Briar’s threat model is to not only preserve message content privacy, but also to preserve metadata privacy wherever possible (e.g. keep private who is talking to who, and at what time). For example, currently 1-on-1 private messages aren’t able to be relayed through mutual contacts in order to preserve metadata privacy. Currently the only messages that can be properly multi-hopped through a network of contacts are group chat messages and blog posts.
There’s pretty much a direct correlation between privacy and connectivity in these types of ad-hoc networks, so we have been thinking about ways to allow users to selectively control their connection preferences over time, one suggestion is to add in a tor browser-like security level selector.
There’s also been some interesting discussion on this topic on the briar-devel mailing list if you’re interested: briar-devel Mailing List for Briar
Worth mentioning there is a project working on the “weakest” privacy level, optimizing for connectivity at the cost of metadata privacy (note that all message content is still e2ee): https://qaul.net
I am thinking of the middle of the road where anyone can know you are running Briar but does not know your Briar-handle, who you are communicating with, or such at all. Basically on the same level as Signal.
One interesting project I found since my last message was Willow Protocol. From my understanding, it actually uses private set intersection to allow peers to discover shared namespaces, and if there is >1 shared namespace, the peers deterministically sync those namespaces with each other.
This is very close to the idea I was describing previously, and might allow for a high-connectivity ad-hoc messaging system that also gives users reasonable privacy assurances.
Hmm… an idea comes to mind how to do Private Intersection Set via virtual sequential logic circuit run ontop of Ueli Maurer’s SMPC
Apologies because this is going to take me some time to wrap my head around, but this is really interesting work, thank you so much for the link to the SMPC paper and the circuit writeup!