[liberationtech] Broadcast Anonymous Routing

[Randolph]

Dear George, Deat Travis,
of course there should be some congestion control, and there is - also
you can decide for half or AE.
http://goldbug.sf.net/img/AE-grid.png
When you decide for bandwidth efficiency, you also decide for exact
graphs. As Thomas wrote, XMPP is a direct graph and srambler messages
need some bandwidth, but propose as well some privacy. (Which means
OTR in the graph theory does not make any sense in regard of anonymity
- which leads to the interesting research question, if privacy is
guaranteed more with encryption or with anonymity or with a mix of
both). Circulating the, in your words, bartender role would be hard
for the XMPP approaches. Regards Randolph

2014-08-18 16:19 GMT+02:00 George Chatzisofroniou <sophron at latthi.com>:
>
> Exactly. To make this distributed, we should circulate the role of the bartender
> to the users themselves.
>..  a peer may receive the same message more than one time wasting even more bandwith.
> --
> George Chatzisofroniou
>
>>On Mon, Aug 18, 2014 at 10:07 AM, Thomas wrote:
>
> Travis, I try to write my homework for university about it and refer on the
> source and the given documents like user manuals etc. My focus is the client
> http://firefloo.sf.net which is hybrid with XMPP and the encrypted Echo
> Protocol and I write a comparision of OTR and native echo encryption, which
> should evaluate that OTR has potential security flaws due to the plugin
> architecture and the non-symmetric encryption of XMPP' s end-to-end
> encryption. The question here is, what is regarded as the end of XMPP
> connections? One hop to the other user and/or one hop to the next server.
> There could be (unknown) plaintext hops of XMPP, which allow the OTR
> protocol handshare to be insecure.
> https://citizenlab.org/2014/08/cat-video-and-the-death-of-clear-text/
> XMPP is not fully encrypted and no one knows it for the chains and hops, a
> messages takes. So the FireFloo client is to be evaluated in this regard.
> A summary coulld be that plaintext-chat-servers have to die and must be
> replaced for security reasons by zero-knowledge- (in the sense of processing
> only ciphertext) servers. As well all chat clients need to have a check
> routine, to deny chat server connections, which are initiated in plaintext.
> There is no one doing this for the oldfashioned protocols and clients, so
> they must be regarded as insecure and even OTR is compromisable via man in
> the middle attacks then. The XMPP/TLS-architecture is a flaw and regarding
> graphs, you see where the messages are traveling. The BAR approach is not
> bad and follows the echo protocol deriving from the nerdd pre-echo project
> registered 2010-06-27 (and then shifted over to the spot project), it´s
> Python, isn`t it? Could be interesting to see the Client Gui evolving to a
> real echo chat client and having all the security approaches of the echo
> protocol added, which then is another echo client which would be compatible.
> http://goldbug.sourceforge.net/new.html But why Python when a C++ kernel is
> given? creating a new chat-server software in just another language is not
> required until you do a client as wlel in that language, though I wounder if
> you can't connect a pyhton gui to a c++ kernel - as it uses HTTPS.
> Kind Regards Tom
>
> On Wed, Aug 6, 2014 at 3:26 PM, <liberationtech-request at lists.stanford.edu>
> wrote:
>>2014-08-18 3:20 GMT+02:00 Travis Biehn <tbiehn at gmail.com>:
>> In for more info on ECHO / Spot-On protocols available implementations
>> etc.
>>
>