[liberationtech] How secure is Bitlbee?

[Uncle Zzzen]

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 <StealthMonger at nym.mixmin.net
> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Uncle Zzzen <unclezzzen at gmail.com> 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 <StealthMonger at nym.mixmin.net>
>     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:stealthsuite at nym.mixmin.net?subject=send%20index.html
>
>
> Key: mailto:stealthsuite at nym.mixmin.net?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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20121225/b8bdaf66/attachment.html>