Off-the-record messaging

Off-the-Record Messaging ( OTR , German  unofficial, confidential, message transmission not intended for the public ) is a protocol for message encryption in instant messaging . It regulates the ongoing updating and management of short-lived session keys.

In contrast to the transmission of encrypted messages with OpenPGP (or in rare cases with an X.509 certificate), with off-the-record messaging it is no longer possible to determine later whether a certain key was used by a certain person (principle of credible deniability , English plausible deniability ). As a result, after the conversation has ended, nobody (not even either of the two communication partners) can prove that one of the communication partners made a certain statement.

This principle is implemented through the combined use of the symmetrical cryptographic process Advanced Encryption Standard (AES), the Diffie-Hellman key exchange and the cryptographic hash function SHA-1 . A program library and numerous instant messaging programs are available that can use the protocol either directly or via additional modules.

Objectives of the project

The following four cornerstones are defined in the statutes of the project:

Encryption (Encryption)

Nobody can read the news.

Authentication (authentication)

You can be sure that the recipient is who you think they are.

Repudiation (deniability)

Encrypted messages do not contain an electronic signature . So it is possible for someone to forge messages after a conversation so that they appear to have originated from you. During a conversation, however, the recipient can be certain that the received messages are authentic and unchanged.

Consequences ( Perfect Forward Secrecy )

If the (long-lived) private key falls into the hands of a third party, this has no effect on the compromise of previous conversations: the conversations cannot be decrypted subsequently.

Technical implementation

The following section simplifies the function of the OTR protocol in version 2.

overview

During their communication with each other, Alice and Bob choose private keys respectively . Two at a time, for example and , are used to create a shared secret using Diffie-Hellman key exchange . The keys and are calculated from this secret . ${\displaystyle x_{1},x_{2},\ldots }$ ${\displaystyle y_{1},y_{2},\ldots }$ ${\displaystyle x_{i}}$ ${\displaystyle y_{j}}$ ${\displaystyle s}$ ${\displaystyle s}$ ${\displaystyle K_{\text{AES}}}$ ${\displaystyle K_{\text{MAC}}}$

${\displaystyle K_{\text{AES}}}$is used to encrypt every message using the Advanced Encryption Standard (AES) in counter mode . This turns the symmetrical block cipher AES into a stream cipher . Alice and Bob use digital signatures for initial authentication , so they can be sure who they are communicating with during the conversation. is used to authenticate a single message using the SHA-1 ( Secure Hash Algorithm 1) hash function , which is used as the Message Authentication Code (MAC). ${\displaystyle K_{\text{MAC}}}$

When sending messages, new private keys , respectively , and generates the corresponding AES and MAC key. The private keys that are no longer used are deleted so that Alice can no longer be associated with her messages. However, this also means that Alice can neither read her own nor Bob's messages afterwards. In addition, MAC keys that are no longer used are published so that any other person could have signed Alice's messages. ${\displaystyle x_{i+1}}$ ${\displaystyle y_{j+1}}$

For the Diffie-Hellman key exchange is a 1536-bit prime number and a primitive root modulo with needs. All exponentiations then take place modulo this prime number. ${\displaystyle p}$ ${\displaystyle g}$ ${\displaystyle p}$ ${\displaystyle 2\leq g\leq p-2}$

initialization

At the beginning of a conversation, initial keys must be exchanged and the authenticity of the call participants must be checked, i.e. Alice and Bob must each be sure with whom they are communicating. This prevents Alice, for example, from exchanging keys with the attacker Eve instead of Bob . The whole process is called Authenticated Key Exchange (AKE) and implemented using the SIGMA protocol:

1. Alice and Bob choose private key , respectively (min. 320 bit long), replace the corresponding public key , respectively , and obtained by the Diffie-Hellman method , a shared secret . ${\displaystyle x_{1}}$ ${\displaystyle y_{1}}$ ${\displaystyle g^{x_{1}}}$ ${\displaystyle g^{y_{1}}}$ ${\displaystyle s=\left(g^{x_{1}}\right)^{y_{1}}=\left(g^{y_{1}}\right)^{x_{1}}=g^{x_{1}\cdot y_{1}}}$
2. Via a secure channel can be created now, each communication subscriber authenticates itself using a digital signature to the other about that. Currently, OTR only supports the Digital Signature Algorithm . ${\displaystyle s}$

