Hi - a "scrambler" could send out from time to time fake messages. - an "impersonator" could record your own chat behaviour and generate random time and lenght and content data, so it looks like your own chat - the main problem remains that from an external analysis you can always see, that User A is sending (a messge) to User B. This can only be solved with sending the Message (originally addressed to A) to all connected people, so as well to B, C, D, E and F. A kind of "echo" would solve this.
EMPP (library: http://spot-on.sf.net, echoed message and presence protocol) has this all and XMPP could benefit from it or - as some discuss - why not merge EMPP and XMPP or even send echo over an xmpp acccount? Would a XMPP connection allow a selfsigned SSL connection over/through it ? I still wounder, why XMPP is not adding end-to-end encryption and it must be done over a plugin (OTR). D/H key exchange / TLS can be attacked by a man in the middle, especially if you use : User A -> TLS -> Own Webserver <- MITM / - Maybe: TLS - <- Own Webserver <- TLS <- User B User A does not know, if the cert between two Webservers is compromised. Or elsewhere in the chain. Only End to End proves, that you have full continuity in your TLS chains. And: Is a D/H key exchange for OTR secure over a broken TLS? But: The problem is not securing xmpp, the problem with XMPP is, that you easily know, who is talking with whoom. This makes no sense to think about adding a scrambler to it, especially if you are not interested in the content, but in the social network one maintains. >From the kids on the block perspective, XMPP is the glorification of open source. Nothing else has to be there. But is this a differentiating view? Form the developer side there are different views: http://harmful.cat-v.org/software/xml/xmpp/ If adding fancy helper tools like encryption or scramblers makes this more easy, dunno. Some Dinos have still homework to do and must be regarded outdated until not a native (and not only plugged) end to end encryption is in. This is not liked, we know, but us as XMPP server admins need to be taken away the possibility to read plaintext. And this is a transformation we after occurances of the last year have to bear. Jabber Servers without Plaintext is the Vision of 2014. And this becomes real Feb. 22 ? 2014/1/5 Fabio Pietrosanti (naif) <li...@infosecurity.ch> > Hi, > > XMPP networks are now going to be default secured with TLS in their > client-to-server and server-to-server communications by 22th Feb. > > Most IM client support end-to-end encryption with OTR by default. > > The "Federated Architecture" make it very scalable and distributed. > > With all that "goods of COMSEC" in place, we are missing a timing > correlation protection schema for XMPP traffic, to avoid an adversary > "monitoring your internet communication line" to know "when" you have > written something. > > POND is a super technology to prevent timing correlation attacks > (https://pond.imperialviolet.org/tech.html), unfortunately it's a closed > network so i don't think it would ever get diffused (it's also written > in GO and my religion does not let me use anything written in GO). > > So i've been thinking that we need "a method" to achieve protection > against time traffic correlation attacks on XMPP chat. > > It's possible that, by having a traffic-generator-robot (behaving like > an XMPP buddy you connect to), and an XMPP client plug-in it would be > possible to create some kind of "constant traffic timing pattern" to > avoid an adversary being able to make timing correlation attacks. > > Something like that would be "relatively easy" to be implemented. > > This would bring "timing correlation attack protection" to the already > existing security stack of XMPP: > - Client TLS encrypted login > - Server-to-Server TLS encrypted communication > - end-to-end encrypted communication with OTR > - Federated architecture > > -- > Fabio Pietrosanti (naif) > HERMES - Center for Transparency and Digital Human Rights > http://logioshermes.org - http://globaleaks.org - http://tor2web.org > > _______________________________________________ > cryptography mailing list > cryptography@randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography >
_______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography