Off-The-Record (OTR) Messaging

Posted on by

Table of Contents:

  1. Introduction
  2. What is OTR?
  3. How does OTR solve the issues of GnuPG?
  4. Installation Example of OTR messaging in Pidgin running on Debian
  5. Some disadvantages of OTR
  6. Available distros, applications, and plugins

1. Introduction:

The purpose of this post is to clarify the meaning and technicalities of ‘off-the-record’ (OTR) messaging and to give insight into the possibilities of implementing it in various devices and Eco-systems. Furthermore some evaluating remarks on the advantages and drawbacks of OTR in comparison to GnuPG will be added.

2. What is OTR?

2.1 “Off the record”

OTR messaging is derived from the original concept of a private “off-the-record” conversation. Two people meet in private and have a conversation, without any observers or recording devices. The content of the information exchanged is merely known by the two parties involved in the conversation, so that the only record kept is their own ‘mental record’. In terms of technology, such a level of privacy is translated in two phenomena: ‘perfect forward secrecy’ (PFS) and repudiability.

2.1 Perfect Forward Secrecy

Wikipedia defines the former term as “a property of key-agreement protocols ensuring that a session key derived from a set of long-term keys cannot be compromised if one of the long-term keys is compromised in the future”, and states that the “key used to protect transmission of data must not be used to derive any additional keys, and if the key used to protect transmission of data is derived from some other keying material, then that material must not be used to derive any more keys”. Thus, the “compromise of a single key permits access only to data protected by that single key” [1].

2.3 Repudiability / Deniable Authentication

Repudiability (or: deniable authentication) refers “to authentication between a set of participants where the participants themselves can be confident in the authenticity of the messages, but it cannot be proved to a third party after the event” [2], thus creating a state of secrecy that allows two participants in a conversation to identify each other, but makes it impossible for a them or a third party to do so after the conversation.

2.4 OTR vs. GnuPG

In a paper [3] written by two Berkeley scientists and the creator of the most widely used OTR software published in “Workshop on Privacy in the Electronic Society“, OTR is presented and compared against GnuPG. While the authors agree that GnuPG encrypted conversations appear to be a secure way of communicating, they criticize that an evesdropping third party could theoretically store all the encrypted conversations and attempt to obtain the private key of one of the participants in the conversation at some point in the future. If the third party were successful, it not only could read all past and future communication but also reveal the signatures featured within the messages, thus giving way to the identities of the conversation partner’s identity. Thus, according to the authors, GnuPG suffers from the lack of PFS due to the longevity of its keys.

3. How does OTR solve the issues of GnuPG?

3.1 Some Remarks

First of all it should be noted that, while OTR solves some of the issues of GnuPG, it cannot replace it in the email context due to its technical characteristics. OTR is largely a technology made for the area of instant messaging, so that the following comments are aimed exclusively at this domain.

3.2 PFS through short-lived keys

In terms of PFS, OTR uses short-lived keys that are discarded after use. To do so, it uses the Diffie-Hellman key agreement protocol, which (without diving into too much mathematical detail) essentially allows the transmission of a maintained secret through the public due to each participating party choosing a variable that is then used to en- and decrypt the secret.

3.2 Repudiability by lack of private keys

In terms of the issue of identification, OTR wants to avoid another pitfall of GnuPG, which is the public key each individual spreads and attempts to keep alive as long as possible. Through the process known as key-signing, users of GnuPG obtain increasing credibility of identity through increasing numbers of key signatures. The downside of this is, that the signatures of messages can later be used to prove the identity of a certain individual, despite whether the person does consent with it or not. Put differently, one might not want to be connected to a secret one has sent at some point in the past, even if the recipient of the secret is or has been trustworthy at the time.

3.3 Identification despite lack of private keys

Thus, the issue is that the sender needs to be able to prove one’s identity to the recipient without the recipient or a third party later being able to do so. This is achieved through message authentication code (MAC) keys, which are calculated based on a secret mac key that is exchanged secretly, using a method similar to the Diffie-Hellman principle. This means that only the individual message can be assigned to the sender, but no identity is revealed.

3.4 Deniability through forgeability

