[liberationtech] Broadcast Anonymous Routing

[Travis Biehn]

Randolf,
We're in agreement on that. OTR encrypts the message but leaves all the
metadata intact. This is a 'bad thing'.

I read sims.me's messaging app security blurb. It seems that it just uses
end-to-end encryption with AES, public keys are federated by a central
authority.
In this scheme if sims.me gets owned or if their private keys get owned an
adversary can just serve you an incorrect public key for the peer you're
trying to chat with. There are a few other attacks.... but the important
thing is that key federation is broken under the scheme ;) Sims is also not
doing anything (that they state in the readme) for metadata 'occlusion'
e.g. any network observer can tell that Bob and Alice are definitely
chatting.

I'm not sure why Echo / AE / Flooding would be used in lieu of onion
routing... TOR based would show that Bob was transmitting something. I2P
would show no metadata about transmission or reception.

Am I missing something?

-Travis


On Tue, Aug 19, 2014 at 2:02 PM, Randolph <rdohm321 at gmail.com> wrote:

> 2014-08-19 19:26 GMT+02:00 Travis Biehn <tbiehn at gmail.com>:
> > 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.. XMPP routers may indeed be
> > compromised.
> >
> > 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 (then)
> > both endpoints 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, A(daptive)ECHO, 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
>
>
> Dear Travis,
> both must be done, using strong multi-encryption and hiding in the
> crowd. If XMPP would offer real end to end encryption and not only
> point to point encryption, OTR would be more secure in the phase of an
> initial certificate handshake of a man in the middle attack. Offline
> Messaging and receiving authenticated (which means to block
> non-authenticated messages) and re-newing the encryption key per
> session would be other security topics. The architecture is currently
> an insecure mosaic, so it makes sense to focus on these new securtiy
> protocols and research them too.
> Echocasting or Broadcasting or Flooding, whatever you call the echo
> protocols, could be analysed in regard of either bandwidth and further
> scalability. Bandwidth could only be on a mobile a real problem, so I
> wonder which of the new ideas are mobile ready. Sims.me/security
> (mobile messenger by DHL Logistics) by the way has a similar
> encryption architecture and sets a new standard for XMPP. But it is
> not open source and graph theory is simple here; even for a round
> table graph theory is quite trivial to explore:
> http://en.wikipedia.org/wiki/Graph_theory
> Regards Randolph
> --
> 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/20140820/adcceb9c/attachment.html>