Thanks. Traffic analysis is indeed a concern, but it seems to me that if there's a way to solve this for jabber, it should be on the server side (perhaps even a tor-like network of jabber servers bouncing "onionized" messages between each other). Still - as jabber clients go - I don't see how this problem makes bitlbee any less secure than jitsi or pidgin.
My question was whether bitlbee was peer reviewed by anyone here and what's the impression (relative to other OTR-enabled jabber clients). If one can judge from user interface, bitlbee's OTR-awareness seems to be pretty serious: * You can maintain multiple keys per buddy, show you how each one was authenticated (affirmed, smp, or smpq), and which one (if any) is active at the moment. * If a buddy sends you an unencrypted message (e.g. from gmail's web interface), it doesn't mess up the session (jitsi could really get catatonic in such cases): you get a bold notice that the incoming message was not encrypted. If that buddy still has an OTR conversation open with you on some other client (say pidgin), you can verify that (with an "otr info" command), and if that is the case - what you type will be sent encrypted (your buddy will see raw OTR rubbish on gmail's web interface, but can switch to pidgin to see what you actually said). Of course, all this doesn't help much if there are low level vulnerabilities I'm not aware of, which is why I'm asking whether anyone knows how safe bitlbee is believed to be by security professionals (e.g. those who say pidgin is less secure than jitsi). Cheers, The Dod On Mon, Dec 24, 2012 at 6:38 AM, StealthMonger <[email protected] > wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Uncle Zzzen <[email protected]> writes: > > > Lately I've discovered http://www.bitlbee.org/ and I feel a lot more > > comfy with it. My question is, how secure is Bitlbee compared to > > Jitsi or Pidgin? > > bitlbee appears to be a low-latency, connection-based technology and > will therefore have the same security defects as any other low-latency > technology, such as Tor. Low latency implies that an observer who can > monitor both sides of the connection can swiftly detect that they are > in communication, just by the packet timing and volume. > > To avoid this defect, security has to be message-based rather than > connection-based, and the messages have to be encrypted and travel via > a channel having high, random latency so that they get mixed with > other such messages, thwarting traffic analysis. An example is the > mixmaster anonymizing remailer network [1]. > > Tor documentation [2] is relevant here: > > ... for low-latency systems like Tor, end-to-end traffic > correlation attacks [8, 21, 31] allow an attacker who can observe > both ends of a communication to correlate packet timing and volume, > quickly linking the initiator to her destination. > > [1] http://www.banana.mixmin.net/ > > [2] http://tor.eff.org/cvs/tor/doc/design-paper/challenges.pdf > > - -- > > > -- StealthMonger <[email protected]> > Long, random latency is part of the price of Internet anonymity. > > anonget: Is this anonymous browsing, or what? > > http://groups.google.ws/group/alt.privacy.anon-server/msg/073f34abb668df33?dmode=source&output=gplain > > stealthmail: Hide whether you're doing email, or when, or with whom. > mailto:[email protected]?subject=send%20index.html > > > Key: mailto:[email protected]?subject=send%20stealthmonger-key > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Processed by Mailcrypt 3.5.9 <http://mailcrypt.sourceforge.net/> > > iEYEARECAAYFAlDXchEACgkQDkU5rhlDCl7sQACgyD92iBtJD3XLREPb1OFmxGZc > bXcAni+10N/j5y3PGR7QR90CqxkwYgLx > =H0Cc > -----END PGP SIGNATURE----- > > -- > Unsubscribe, change to digest, or change password at: > https://mailman.stanford.edu/mailman/listinfo/liberationtech >
-- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
