Image of the glider from the Game of Life by John Conway
Skip to content

Bitlbee and OTR

I'm actually surprised that I haven't blogged about this before, seeing as though I use it daily. Further, seeing as though I seem to be on a security blogging trip, it only seems fitting to discuss OTR support in Bitlbee now.

OTR, or Off-The-Record messaging is the ability to have encrypted and authenticated communication with full deniability and perfect forward secrecy. The idea is simple. Just as you want to be able to deny anything you say to a journalist when "off-the-record", you should be able to have that ability with instant messaging. It works by not cryptographically signing the message. It's just encrypted, and your buddy decrypts it on the other end. Further, each message is encrypted with a one-time AES session key. This means that even if you successfully snatch the AES key for encrypting and decrypting the message, it only applies to the current message, and does nothing for the previous messages, nor does it do anything for you on future messages. Thus, you have perfect forward secrecy with your chat. However, I want to spend some time on the inner workings of how authentication and trust are established, if the messages aren't signed for validation.

First, OTR is fully supported in Bitlbee version 3.0 and later. For Debian and Ubuntu packages, you will need to install both the "bitlbee" and "bitlbee-plugin-otr" packages if you want to take advantage of it. Of course, you could grab the source, and compile it in yourself as well. Once installed, you will want to generate master keys for each account you wish to use OTR with. You can get a list of your accounts with "account list" in the &bitlbee window of your IRC client:

15:20 <@aaron> account list
15:20 <@root>  0 (gmail): jabber, aaron.toponce@gmail.com (connected)
15:20 <@root>  1 (twitter): twitter, aarontoponce (connected)
15:20 <@root>  2 (identica): twitter, eightyeight
15:20 <@root> End of account list

I wish to use OTR with my Gmail account. Thus, I need a key for the account. You can run "otr keygen <account-no>" for this:

otr keygen 0

It will take some time to generate the key, as it grabs entropy from /dev/random. You may want to add more entropy to the pool by running "du -sh /" from a different terminal to help speed things up. Wiggle the mouse, type in text editors, do other things to generate environmental noise. After it's finished, you can see the key fingerprint by running "otr info":

15:28 <@aaron> otr info
15:28 <@root> private keys:
15:28 <@root>   aaron.toponce@gmail.com/jabber - DSA
15:28 <@root>     8D57F662 D991493F 1084427E 31C7E1B9 2074B713
15:28 <@root>  
15:28 <@root> connection contexts: (bold=currently encrypted)
15:28 <@root>   (none)

Now, you're ready to communicate with your buddies via OTR. The question that will likely come up now is how do you know if the person you wish to communicate with secretly is really the person you expect? Well, for the years that I've used OTR, I've trusted the individual implicitly. I've communicated with their account enough that when we both decide to "go secure" with our chats, that it's no big deal. I just trust their keys, they trust mine, and we go about our day. However, you may not want to do that, but want to explicitly acknowledge that you are communicating with who you think.

This can be solved a number of ways:

  1. You could call them on the phone, and verify fingerprints verbally.
  2. You could agree on a shared secret before initiating the communication electronically, and use that shared secret to trust the keys.
  3. You could issue a challenge/response question to the opposite party. If they answer correctly, trust the key.

Personally, I like the challenge and response system. It's not too terrible difficult to think of a question that only your buddy would know, and issue the challenge for them to respond. Of course, they need to do the same with you. This is known as the Socialist Millionaire Protocol. Use "otr smpq <nick> <question> <answer>". It could go something like this:

otr smpq foobar "What color pen did I use on your whiteboard yesterday? one word, lowercase" red
15:35 <@root> smp: initiating with foobar...

On the other end, the nick "foobar" would have seen this:

06:42 <@root> smp: initiated by aaron with question: "What color ped did I use on your whiteboard yesterday? one word, lowercase"
06:42 <@root> smp: respond with otr smp aaron <answer>

At this point, "foobar" wishes to respond, as he thinks he knows the question. He would use "otr smp <nick> <answer>":