In between, the connection is always encrypted with AES as far as possible and individual messages are authenticated using SHA-256 - HMAC .

Send a message

Suppose Alice wants to send the message to Bob . It carries out the following steps: ${\displaystyle M}$

1. Alice selects the last Diffie-Hellman key she received from Bob . Bob's key is considered received if he used it for a message that Alice received or was previously exchanged using AKE (see section above), which obviously can only be in the case . ${\displaystyle x_{i}}$ ${\displaystyle g^{x_{i}}}$ ${\displaystyle g^{x_{i}}}$ ${\displaystyle i=1}$
2. If Alice's newest Diffie-Hellman key, she randomly generates a new key of at least 320 bits in length. ${\displaystyle x_{i}}$ ${\displaystyle x_{i+1}}$
3. Be the last Diffie-Hellman key received from Bob. The key is deemed to have been received if Bob added it to the last message (see below) or if it was exchanged using the AKE. ${\displaystyle g^{y_{j}}}$
4. The common Diffie-Hellman secret can now be calculated (modulo ) as . ${\displaystyle p}$ ${\displaystyle s:=\left(g^{y_{j}}\right)^{x_{i}}}$
5. Calculate the AES key , where the first 128 bits of the SHA-1 hash value denotes. was previously brought into a certain data format and expanded by one byte . ${\displaystyle K_{\text{AES}}:=H(s)}$ ${\displaystyle H(s)}$ ${\displaystyle s}$ ${\displaystyle s}$
6. Compute the MAC key as the 160-bit SHA-1 hash value of . ${\displaystyle K_{\text{MAC}}}$ ${\displaystyle K_{\text{AES}}}$
7. For the counter mode that will be used later, a counter is required that is selected so that the triple never occurs twice during the entire message exchange with Bob. ${\displaystyle c}$ ${\displaystyle (i,j,c)}$
8. The message is now encrypted in counter mode using the AES algorithm. The key used for this is the meter you just selected . The message encrypted in this way is called . ${\displaystyle M}$ ${\displaystyle K_{\text{AES}}}$ ${\displaystyle c}$ ${\displaystyle N}$
9. The encrypted message , , and some cryptographically unimportant parts such as the version number of the protocol to be combined and which Authentication of the message code using the key computed. Here denotes the Keyed-Hash Message Authentication Code (HMAC) using the hash function SHA-1 and the key . ${\displaystyle N}$ ${\displaystyle i,j,c}$ ${\displaystyle g^{x_{i+1}}}$ ${\displaystyle T}$ ${\displaystyle MAC_{K_{\text{MAC}}}(T)}$ ${\displaystyle K_{\text{MAC}}}$ ${\displaystyle MAC_{K_{\text{MAC}}}}$ ${\displaystyle K_{\text{MAC}}}$
10. ${\displaystyle T,MAC_{K_{\text{MAC}}}(T)}$ and all unused MAC keys are sent to Bob over an insecure channel.

Receive a message

Bob receives the data generated above from Alice and does the following:

1. Bob has already received it either through an old message from Alice or via AKE. Thus it may be the same Diffie-Hellman shared secret by calculating, with and in denote indexes contained. ${\displaystyle g^{x_{i}}}$ ${\displaystyle s:=\left(g^{x_{i}}\right)^{y_{j}}=g^{x_{i}\cdot y_{j}}=\left(g^{y_{j}}\right)^{x_{i}}}$ ${\displaystyle i}$ ${\displaystyle j}$ ${\displaystyle T}$
2. Just like Alice and, he can calculate. ${\displaystyle K_{\text{AES}}}$ ${\displaystyle K_{\text{MAC}}}$
3. With the help of , he calculates and compares the value received with that transmitted by Alice. This checks the authenticity of the message and protects it against middleman attacks. ${\displaystyle K_{\text{MAC}}}$ ${\displaystyle MAC_{K_{\text{MAC}}}(T)}$
4. With the help of and , which is contained in the message sent by Alice , he decrypts the message with the AES algorithm in counter mode and receives it back. This works because AES is symmetrical, meaning that it uses the same key for encryption and decryption . ${\displaystyle K_{\text{AES}}}$ ${\displaystyle c}$ ${\displaystyle T}$ ${\displaystyle N}$ ${\displaystyle M}$ ${\displaystyle (K_{\text{AES}},c)}$

Review of goals

Encryption (Encryption)

