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.
I really like OTR as a concept, but there are several places where it seems like every implementation I’ve seen falls down:
User authentication: The initial authentication method is fine, but it doesn’t seem to carry over between sessions very well. All it tells me is that *at some point* the person I meant to talk to was on the remote end; after that I’m just trusting that they’re still there (i.e. Pidgin’s “Start private conversion” option just works, with no further authentication.) When a key changes on the remote end, there is little warning (compare what pidgin-otr does with what, say, SSH does), and (see below) key changes are frequent enough that this is a pretty big problem.
Key authentication: Every client creates its own key, and so work/home/mobile need to be re-authenticated separately. There is no key infrastructure of any kind. It sure would be nice to be able to bootstrap off of OpenPGP (i.e. sign your OTR key(s) with your PGP key and it just works).
Key security: Every implementation I’ve seen keeps the private key unencrypted with the account profile, enabling stuff like http://parkerhiggins.net/2012/01/howto-transfer-otr-private-keys-between-adium-and-pidgin/
Multiple-login support: All of the clients I’ve tried are bad at handling XMPP’s multiple resource/simultaneous logon system.
Multiple-login support was fixed by a recent protocol change (OTRv3). The other issues are still around, although there was a discussion on the mailing list recently about support for sharing public keys (and private keys?) between different clients on the same machine.
First of all many thanks for this! This is exactly the kind of IM encryption we need: truly private and easy to use! I have a lot of IM contacts who are waiting for this. Is there any time frame in which we may expect this?
There is no time frame for 3.0.0 release – I will post about it when any estimations come up. Until then, you can use current 2.x.y version with “old” pidgin-otr plugin.
Are file transfers encrypted aswell?
I use pidgin alot and will test the new version with otr included from now on.
No, file transfers are not encrypted.
I think the version ready for testing will be available in few weeks.
Any news about it? Thanks. :)
The code is ready at the moment, but still waiting for a code review by OTR plugin maintainers.
Are video conversations encrypted?
Also, the fact that otr doesn’t work when the contact is offline is a major inconvenience. It is technically possible to work with offline messages, Telegram does exactly that. There should be optional “forever session” which remains after both users log out. It’s a tradeoff between perfect forward secrecy and offline messages but many prefer the former.
As I replied for your another comment, video is not supported (neither now or in the future).
I’m not sure if there is any point in making “offline otr messaging” possible. Anyway, If you really insist on discussing it, the better place would be libotr mailing list.
“No, file transfers are not encrypted.
I think the version ready for testing will be available in few weeks.”
what is the status?
Is there any solution to use private messaging whit OTR and simultaneously have previous messages in log?
i mean when we use OTR previous messages don’t save and remain for next logins to be shown.