OTR with bitlbee

Off-the-Record Messaging, commonly referred to as OTR, is a cryptographic protocol that provides strong encryption for instant messaging conversations. OTR uses a combination of the AES symmetric-key algorithm, the Diffie–Hellman key exchange, and the SHA-1 hash function. In addition to authentication and encryption, OTR provides perfect forward secrecy and malleable encryption.

BitlBee supports OTR natively since 3.0, but it's an optional component.

Note that this requires running your own BitlBee. OTR functionality should not ever be offered on any public server as it only gives a false sense of security! It is important to note that if you have logging turned on for BitlBee then your OTR messages are in vain. Also they could trace your connections via your network connection.

For more information on how to use OTR, see help otr and other existing documentation.

Enabling OTR support

When using distro packages, there is hopefully a bitlbee-plugin-otr package you can install.

When compiling your own BitlBee, pass --otr=1 or --otr=plugin to the configure script.

You'll need the right version of the OTR library installed, with its development headers.

Version reference

Since the OTR versions seem to be a bit confusing, here's a nice table explaining absolutely everything.

Modern distros only include libotr4 and will work fine with newest bitlbee.

OTR-related settings

• otr_policy

  • Possible values: never, opportunistic, manual, always
  • This setting controls the policy for establishing Off-the-Record connections. See the next section for details.

• otr_color_encrypted

  • If set to true, BitlBee will color incoming encrypted messages according to their fingerprint trust level: untrusted=red, trusted=green.

• otr_does_html

  • based on ticket#690 this "causes OTR plaintext to always be considered HTML."

    • Even though the spec defines that HTML markup is optional (Data Message section) in practice OTR messages are HTML messages for most (if not all) clients.

OTR policies

• never: disables the OTR subsystem.

• opportunistic: A magic whitespace pattern will be appended to the first message sent to any user. If the peer is also running opportunistic OTR, an encrypted connection will be set up automatically.

• manual: OTR connections must be established explicitly using otr connect.

• always: enforces encrypted communication by causing BitlBee to refuse to send any cleartext messages at all.

The "magic whitespace pattern" that opportunistic OTR uses consists of 16-40 bytes of either space or tab characters (See the "Tagged plaintext messages" section of the OTR spec for more details). This might cause minor visual issues in some IM clients.

Simple Question and Answer Response

You can authenticate a user's fingerprint by asking a question using the otr smpq

   1 <@alice> otr connect bob
   2 <@alice> otr smpq bob "question question question" answer
   3 <@root> smp: initiating with bob...

On the other side:

   1 <@root> smp: initiated by alice with question: "question question question"
   2 <@root> smp: respond with otr smp alice <answer>
   3 <@bob> otr smp alice answer
   4 <@root> smp: responding to alice...
   5 <@root> smp alice: secrets proved equal, fingerprint trusted

Issues

OTR does NOT work (well) with offline messages.

Without previous or future chat-session, offline messages from either party will not be passed on and no notification will be sent. OTR messages are only being delivered in these scenarios:

1. User "A" and "B" are in an OTR session, when "B" is disconnecting. Messages from "A" are being delivered after "B" reconnects.
2. User "A" is attempting an OTR session with the offline-user "B", when "B" is connecting while "A" is still online.