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 <[email protected]>: > > 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, <[email protected]> > wrote: >>2014-08-18 3:20 GMT+02:00 Travis Biehn <[email protected]>: >> In for more info on ECHO / Spot-On protocols available implementations >> etc. >> > -- Liberationtech is public & archives are searchable on Google. Violations of list guidelines will get you moderated: https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, change to digest, or change password by emailing moderator at [email protected].