To go even further, OTR messaging applies the principle of forgeability through malleable encryption. The principle of forgeability is to create encryption in such a way that it is very “easy to alter the ciphertext in such a way as to make meaningful changes in the plaintext, even when you don’t know the key”. To give an example for this, imagine the following scenario: you have sent a message with the content “I want to meet you tomorrow to give you flowers”. An FBI agent has intercepted your message. The fact that the message is malleable means that some slight changes in the encrypted data could easily result in the message saying “I want to blow up the trainstation and kill myself”. In other words, since the message is encrypted in such a way that it is easy to make meaningful changes to its content by simple manipulations of the code, arguing for any meaning within the decrypted message is obsolete. Put even more simple, even if the content of the message was decrypted, an argument can be made that the content could have easily be changed by a third party.

In more technical terms: OTR “encrypts the plaintext by masking it with a keystream using the exclusive-OR operation; to decrypt, the same exclusive-OR is used to remove the keystream and reveal the plaintext. This encryption is malleable, as a change to any bit in the ciphertext will correspond to a change in the corresponding bit in the plaintext”. If an interceptor “can guess the plaintext of a message, she can then change the ciphertext to decrypt to any other message of the same length, without knowing the key. Therefore, a message encrypted with a stream cipher does not prove integrity or authenticity in any way”. The participants in the conversations “can still use a MAC to prove […] that [their] messages are indeed [theirs]” [3].

4. Installation example for Pidgin running on Debian

In this example, the process of enabling OTR for pidgin on Linux is shown.

1. First of all, we need to install pidgin. This is achieved by using the standard package management tool or the “Add/Remove Software” tool.

2. Once Pidgin is installed, the following command needs to be run in the terminal in order to install the OTR plugin:

3. Once the installation of the OTR plugin has succeeded, OTR messaging can be enabled in the pidgin settings (“Tools/Plugins” in the top menu bar):

4. The last step is configuring a fingerprint:

5. Now OTR for Pidgin is set up and running, and can be used enabled in the messaging window – provided the communication partner has it enabled as well:

6. When both parties have OTR enabled, there still is the process of identification that has to take place. The options to do so are “Question and Answer, Shared Secret, or Manual Fingerprint Verification”:

7. Finally, OTR is enabled and private messaging can commence!

Note that the above procedure is can be applied for a range of messaging services including Facebook chat (see bellw), ICQ, AIM, irc, Jabber, MSN messenger, etc.!

5. Some disadvantages of OTR:

With the introduction to OTR given and the installation procedure explained, it is time to critically reflect on the technology from a user standpoint. Please note that some of the remarks below are valid for several types of encryption services an not merely for OTR.

The first and most obvious issue is one that is shared by other encryption procedures as well: it only works if both parties use it. Since this is a immanent issue of message encryption services, the question that remains is how difficult it is to use in a real-life scenario. Whereas for instance Apple’s iMessage encryption is implemented into the device and operates ‘invisibly’ to the user, the use of OTR requires some significant effort and some degree of technical expertise. In a related note, OTR isn’t supported by many of the most commonly used messaging services such as Whatsapp or Skype. This means that the user in question would need to make a switch to a messaging platform that supports OTR first.

The mere process of grasping the encryption principles of OTR, which is arguably a necessary step to convince someone to begin using it over another channel of communication, does take some time and effort. This Thirdly, platform fragmentation, especially in the mobile segment, does pose additional challenges to the adoption of OTR. For instance, the process of fingerprint validation between iOS and Android devices needs to be optimized.

Moreover, the OTR level of security comes at a price: messages are typically inaccessible once the connection has been closed, which may be unappealing to some users who are used to being able to browse their message history. Obviously this is more of an issue of education rather than one of features, but it needs to be accepted as such.

On the side of the level of privacy given by OTR, an important thing to note is that the higher level IM protocol can give your identity away depending on how you use it. Since this is a question of implementation, it should be taken with a grain of salt. Nonetheless, as Mathew Green put it [4]: “In fact [OTR is] such a good idea that if you really care about secrecy it’s probably one of the best options out there.”

6. Available distros, applications, and plugins:

OS Distributions which ship with OTR software

IM clients which support Off-the-Record Messaging “out of the box”

Third-party plugins for IM clients

Libraries that support OTR

* Software developed by the OTR Development Team

 

 

[1] https://en.wikipedia.org/wiki/Forward_secrecy

[2] https://en.wikipedia.org/wiki/Repudiability_%28cryptography%29

[3] https://otr.cypherpunks.ca/otr-wpes.pdf

[4] http://blog.cryptographyengineering.com/2014/07/noodling-about-im-protocols.html