Den 5 jan 2014 13:23 skrev "Randolph" <rdohm...@gmail.com>: > > 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
There are the I2P method of everybody acting as anonymizing relays + layered end-to-end encryption make traffic analysis nearly impossible (you don't know where any packet originated from). There's already a chat program using it called I2P Messenger, and it's serverless. XMPP has also already been made to work over I2P. And there's the batching method (send everything at once in a fixed size message). Could work well with Moxie's axolotl ratcheting key exchange to establish PFS encrypted chats. Both of those can be strengthened by throwing in fake traffic. I don't like the option of *only* hiding your activity among fake activity generated only by your own node, it's too easy to attack with things like statistical means and watching what the node does if you disrupt it's Internet connection (such as making it somewhat unreliable through DDoS:ing it's router or whatever). (And FYI, OTR is secure independently of the channel it's used over if the keys are verified. But it ONLY protects the contents of the chat.)
_______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
