Re: [briar-devel] How does Briar know where to send a message to reach a given user?

[Greg T. <gd...@le...>]

James Marshall <ja...@jm...> writes:

> I'm planning a secure social media tool, an alternative to FB where users
> don't need to trust any servers (which makes it different from the
> federated tools I know about).  Servers would do little more than pass
> encrypted messages among users and other servers.  I like Briar's
> priorities and approach to security, and I may try to use some of Briar's
> code in it, or at least the protocols.

Two thought from that:

  Briar is essentially what you want, perhaps missing some features.
  Consider extending Briar instead.

  Briar is heading in the direction of federated personal servers (but
  with the big point of a server for each person), so that they can be
  always reachable.  Understand Briar's issues with power usage, then
  design, and then post it for review.

> As I understand it, a Briar user's identity is basically just their public
> key (?).  If each user isn't associated with a server, like the
> use...@se... that some federated tools use, then how does user A
> know where to send a message to get to user B?

There's identity, and there's address.  Briar shares a tor hidden
service address with peers and one communication method is to contact
the other briar node over tor.  The others are local only, so tor is the
only method for people not near you, more or less.

> Unless I'm missing something, I don't see how to do that without a
> centralized lookup server, which I thought Briar is trying to avoid.
> Maybe server info is stored with each contact?

Yes, the hidden service.  But you don't need a centralised server, you
need a worldwide service which can be distributed.  tor HS are such a
distributed service.

> I would love for my tool not to require a server name in user IDs; it would
> be easier to use onion servers, for example, and easier to transparently
> migrate to a different server.

I don't follow your concern.  Briar keeps the HS name in the db and
doesn't show it to the user, so it isn't hard.  If you mean "just type
in the name", then you need centralized registration, or to bootstrap on
centralized registration like DNS.

> Thanks a lot!  Links to docs, discussions, or relevant source code are most
> welcome.

A huge issue in Briar was and still is power usage.  For reasons that
aren't fundamental, tor uses huge amounts of power when offering a
hidden service (on a phone; regular computers call this same usage very
little power!).  So enabling the HS on your phone -- which is necessary
to receive messages from people who aren't on the same wifi or in BT
range -- runs the battery down, unacceptably for most.  Surely
acceptable to some if their actual threat model is as bad as Briar's.

There are two paths forward, and as I understand it both are happening:

  fix tor to not need a wake lock for a HS.  then it will just be sort
  of heavy usage, but probably good enough

  allow personal relay boxes that speak the protocol, but can't decrypt,
  that are someplace with power, with a different HS, that the user
  polls when they want to get mail (or when they are plugged in, etc.)


Also, see the literature on Disruption Tolerant Networking, which for a
time in the 2000s was very successful at extracting funding from
research sponsors :-)   But seriously, there is the notion of
transferring messages over a network with occasional connectivity and
node movement.   The problems are:

  figuring out routing is very hard,  You can't flood, because that
  doesn't scale.  You don't know who is going where.

  if you want to trust no one, do you trust strangers?

briar avoids this by not doing routing, just direct delivery, via wifi,
bt, or tor HS.  It is headed to 1-hop routing, where the intermediate is
specified by the peer, avoiding both of the above issues.