Why OTR?
Recently we have covered data encryption and signing with GPG, which is widely used and is nice for many purposes, yet some of its properties may be not desirable for instant messaging, while some of the properties which it does not possess may be desirable: for instance, a basic signed message provides the means for authentication (shows who wrote the message), non-repudiation (the one who wrote it can’t deny that), and data integrity verification (the message can’t be altered by a third party); let’s consider the second property. You are sending a signed and encrypted message to another person – say, complaining about your teachers, parents, job or government to somebody, or sharing books, music or movies; encryption helps to ensure that only that person will receive the message, everything’s fine. The next day you find that the receiver is not a nice person, and now they have a proof of you writing that, which you can’t deny once it’s presented to others (well, you can claim that the key was compromised, but it’s still considerably worse than if such a proof didn’t exist in the first place). If the key really gets compromised, we come to another OpenPGP weakness: all the previously encrypted messages addressed to you also get compromised.
GPG is good for some purposes, but for others it is far from perfect. Luckily, there are alternatives: OTR (Off-the-Record Messaging) was designed to get a more appropriate alternative to GPG for secure instant messaging – taking human behaviour and various life situations into account.
There are other alternatives (which we probably will cover in future articles), but after applying the basic rules from the GPG article, we simply arrive to OTR: it is supported and used relatively widely, it is a serious project, and it provides useful features, such as deniability and perfect forward secrecy.
Why IM?
Although mail is not drastically different from IMs, such as XMPP, and one protocol can be used in place of another, their common use cases do differ, particularly in that we normally don’t expect a mail recipient to be online. But OTR establishes a secure channel before messages can be sent, making it rather impractical to use in such a mode. Other differences include the expectation that letters would be written to a disk in plain text (while IM logging may be turned off, reducing the risk of leaks) and delayed letter delivery (slow spam filters and IMAP/POP3); though it all can be avoided, that’s the current state of things: in most cases IMs are just more suitable for low latency message exchange, which is pretty much what makes them IMs, and hence for OTR.
Using OTR
Just as GPG, OTR is not limited to any particular network protocol, and various multi-protocol clients do support it: some are listed in the “OTR-Enabled Software” section and in the Wikipedia article; among those are BitlBee, Adium, Kopete and Pidgin.
Those programs would do pretty much everything automatically, but there are some things that are useful to know about the protocol.
First of all, you should have a key pair – just as with OpenPGP: usually it gets generated by a client when you enable OTR for the first time. But instead of using those keys to encrypt and sign your messages directly, OTR generates a common symmetric key using Diffie–Hellman key exchange – as does TLS, so participants get authenticated to each other, but any of them can encrypt the messages, and make them look like they came from the other side – only the participants will know whether those are real. Cryptography is full of cool tricks!
To make things fancier, OTR also supports socialist millionaire protocol (how it works), which helps to ensure that the person you are talking to is who you think they are: basically, you provide a question and an expected answer, that person receives the question and answers it, and the protocol checks whether the answers match, but without revealing them. Another (and more reliable) method is to meet in person and exchange your public keys’ fingerprints, but often it is less practical, or to sign them with GPG, if you have exchanged those keys previously.
One more useful to know thing about OTR is that it can be configured to indicate your willingness to use OTR, but without necessarily visible messages: just by adding whitespace characters to one of your messages. So that OTR won’t be required, and won’t even be visible in most cases, but will be established if both participants are willing to use it when possible.
There are other guides and explanations around: Beginners’ Guide To Off-the-Record Messaging and OTR with bitlbee, for instance, and the specification itself is readable.