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

Linuxtag 2014

Posted on by

From the 8th to the 10th of May 2014, we represented the FSFE at the Linuxtag 2014. It was my first task as an intern and as such my introduction to the FSFE.

Generally it was a really valuable and exciting experience in the sense that I had the chance to learn and read about the various campaigns and activities of the FSFE as well as the many other initiatives taking place in other organizations. To give a more detailed overview of the individual days and possible improvements for the coming years, I have summarized them together with some comments below.

As a small disclaimer I should mention that I am lacking a reference to compare this event with, which might have lead me to perceive certain aspects differently from how others might have experienced them. Also, Linuxtag coincided with Droidcon and one day of re:publica. I am not certain whether this is usually the case, so it may be something to bear in mind.

Enough of the fine print, enjoy the read!

Wednesday:

In an email we received prior to the event we were advised to arrive a bit later than the official setup time of 20:00. Upon our arrival at about 20:45 we were told that our booth had not been set up yet and that additional time was needed.

We then decided to talk to the builders of our booth and found out that they expected not to be done before around 1:30-2:00 at night.Since we had to finish the booth at 8:30 the next morning, we decided to leave our materials with a trusted employee of the building company and left to catch some sleep for the days to come.

Thursday:

We managed to set up the booth rather quickly, trying to make most of the limited space available. Around us all the other booths were set up and people got ready for the first day.

In my view this was probably the most exciting phase of the three days since I got to discover the many fascinating projects around us. One of the most interesting acquaintances were the friendly people behind http://www.rechenkraft.net/, a foundation that facilitates the scientific use of distributed computing power, since I had dealt with the the movement in my master thesis on protein folding software.

As this was the day that coincided with the Re:publica, the group of ‘non-experts’ was relatively high. This was beneficial for me since it gave me a chance to test my knowledge of the FSFE and its individual campaigns through explaining, which as I have recently learned dramatically increases the long term memorability of the subject matter at hand.

If I remember correctly, Thursday night was also the night of the party which I did not participate in since I was too tired.

Friday:

On Friday, I took a good portion of the day to explore the stands that I had missed out on during the previous day and decided to join a few talks. Since I am more of a political science person, most of the talks were too technical with a few exceptions that dealt with issues of privacy in relation to the Snowden leaks etc.

As for the visitors at our booth, my estimation would be that there was a conversation taking place most of the time with a few quiet episodes in between. We could comfortably handle the amount of visitors and had enough time for each of us to occasionally leave the booth to explore the surrounding.

By the afternoon I was getting more and more comfortable with presenting the campaigns and topics and more and more people filled out the quiz we had brought with us. The latter consisted of six pages with about five multiple choice questions each, more about this in the conclusion.

Saturday:

Saturday was the community day with ticket prices being reduced from approx. 150 to 10 Euros. I expected this day to be the most busy one due to the comparably cheap entrance fee, however I have to admit that the big stream of visitors I envisioned did not occur.

Since this was the third and last day, most of the exhibiting parties had already visited one another’s booth and it felt a bit slow towards the end. We then decided to pack everything together and left.

Conclusion:

As I have mentioned in the introduction, the Linuxtag was a motivating and interesting experience for me personally. I obviously cannot speak for the FSFE as a whole.

As I have learned, the sale of the merchandise was on the very low end, which would mean that measured by that factor, its value is very low. On the other hand, it appeared to me that the Linuxtag as a chance to encounter other members of the Linux movement served its purpose.

As for our booth, the leaflet that resonated the most with the visitors was the F-Droid leaflet. The quiz we handed out was also well-received, if a bit lengthy for some. The latter concern turned out to be unfounded as we had about 40 filled out quizzes by the end of the Linuxtag.

One thing that could certainly be improved upon in terms of the quiz is its educational value: Since one of the main functions of the quiz is to educate the participants on Free software, it would be great to have a way of giving them feedback on their answers. This could be done in a number of ways:

  • the quiz could be moved online by using a QR code
  • the participants are explicitly asked to provide some form of contact information so that they can be contacted afterwards.

The first solution obviously means more work beforehand, the latter more work afterwards. Apart from this issue, the quiz contained several ambiguous answers that will be sorted out for the next time.