[liberationtech] Broadcast Anonymous Routing

[George Chatzisofroniou]

Hi Marc,

On Sun, Aug 17, 2014, Marc W. Abel wrote:
> Where can I find the BAR paper referenced on [1]?  It would help me 
> understand some of your decisions and threat model better.  I also will 
> need to cite it in my own papers.

The BAR paper has not yet been published. Hopefully, it will be until the end of
2014. I'll keep you informed.

> You might also be interested in Clique [2], which I published July 4 and 
> announced on this list August 4.  Your feedback on that would be 
> splendid, although I need to write a paper with some better 
> explanations.  A short comparison, as I understand things:

This is great! Clique looks promising. Thanks for posting it.

> 1.  Both of us made very poor choices when we named our protocols. How 
> on earth is someone to find us on a search engine?

That's true. Both names are easy-to-remember though. :)

> 2.  BAR communicates via an anonymity network like Tor (?)  Clique is 
> not an anonymity protocol; it is a metadata privacy protocol.

BAR *is* an anonymity network just like Tor or I2P using its own protocol.

> 3.  BAR aims to provide low latency.  Clique is intended to be a little 
> faster than U.S. Mail.

That's correct. BAR aims to provide strong anonymity with low end-to-end
communication latency.

> 4.  BAR's per-network scaleability limit is a few hundred nodes. Clique 
> is intended to be "good" at 30,000 nodes and "fair" at 1,000,000 nodes.

That's true only for the very basic version of the protocol that has been
implemeneted and is presented in the above guide. In the extended protocol, our
system is scalable enough to support concurrent anonymous communication of
thousands of users.

> 5.  BAR costs "a few Mbps" of bandwidth.  Clique hasn't even been tested 
> that fast, but is designed to consume roughly one VOIP channel's 
> bandwidth equivalent in common use.

Yes, we've tested several scenarios and it appears that BAR can provide strong
anonymity by investing a few Mbps bandwith.

> 6.  BAR appears to be written in... Python?  Clique had a Python 
> implementation, but it proved unwieldy.  Its reference implementation is 
> written in C.

Yes, the protocol components are written in Python using the Twisted networking
library. It seems sufficient for now.

> 7.  BAR's user interface is ... not known to me.  Clique's user 
> interface /doesn't exist/ today, although sample scripts are provided.

There is no GUI yet. You can use the CLI version though [1].

> 8.  BAR's encryption is ... well, I'm not sure.  Clique's encryption is 
> a little nonstandard and a little controversial.

BAR attempts to minimize public key encryption in favor of symmetric. Although,
for allowing global communication of users belonging to different broadcast
servers, the extended BAR protocol comes with a key management mechanism that
provides random session public keys.

> 9.  Does BAR work on mobile devices?  Clique does not work natively on 
> mobile devices, although workarounds exist if a user can arrange for a 
> secure non-mobile node.

Our implementation has not yet been tested on mobile devices.

> 10.  BAR is organized around a central server.  Clique isn't centralized 
> at all.

Yes, although it is easy to distribute this role to the users themselves.

> 11.  Bandwidth of BAR's peers is determined by _________ and (circle 
> one) IS / IS NOT configurable.  Clique's peers individually set their 
> own bandwidth.

In the extended protocol, we introduce an entity (no trust assumptions are
required for it) that sets the broadcast efficiency (bandwith) parameter with
respect to the anonymity parameter. A user could potentially configure its
bandwith at some level but is not recommended as it will compromise her
anonymity.

[1]: https://sophron.github.io/BAR/install.html

-- 
George Chatzisofroniou