Modern instant messengers claims about security and privacy. And users trusts them. But companies that delivers such services sometimes fails protecting their users privacy. The point is, that user doesn’t have any control over confidentiality of his private conversations – the service provider does it.
In most cases, this schema works pretty good: user A sends a private message via an encrypted connection to a service provider and the provider sends it to the user B (also using an encrypted connection). The problem occurs, when the intermediary company reveals such message – due to software failure or dishonest employee.
Encrypting the message by A seems to be the solution, but it creates another set of problems. To make user A able to encrypt a message for user B, he have to obtain a B’s public key. But how to obtain it in a secure way? What, if B loose his key, used to secure a long history of conversations? Also, to make user B sure, that the A sent the message, user A have to sign it. But what, if user A says something humiliating to user B in private, but the second one reveals the message to the public and use it against A? The message is signed by A, so there is a proof he wrote it.
And there comes the Off-the-Record Messaging protocol. It’s goal is to provide truly private conversations over any underlying IM protocol (such as xmpp, ICQ, Gadu-Gadu) in a easy to use manner. It ensures four aspects of privacy:
- encryption, so nobody other than A or B can read their messages;
- authentication of the other party, to make sure we are talking with the right person;
- deniability, because messages does not have digital signatures that are checkable by a third party – the other side of conversation cannot prove, the messages he got are sent by you (but he’s still sure about it);
- perfect forward secrecy – if someone get your private keys, he won’t be able to decrypt any past conversations.
OTR and Pidgin/libpurple
There is a plugin for Pidgin, implementing OTR messaging – pidgin-otr. Unfortunately, the user have to install it by himself, so it’s not as easy to use as in other messengers. I was asked to integrate it within the official release.
I decided to make this task a bit more challenging. Pidgin-otr is a Pidgin UI client plugin, so it’s not available for other libpurple clients. Some of them (Adium) implements OTR by itself, some (Finch) doesn’t offer such functionality. I decided to rewrite it as a pure libpurple plugin, to provide this excellent feature for all clients that use libpurple as a backend. Fortunately, pidgin-otr is pretty well designed, so I had only to alter things related directly to the UI.
There already was a similar attempt, named purple-otr. Its main problem was really poor UI – its author used pretty limited libpurple’s Request API to create dialogs, so he wasn’t able to clone all pidgin-otr’s functionality. My situation is way more comfortable, because I am a Pidgin developer (having direct impact on its code), working on a 3.0.0 version (which breaks API, so I don’t have to care about compatibility). That means, I was able to extend libpurple’s features to better fit OTR plugin needs. Some of libpurple API changes that made it possible:
- End-to-End encryption providers API allows to present (implementation independently) conversation’s security state. Previously, pidgin-otr and similiar plugins placed their own controls in various parts of the conversation window, now it’s standardized.
- Request API refactored with PurpleRequestCommonParameters, which makes this API easily extendable.
- Using PurpleRequestCommonParameters for new features implementation, like an option to provide HTML decorated text descriptions, an option to alter the dialog icon, to make better control over the dialog buttons.
- Adding a new window type: cancellable “please wait” dialog, with an optional progress bar.
These changes may not look crucial. In fact, without them the libpurple’s pidgin-otr port would look really poor or even awkward.
At this point, all conversation-related code is ready and working fine, and it’s possible to use it conveniently. I haven’t implemented configuration dialogs yet (It’s the next task for me) nor adapted Finch for the new API (so it’s not possible yet to use it with OTR, but it’s not the hard part).
Unfortunately, there is no possibility to test it at the moment. The libpurple’s part is in its repository, but the new pidgin-otr is developed in its non-public branch in OTR authors repo.