Hey Tom, Thank you for your reply. I admit I have a bit of difficulty parsing it, however ;) So to summarize: You're researching OTR, ECHO Protocol and the FireFloo client. You posit that because XMPP supports federation along a mix of TLS and plaintext interconnects that OTR is therefore susceptible to a man in the middle attack. This is absolutely correct, in fact, it would be correct even if all servers from the originator of the message to the termination of that message were over TLS links that were doing certificate pinning, where public pins were exchanged in person between XMPP routers. The reason for this is the problem: Everything is insecure. XMPP routers may indeed be compromised.
If you have inspired the ire of certain oppressive regimes then it will be a miracle if not only all of the routers you use are compromised but your endpoints as well. So the problem that OTR is solving is exactly this. You cannot know or trust the routers either at the application layer or at the network layer. Thats why OTR exists. It is message encryption negotiated between endpoints. Key federation under the OTR scheme: in order to be confident that the endpoints are chatting to each other through a secure channel they must exchange key fingerprints out of band OR conduct validation under the SMP ZKP. This is what prevents wholesale man in the middle attacks against OTR messages routed outside of your trust boundary. If these fingerprints are validated by the out of band channel or ZKP by both endpoints they can be reasonably sure that they are communicating over a secure channel - regardless of the maliciousness of the XMPP routers that they are connecting through. The problem after key federation and the reason that these protocols (BAR, ECHO, AECHO, Clique etc) exist. They are trying to resolve the metadata aspect of communication. OTR protects message content but does not make any efforts at obscuring metadata - OTR attempts to address this problem by attempting to include properties of deniability. Unfortunately mathematic deniability as a property of a cryptographic system is likely not enough to stop "Threat Agents" interested in total information awareness. These new schemes operate by distributing these messages through either an onion routing arrangement and/or by distributing multiple messages at once from either a centralized or decentralized system. Most messages are just entropy an observer of the network cannot distinguish between noise and signal in such as system. Of course key federation in these schemes again is a weak link - Web of Trust and PKI are such imprecise topics, I have a feeling it tends to scare the talented away. As a final note regarding mixing of programming languages, I'd prefer my clients be written in languages which clearly distinguish between executable code and data. Preferably one which doesn't provide direct access to memory at all. Unfortunately it seems that there are various problems with cleansing secrets from memory when you write in such a language, or the impression that that problem exists. Hope this was helpful. -Travis On Mon, Aug 18, 2014 at 4:07 AM, Thomas Asta <[email protected]> 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]. > -- Twitter <https://twitter.com/tbiehn> | LinkedIn <http://www.linkedin.com/in/travisbiehn> | GitHub <http://github.com/tbiehn> | TravisBiehn.com <http://www.travisbiehn.com> | Google Plus <https://plus.google.com/+TravisBiehn>
-- 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].
