IM + Paranoia Mode On

Greetings to you, harabrachitel!

The latest update of the multi-protocol mobile client IM + brought with it support for the encryption protocol OTR (Off-the-Record). It is noteworthy that the encryption function is available regardless of which IM protocol you use when communicating (OSCAR, Jabber, Gtalk, MSN, YIM, or another).
')
The main properties of this protocol:

• message encryption - no one else can read messages;
• interlocutor authentication - confidence in who the interlocutor is;
• if secret keys are lost, the previous correspondence will not be compromised;

Where does it work?

OTR encryption among desktop clients supports:

• Adium (Mac OS X) has built-in support;
• Climm (Unix) has built-in support;
• Gajim (Microsoft Windows, Linux, FreeBSD) with a plug-in from third-party developers;
• irssi (Unix) with plugin from third party developers;
• Kopete (Unix) with plugin from third party developers;
• Miranda IM (Microsoft Windows) with plugin from third-party developers;
• Pidgin, formerly Gaim, (cross-platform application) with the official plugin;
• Psi + (Microsoft Windows, Linux) with plug-in from third-party developers;
• qutIM (Microsoft Windows, Linux, Mac OS X) with the OTR plugin (libofftherecord), which was written by the qutIM author himself and is available “out of the box”;
• Trillian (Microsoft Windows) with plugin from third party developers;
• Vacuum-IM (Microsoft Windows, Linux, Mac OS X) with the official plugin.

In addition, for the OSCAR protocol, there is a solution in the form of OTR through a proxy (SOCKS5, HTTPS and HTTP connections are supported.)

How it works?

Key exchange

OTR uses the Diffie-Hellman protocol for key exchange. In general, this key exchange scheme was invented in 1976, and became the first practical method for obtaining a shared secret key when communicating via an unprotected communication channel.



When running the algorithm, each side:

1. Generates a random natural number a - private key
2. Together with the remote side, sets open parameters p and g (usually p and g values ​​are generated on one side and transmitted to the other), where:

- p is a random prime
- g is a primitive root modulo p

3. Computes the public key A using the transformation above the private key

A = g ^a mod p

4. Exchange public keys with the remote party
5. Calculates the shared secret key K using the public key of the remote side B and its private key a

K = B ^a mod p

K turns out to be equal on both sides, because:
B ^a mod p = (g ^b mod p) ^a mod p = g ^ab mod p = (g ^a mod p) ^b mod p = A ^b mod p

In practical implementations, for a and b, numbers of the order of ^10,100 and p of the order of ^{10,300 are used} .
The number g does not have to be large and usually matters within the first ten.

Authentication

For digital signatures in OTR, the RSA algorithm is used, because without additional means of authentication, users could not be sure with whom exactly they generated the shared secret key.



Thus, for the sender, the algorithm will be as follows:

• Take plaintext m
• Digitally sign s with your private key { d, n }:

s = Sa (m) = m ^d mod n

• Send the pair { m, s }, consisting of a message and a signature.

For the recipient, the algorithm is the reverse:

• Take a pair { m, s }
• Accept the public key { e, n } from the sender
• Calculate the preimage of the message from the signature:

m '= P _s (s) = s ^e mod e

• Verify the authenticity of the signature (and the immutability of the message) by comparing m and m '

Encryption

The AES block cipher is used for encryption in OTR. This algorithm is well analyzed and is now widely used, being one of the most common symmetric encryption algorithms. Created in 1998, and published in 2001, it can now be found everywhere. For example, AES support was introduced by Intel into the x86 family of processors starting with the Intel Core i7-980X Extreme Edition, and now also on Sandy Bridge processors.

Considering its popularity, publications devoted to ways to find the key regularly appear on the network, but despite this, 128-bit AES encryption is still fairly reliable.

Hashing

SHA1 (Secure Hash Algorithm 1), developed back in 1995, is used as a hashing algorithm in OTR. For an input message of arbitrary length, the algorithm generates a 160-bit hash value, also called a message digest.

Theoretically, SHA-1 is considered to be hacked (the number of computational operations has been reduced by 2 ^80-63 = 131 000 times), in practice such hacking is hardly possible, as it will take many years. However, this time can be drastically reduced provided that distributed computing and GPU computing are used. The search for alternatives to the existing SHA-1 and SHA-2 is already underway (the future standard will have the “unexpected” name SHA-3).

SHA-1 in OTR is used to implement the HMAC function (hash-based message authentication code, i.e., message identification hash code). When using HMAC, the resulting authentication code ensures that the data has not been changed in any way since it was created, transmitted, or stored by a trusted source.

For this kind of verification, it is necessary that, for example, two parties trusting each other agree in advance on the use of a secret key that is known only to them. This ensures the authenticity of the source and the message. The disadvantage of this approach is obvious - you must have two parties trusting each other.

Millionaire Socialist Protocol

The Socialist Millionaire Protocol (SMP) is used in OTR to authenticate the other party, knowing some kind of shared secret. This protocol allows you to make sure that the participants know some general information (password, the answer to a question known only to them) without disclosing it directly, without exchanging any of its fingerprints that can be used to the detriment of the person in the middle.



Man in the middle, MITM-attack - a situation where an outsider (attacker) is able to read and modify at will the messages that correspondents exchange, and none of the latter can guess about his presence in the channel.

OTR uses SMP to compare not the “wealth” of millionaires, but to compare the information of two participants. More specifically, two session identifiers, fingerprints of the participants' public keys and the “secret” itself are compared.

What does this look like?

When talking through any protocol, for example Gtalk, to start a secure OTR conversation, simply click on the open lock icon:



If the client of the interlocutor does not support OTR, the interlocutor will receive the following message:

? OTR? V2?
% name of the interlocutor% has requested an off-the-record private conversation. However, you don’t have a plugin to support that.
See otr.cypherpunks.ca for more information.

Mysterious message header? OTR? V2? suggests the required version of the protocol OTR - v2.
In case the interlocutor uses IM + (or another client with OTR support), you will be prompted to start an encrypted communication session.

After sharing the “shared secret” - secret information that is known only to both interlocutors (it is obvious that it should be negotiated via another communication channel - a personal meeting, a phone call, postal pigeons), an OTR communication session will be started. Message history during an OTR session is not saved.

What else can I add? The OTR function in IM + clients for Android and iOS can be activated directly from the application, through the In-App Purchase system, the “security price” - $ 5, one-time.

I have not yet met other mobile clients with OTR support, if there are any, share information in the comments. Thanks for attention :)

UPD1: The latest version of qutIM for Maemo also has support for OTR. To do this, you need to put the qutim and qutim-extra-plugins packages from the Extras-devel repository.

UPD2: xabber for Android also supports OTR encryption.

UPD3: More information can be found on Wikipedia and on the official OTR page .