otr smp aaron red
06:43 <@root> smp: responding to aaron...
06:43 <@root> smp aaron: correct answer, you are trusted

At this point, I now trust that foobar is who he says he is, so I can trust any OTR communication from him. However, he hasn't verified that I am who he thinks I is. After all, I could be someone pretending to be Aaron, and get sensitive information from him. So, he should issue the same challenge and response to me. Something that only Aaron would know, to thwart any potential baddies. Should I answer correctly, he can then trust my fingerprint, and we will have 2-way OTR communication.

When everything is said and done, Bitlbee will print out the following:

15:36 <@root> smp foobar: secrets proved equal, fingerprint trusted

You can also verify it with "otr info <nick>":

15:37 <@aaron> otr info copecd
15:37 <@root> foobar is foobar@gmail.com/jabber; we are aaron.toponce@gmail.com/jabber to them
15:37 <@root>   otr offer status: none sent
15:37 <@root>   connection state: cleartext
15:37 <@root>   fingerprints: (bold=active)
15:37 <@root>     13C45179 F2A8645B 466463E8 228DBE16 787D1A82 (affirmed)

As already mentioned, there are other ways for verifying that the person on the other end is who they say they are, and OTR in Bitlbee supports it. You will notice too, that once the fingerprints have been trusted on both sides, the text is green in the chat window. If not trusted, the text is red. As far as I know, there is no way to change the color, or have any other sort of visual clue on whether or not trusted encryption is taking place in the communication.

Also, is should be worthy to note that Bitlbee OTR only supports conversations through Bitlbee, not your IRC client. This means that if you are using Irssi, Weechat, or some other IRC client, Bitlbee OTR won't help you for IRC messages. You'll need an OTR plugin for that as well. This is definitely a drawback. For example, if you use Irssi like I do, there is an OTR plugin for Irssi. Not only will it handle IRC, but any message through IRC, including those of Bitlbee. However, the Irssi OTR plugin hasn't been updated in two years, and it has security holes that haven't been addressed. The Bitlbee OTR plugin is up-to-date and in my opinion, much more streamlined. I don't use private IRC messages much, so the Bitlbee OTR plugin works just fine for me.

Now, start using OTR with Bitlbee. If you love your Bitlbee as much as I do, you will. :)

{ 5 } Comments

  1. Dominik Honnef using Google Chrome 9.0.597.94 on GNU/Linux | March 8, 2011 at 8:11 pm | Permalink

    Hey, thanks for the nice article!

    I actually didn't know that bitlbee 3 comes with proper OTR support.

    I, however, am facing a problem and couldn't find a solution yet: Even though bitlbee has been compiled with --otr=1, ldd shows that the bitlbee binary indeed links against libotr and "help otr" lists all available otr commands, none of them work. every "otr *" command just returns "Unknown command: otr"

    If anyone else encountered this problem and knows how to fix it, I will greatly appreciate any help.

  2. Dominik Honnef using Google Chrome 9.0.597.94 on GNU/Linux | March 8, 2011 at 8:30 pm | Permalink

    Okay, most stupid mistake I could've made: I was still running an earlier version of bitlbee and never reconnected after updating it. Sorry for the noise.

  3. Ahmed Kamal using Google Chrome 10.0.648.127 on GNU/Linux 64 bits | March 9, 2011 at 3:33 pm | Permalink

    This is awesome stuff! Please keep those articles coming, #crypto is cool :)

  4. Luke Faraone using Google Chrome 9.0.597.107 on Ubuntu | March 10, 2011 at 7:41 am | Permalink

    Took me a while to figure out you were referring to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=569506 wrt irssi-plugin-otr insecurity

  5. onny using Google Chrome 23.0.1271.95 on GNU/Linux | January 2, 2013 at 10:36 am | Permalink

    You should really consider joining Flattr! I really would like to support such helpful articles.

Post a Comment

Your email is never published nor shared.

Switch to our mobile site