The AES cryptosystem used has been subjected to detailed cryptanalytic tests and is practically computationally reliable.

Authentication (authentication)

Using AKE and digital signatures, Bob can be sure (even at a later point in time) that Alice has chosen the public key . Since the next message and thus also the next key is signed with the help of this key , Bob can be sure of the identity of the person he is speaking to in all subsequent messages. ${\displaystyle g^{x_{1}}}$ ${\displaystyle g^{x_{2}}}$

Repudiation (deniability)

Alice only uses her digital signature at the beginning of the conversation. All subsequent messages are signed with the MAC keys . Since the shared secret is required to generate the MAC key , Bob can be sure that Alice has signed the message. However, he cannot prove this to anyone else, as he could have signed the message as well. In addition, by publishing MAC keys that are no longer used, nobody can check the authenticity of the messages, as anyone could have signed them. Only Bob can be sure that Alice sent the message, since only both of them know the corresponding MAC key at the time of receipt. However, by using a digital signature at the beginning of the conversation, nobody can deny that a conversation has taken place. ${\displaystyle K_{\text{MAC}}}$ ${\displaystyle s}$

Consequences ( Perfect Forward Secrecy )

If Alice loses her long-lived private key, none of the short-lived private keys can be derived from it, since these were never published and deleted shortly after they were used. Since only these short-lived private keys were used to encrypt and sign the messages, the conversation was not compromised despite the loss of the long-lived private key. ${\displaystyle x_{1},x_{2},\ldots }$

Another security concept is counterfeitability . With the stream cipher (AES in counter mode) used for encryption , in which the plain text is simply linked with an XOR in order to obtain the ciphertext , the attacker can modify the ciphertext if part of the plaintext is successfully guessed so that this part becomes any text decrypted. This does not reduce security, because by signing the message with the MAC key, Bob can be sure that the falsified message did not come from Alice. However, the attacker can subsequently sign this message because the associated MAC key was published. This makes it more difficult for Alice to be associated with her through the content of a message, since the message can subsequently be signed by anyone and modified to a limited extent.

Cryptanalysis

A computer-aided cryptanalysis of the protocol in version 2 was carried out by Stanford University and several vulnerabilities were discovered: A middleman attack made it possible to switch to an older version of the protocol (e.g. version 1) in order to exploit its weaknesses. Furthermore, deniability in the strongest sense, that is, that anyone could have signed a message, is no longer given in the case of an attacker with complete control over the network. This can replace the published MAC keys with random data, which means that it is no longer possible for others to validly sign messages with these keys. In addition, the authors found an attack during the authentication in the AKE, which, however, can be discovered and does not have any far-reaching consequences.

Availability

Reference implementation

libotr
Basic data
developer	The OTR team
Current  version	4.1.1 (March 9, 2016)
operating system	Windows , Linux , x BSD , macOS
programming language	Java (java-otr) or C (libotr)
category	Encryption
License	LGPL / GPL ( Free Software )
German speaking	Yes
otr.cypherpunks.ca

The two developers, Ian Goldberg and Nikita Borisov, provide a program library called libotr as a reference implementation of the protocol . It is also published in source code as free software and licensed under the terms of the GNU Lesser General Public License (LGPL). A toolkit for forging messages is provided with the library. The developers also provide a plugin for pidgin . The latter are both subject to the terms of the GNU General Public License (GPL).

Native support

The following clients natively support off-the-record messaging. This includes that you can use OTR with all implemented instant messaging protocols (for example OSCAR , XMPP , MSN and YIM ). Another list of programs can be found on the developer's website.

Inherent part

• Adium ( macOS )
• BitlBee (platform-independent), from version 3.0 (optionally adjustable at compile time)
• CenterIM (Linux / Unix) supports OTR from version 4.21.0
• ChatSecure ( iOS )
• climm ( Linux / Unix ) supports it directly since 0.5.4
• IM + (Android / iOS)
• Jitsi (formerly SIP Communicator) ( platform-independent )
• LoquiIM ( Firefox OS )
• Mcabber (Linux, several BSD - derivatives , OS X) supports OTR directly since 0.9.4
• Phonix Viewer (platform independent), a viewer for the game Second Life , supports OTR discussions within the game
• qutIM (platform-independent) since 0.3.1
• Rocket.Chat (platform-independent)
• SecuXabber (Android) supports OTR natively (beta)
• Spark (platform-independent)
• Xabber (Android) supports OTR natively since 0.9.27 (only XMPP)

