[liberationtech] Broadcast Anonymous Routing

[Travis Biehn]

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 <thomasasta at googlemail.com>
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.
> >
>
> --
> 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
> companys at stanford.edu.
>



-- 
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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20140819/03bba4a8/attachment.html>