Plugin

• Gajim (platform independent) has a plugin from version 0.15
• Irssi (platform independent) has a plugin
• Kopete ( Linux / Unix ) has a plugin (from version 0.50.80 / KDE 4.1 official)
• Miranda IM ( Windows ) has a plugin
• Miranda NG (Windows) has a plugin
• Mozilla Thunderbird from version 68 with the OTR library
• Pidgin ( platform independent ) has an official plugin
• Psi (platform-independent) has an unofficial plugin, in Psi + this can be used natively (on Linux)
• Vacuum IM (Linux / Windows)
• WeeChat (platform independent) has a plugin
• XChat (platform independent) has a plugin

Proxy

First of all, a proxy was developed that should enable use with the OSCAR protocol (AIM / ICQ), even if the chat client itself does not support OTR. The software has not been further developed since 2005 and the manufacturer advises against its use.

history

OTR was presented by Nikita Borisov, Ian Avrum Goldberg and Eric A. Brewer in 2004 at the “Workshop on Privacy in the Electronic Society” (WPES) as an improvement over the OpenPGP and S / MIME systems. On November 21, 2004 the first version 0.8.0 of the reference implementation was published. In 2005, Mario Di Raimondo, Rosario Gennaro and Hugo Krawczyk presented an analysis that drew attention to several vulnerabilities and suggested corrections to them, including in particular a security gap in the key exchange. As a result, Version 2 of the OTR protocol was published in 2005, which implements a variation of the proposed modification that also hides the public key. In addition, the possibility of fragmenting OTR messages was introduced for chat systems with limited message size and a simpler possibility of checking against middleman attacks without the comparison of key checksums was implemented. Knowledge of any shared secret can be used via the Socialist Millionaires Protocol, for which a relatively low entropy can be tolerated. Version 3 of the protocol was published in 2012. As a measure against the continuous re-establishment of a session with several competing chat clients who are logged on to the same user address at the same time, a more precise identification of the sender and recipient client instance was introduced in version 3. In addition, an additional key is negotiated that can be used for another data channel.

Several systems have been proposed to support multiple callers. A procedure proposed by Jiang Bian, Remzi Seker and Umit Topaloglu in 2007 used a participant's system as a “virtual server”. The “Multi-party Off-the-Record Messaging” (mpOTR) procedure published in 2009 managed without a central organizational instance and was developed by Ian Goldberg et al. Introduced in Cryptocat . In 2013, TextSecure introduced the Axolotl protocol based on OTR messaging and the Silent Circle Instant Messaging Protocol (SCIMP). As a central additional feature, it brought support for asynchronous communication (“offline messages”), as well as better resilience in the event of a disrupted message sequence and simpler support for several call participants. The OMEMO introduced in Conversations in 2015 integrates Axolotl into the instant messaging protocol XMPP (“Jabber”) and now also enables file transfers to be secured. It was submitted to the XMPP Standards Foundation for standardization in autumn 2015 .

Socialist Millionaires' Protocol

The Socialist Millionaires' Protocol (SMP) enables the comparison of the fingerprints of the public keys , which otherwise takes place out of band , to be replaced by a shared secret .

Other areas of application

• Apple iCloud Keychain uses the OTR protocol to transfer user ID and passwords from Apple device to Apple device.

Web links

• Project page (English)
  • Off-the-Record Communication, or, Why Not To Use PGP (PDF; 132 kB) - first publication of the OTR protocol by Nikita Borisov, Ian Goldberg and Eric Brewer (English)
  • Off-the-Record Messaging Protocol version 2 (English)
• - Joseph Bonneau, Andrew Morrison: Finite-State Security Analysis of OTR Version 2 (PDF; 105 kB) Stanford University (English)
• Off-the-Record Messaging: Useful Security and Privacy for IM - Video by Ian Goldberg, one of the developers (English, various formats are available)
• T. Engel: Secure messaging with off-the-record messaging (PDF; 860 kB) - diploma thesis from at the Technical University of Applied Sciences Berlin

Individual evidence

1. ↑ ^{a b} Off-the-Record Messaging Protocol version 2 (English)
2. ↑ Joseph Bonneau, Andrew Morrison: Finite-State Security Analysis of OTR Version 2. (PDF (105 kB)) Stanford University, accessed on July 13, 2011 (English).  
3. ↑ ChatSecure website
4. ↑ IM + on Google Play
5. ↑ github.com
6. ↑ mcabber Changelog, see "mcabber (0.9.4)" (English)
7. ↑ Phonix Viewer , OSS
8. ↑ qutIM 0.3.1 changelog on Facebook
9. ↑ Rocket.Chat Channel Actions , English
10. ↑ SecuXabber in the Google Play Store (English)
11. ↑ Spark changelog
12. ↑ Xabber in the Google Play Store , English
13. ↑ Gajim OTR , English
14. ↑ Irssi OTR , English
15. ↑ Miranda OTR Plugin ( Memento from March 1, 2012 in the Internet Archive ), English
16. ↑ MirOTR, Miranda NG Wiki
17. ↑ thunderbird.net
18. ↑ Thunderbird: OTR - MozillaWiki. May 22, 2019, accessed July 20, 2019 . 
19. ↑ Pidgin OTR Plugin , English
20. ↑ Psi-Patch and OTR-Plugin on tfh-berlin.de ( Memento from March 26th 2009 in the Internet Archive ), English
21. ↑ Website of the Psi development version Psi + , English
22. ↑ Plugin collection for Vacuum IM
23. ↑ weechat-otr , English
24. ↑ Xchat OTR ( Memento of the original from February 27, 2016 in the Internet Archive ) Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice. , English  
25. ↑ Nikita Borisov, Ian Avrum Goldberg, Eric A. Brewer: Off-the-record communication, or, why not to use PGP . In: Association for Computing Machinery (Ed.): WPES '04: Proceedings of the 2004 ACM workshop on Privacy in the electronic society . ACM Press, New York October 2004, pp. 77-84 ( cypherpunks.ca [PDF]).
26. ^ Mario Di Raimondo, Rosario Gennaro, Hugo Krawczyk: Secure off-the-record messaging . In: Association for Computing Machinery (Ed.): Proceedings of the 2005 ACM workshop on Privacy in the electronic society . 2005, p. 81-89 ( unict.it [PDF]).
27. ^ Jiang Bian, Remzi Seker, Umit Topaloglu: Off-the-Record Instant Messaging for Group Conversation . In: IEEE (Ed.): IEEE International Conference on Information Reuse and Integration . 2007 ( online (PDF)). Off-the-Record Instant Messaging for Group Conversation ( Memento of the original from January 4, 2016 in the Internet Archive ) Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice.  
28. ↑ Chris Alexander, Ian Avrum Goldberg: Improved User Authentication in Off-The-Record Messaging . In: Association for Computing Machinery (Ed.): Proceedings of the 2007 ACM workshop on Privacy in electronic society . New York October 2007, p. 41-47 , doi : 10.1145 / 1314333.1314340 ( cypherpunks.ca [PDF]).
29. ↑ otr.cypherpunks.ca
30. ↑ Ian Avrum Goldberg, Berkant Ustaoğlu, Matthew D. Van Gundy, Hao Chen: Multi-party off-the-record messaging . In: Association for Computing Machinery (Ed.): Proceedings of the 16th ACM Computer and Communications Security Conference . 2009, p. 358-368 , doi : 10.1145 / 1653662.1653705 ( cypherpunks.ca [PDF]).
31. ↑ Nik Unger, Sergej Dechand, Joseph Bonneau, Sascha Fahl, Henning Perl, Ian Avrum Goldberg, Matthew Smith: SoK: Secure Messaging . In: IEEE Computer Society's Technical Committee on Security and Privacy (Ed.): Proceedings of the 2015 IEEE Symposium on Security and Privacy . 2015, p. 232-249 ( ieee-security.org [PDF]).
32. ^ Andreas Straub: OMEMO Encryption. (No longer available online.) In: XMPP Standards Foundation website. October 25, 2015, archived from the original on January 29, 2016 ; accessed on January 4, 2016 . Info: The archive link was inserted automatically and has not yet been checked. Please check the original and archive link according to the instructions and then remove this notice.   
33. ↑ Daniel Gultsch: OMEMO Encrypted Jingle File Transfer. In: XMPP Standards Foundation website. September 2, 2015, accessed January 4, 2016 .  
34. ↑ heide.de / ... - iCloud keychain : vulnerability enabled third party access to passwords. August 4, 2017. Retrieved August 5, 2017.