- Joined
- May 15, 2016
- Messages
- 14,019
- Likes
- 2,643
- Points
- 1,730
End-to-end encryption, or end-to-end encryption (E2EE), is considered a panacea for persistent attempts by hackers and security agencies to get acquainted with online correspondence. The meaning of E2EE often comes down to the fact that keys are stored only on interlocutors' devices and do not get on the server ... but this is not quite so. Let's see how things really are with E2EE, using the example of popular instant messengers.
Encryption in messengers
Write this article I pushed research Obstacles to the Adoption of Secure Communication Tools ( PDF ). As the authors found out, “the overwhelming majority of survey participants do not understand the basic concept of end-to-end encryption.” Simply put, people usually choose an instant messenger with a heart, not a brain.
To begin with, E2EE has its own characteristics in each messenger. In Signal, it is almost exemplary. WhatsApp is formally the same as Signal, except for one very important point: changing the subscriber’s primary key WhatsApp does not block sending messages to it. At most, you can enable useless notification (which is disabled in the default settings). In Viber, pass-through encryption is inactive by default, and it appeared only in the sixth version. In Telegram E2EE also used only in secret chats, and they are implemented quite strange.
The conflict between Roskomnadzor and Telegram in general has created an excellent advertisement for the latter. Ordinary users now consider the creation of Durov to be a real pain in the back of the special services (or a little lower than it), which can do nothing with a bullet-proof innovative service. Telegram fans compare it with Signal and claim superiority of the first.
However, in cryptography there are no miracles, and especially - in applied. Many mathematically beautiful ideas turn out to be hopelessly spoiled by implementation, when convenience and controllability put it above safety and privacy (and this happens almost always).
Initially, the messengers used the OTR (Off-the-Record) protocol. It uses AES symmetric encryption in CTR mode, the key exchange protocol DH and the SHA-1 hash function. The AES-CTR scheme provides the so-called “controversial” (in a good sense) encryption and the possibility of denying the authorship of the text if it is intercepted. You can always refer to the fact that the intercepted traffic itself has changed the ciphertext so that it corresponds to another variant of decryption of the same length. For example, instead of “go for the bread,” it turned out to “poison the queen” - technically it is possible, and this property is specifically incorporated into the algorithm.
The OTR protocol authenticates the interlocutors and encrypts the correspondence between them. It is safe as long as participants in the conversation regularly check each other’s public key prints and resist attacks against other vectors (including social engineering).
The main disadvantage of OTR is that after sending a new key, you must wait for confirmation from the interlocutor. If it is offline, the connection will be temporarily unavailable. One way out was the Double Ratchet (DR) algorithm, developed five years ago by Trevor Perrin and Moxy Marlinspike in Open Whisper Systems. Today, DR is used in Signal, WhatsApp, Viber and many other instant messengers that support end-to-end encryption by default or as a separate option (secret chats).
A simplified scheme of the algorithm Double Ratchet (source: signal.org). Alice and Bob begin the session by exchanging public keys.
End-to-End Encryption
The E2EE scheme uses a combination of public-key and private-key cryptographic systems. It is obvious in general terms and quite complex at the level of detail. It uses a mass of interrelated keys, some of which must be sent to the server and, moreover, must be loaded onto it before the start of the correspondence, so that it can be started at an arbitrary moment. Let's take a closer look at it.
You probably know the beginning of the scheme, since it is standard for all asymmetric encryption systems - a pair of keys is generated. This is necessary because cryptosystems with one key (like AES) are too difficult to use in pure correspondence. They would have to somehow organize a secure channel to transfer the key (for example, to meet in person), and then do it again with each change of it.
Immediately, everything is as usual in PGP: there are two interlocutors (Alice and Bob), each of which generates its own pair of keys. Then they exchange public keys, keeping their secret secrets secret. Public keys are transmitted over an open channel (for that they are public, let them intercept them for health) and serve two purposes: they allow you to encrypt a message and verify its signature. Accordingly, secret keys are used to decrypt and generate a signature.
Such a cryptosystem somehow works in e-mail, since it is a service for delivering individual encrypted messages of arbitrary length. Using it, the interlocutors do not have to be online at the same time. All messages are accumulated on the server and downloaded from it on demand after the user successfully passes authorization. Decryption occurs locally using secret keys that are not transmitted anywhere. PGP mail is popular, but works far from perfect.
Unfortunately, the pure asymmetric encryption scheme is also not suitable for instant messengers, since these services are focused on intensive online correspondence in the form of a chain of short messages. They must be displayed in a strictly defined order, and the interlocutor may at any time be offline and disrupt the structure of the dialogue.
Also, encrypting multiple short messages with one key is a bad idea. In total for the day of their correspondence hundreds are created (if not thousands). In many messages, the number of ciphertext is minimal and predictable (emoticon, sticker). They also have standard headers that simplify cryptanalysis.
The peculiarity of the correspondence in messengers is that, due to typical metadata, an attacker can intercept a large amount of predictable ciphertext in a short time. His lion's share will correspond to the known clear text. If it is encrypted with one key, then if the attack is successful, all previously written messages will be compromised, and even those that the interlocutors will write in the future.
To prevent this from happening, the messengers provide such properties as direct and reverse secrecy. They imply the impossibility of reading the messages sent earlier and written in the future, having only the current encryption key. To do this, multilayer encryption is used with the transition from asymmetric to symmetric cryptography and additional keys with different lifetime.
Diffie Hellman! Give three!
From open documentationIn Telegram, it is known that authenticated key distribution provides the classic Diffie-Hellman (DH) protocol. It creates a bridge between asymmetric (RSA) and symmetric (AES) encryption, enabling a certain number of interlocutors to conduct encrypted correspondence, transferring only public keys via an open channel. To do this, it generates session keys, which are a shared secret or a common ephemeral key. It is calculated on the basis of the secret key of one interlocutor and the public key of another. Ephemeral keys are authenticated by long-term public keys.
Therefore, for its Signal messenger, Open Whisper Systems uses the Diffie-Hellman triple transformation method X3DH with Curve25519 (Bernstein elliptic curve for fast DH) orX448 . The X3DH uses HMAC-SHA-256 and AES-256 as other cryptographic primitives.
Protocol Extended Triple Diffie - Hellman establishes a shared secret key between two parties that mutually authenticate each other based on public keys. Additionally, the keys are checked immediately after the session is installed and before the start of message transfer. This minimizes the risk of MITM attacks, making them very difficult.
X3DH uses four types of keys, three of which are constantly changing:
Auxiliary keys are changed in X3DH using the Double Ratchet algorithm. He replaced OTR and introduced the concept of a chain, or a pool, of keys. In case the interlocutor is offline, the creation of an OPK pool is provided. Several one-time ephemeral keys are preloaded to the server and consumed as they communicate. This allows the server to receive encrypted messages, authenticating their sender with a new key pair, even when the recipient is not online. If the OPK pool is exhausted, the server uses a spare EK.
The name “double ratchet” is a reference to the device of the Enigma encryption machine with gear wheels, which eliminated the reverse movement and reuse of previous values. The digital analogy is that DR is used to generate new ephemeral keys that encrypt the next message (or a small portion of messages). At the same time, the ephemeral keys are guaranteed to differ, they do not repeat the previous ones and cannot be predicted in a reasonable attack time.
X3DH is based on the TextSecure protocol, which was later renamed Signal. In pure or slightly modified form, the Signal protocol is used in the same messenger, as well as in WhatsApp, Viber and others. Developers can give protocols their own names, but in fact it is all the same X3DH with a varying set of hash functions, PRNG and other cryptographic primitives.
The problem of group chats.
organization of group chats in instant messengers is discussed in detail in the recent article “WhatsApp, and Threema” ( PDF ). I will give the main conclusions from it.
Our systematic analysis revealed that the integrity of communications (represented by the integrity of all messages) and group membership (determined by the ability of members to manage them) do not have end-to-end protection. In addition, we have shown that reverse secrecy (a key security feature) is not preserved when using the Signal protocol for group chats.
Explanation: The cornerstone of end-to-end encryption is authenticated key distribution using the classic or enhanced DH protocol. It only works for two interlocutors who form a shared secret. It is expected that DH messengers are not used in group chats, and the messaging structure in them is devoid of basic cryptographic properties.
Encryption in group chats. A - the sender, B - the recipient, G - a group of users
The authors show what manipulations can be performed by an attacker controlled server in group chats due to the lack of E2EE in them. They conducted their research on the example of Signal and WhatsApp, but one can hardly expect that this problem has some elegant solution for other messengers.
The weirdness of a telegram
With a telegram, everything is covered with a veil of secrecy. There is only partial information about the MTProto 2.0 protocol. His external audit was not performed, and the open source Telegram model is used in a highly distorted form and exclusively for marketing purposes. Below I will explain why I think so.
Judging by the official description, all undelivered messages are temporarily (we hope) stored on Telegram servers, which are often scattered around the world and combined into a virtual cloud. They are synchronized with each other in order to organize and deliver messages to one or several (in the case of group chat) interlocutors in a specific order as soon as they appear on the network. Therefore, encryption is divided into two stages: in areas of client - server and server - server. This is a common scheme, but it is strange that the direct connection of clients is never used at all.
In Telegram, traffic is transmitted through servers even when opening a secret chat, for which it would be more logical to make a P2P connection. The conclusion is that without permanent use of Telegram servers, the connection in this messenger does not work at all. Other messengers can use their servers only at the initial stage - to compare the current IP addresses of the interlocutors and organize a direct connection between them. Telegram does not know how, and it is damn similar to MITM by design.
For some reason, all the arguments about the resilience of MTProto 2.0 revolve around the fact that the DH algorithm reliably protects against interception. This is not true. The Diffie - Hellman algorithm is just vulnerable to the MITM attack. Moreover, in the case of a Telegram, it is likely to be further weakened at the level of the PRNG.
The problem is that the Telegram client application is guided by a very vague estimate of entropy. Instead of locally generating pseudo-random numbers and sifting out qualitative simple ones, the client requests them from the server. What the PRNG is used on the server, how successful it is, the simple numbers it generates, and whether there are mechanisms on the server for selectively sending prime numbers with certain properties to individual clients — unanswered questions. The client application only performs a check of the random number sent, and it is simplified, since for a thorough test of prime numbers, the smartphone simply does not have enough computing resources for a reasonable time.
Another common argument in favor of Telegram security is open source. However, they do not have the source code of the server part, and the client code is usually irrelevant. Telegram repositories are updated with a long delay (unless the trimmed web version is more or less lively), and only the old versions are always in them. It is not even possible to check whether the source code actually compiles what is being distributed as a ready-made distribution kit.
Therefore, talking about the audit of the messenger is actually meaningless. While experts are digging in the old code for several months, a dozen new versions of Telegram will be released, where huge chunks of code will be rewritten. To make the entire encryption system vulnerable, it is enough to replace one byte — for example, one conditional transition.
The hackathons that Durov arranges will not replace the audit, since they prove nothing. In their tasks, an artificial situation is created in which the attacking side has only one encrypted message. In real life, there are no such restrictions and there are many other vectors for attacking the messenger.
One thousand and one vulnerability
Signal is one of the few instant messengers whose protocol was subject to external audit ( PDF ). The report on its results is very voluminous, so I will quote the main conclusions in my translation.
Our analysis shows that the [protocol] Signal satisfies standard cryptographic assumptions and security properties. We found no serious flaws in its design, which is very encouraging. With real use of Signal, uncertainties remain. Therefore, it is impossible to say whether [the app] Signal always achieves the stated goals.
It is necessary to realize that the analysis of the message transfer protocol is an important stage of the audit, but not the only component of security. Any messenger works in a real and very vulnerable environment. Usually it runs on the latest version of Android, in parallel with hundreds of left-wing applications (some of which probably misuse permissions or even contain Trojan bookmarks), and the account itself is tied to a mobile phone number.
The huge gap is that the confirmation codes come in SMS. They can be intercepted through a known vulnerability in the SS7 cellular communication protocol. So the attacker will get access to all the correspondence without knowing the encryption keys and not even trying to hack Signal / Proteus / MTProto (or another security protocol). The messenger server will change the key itself and helpfully decrypt the last correspondence (at least, undelivered messages). Even your stickpacks will recover. The main thing is convenience, right?
Another gap in the security model is push notifications. Without them, you will not know that a message has come to you, until you manually launch the messenger. With them, you turn the server push-notifications into a legalized "man in the middle." For example, in order for iMessage to work notifications, it sends encryption keys to Apple servers. Already they authenticate users and (at a minimum) decrypt message headers. Restore Apple's account on another device, and you will get everything as it was - right up to the correspondence and Wi-Fi passwords. Almost the same situation with the servers of Google and Microsoft. Or do you still believe in end-to-end encryption with reference to the mobile number and main account on your smartphone?
The problem of unsafe key management and a large attack surface generally affects all instant messengers. WhatsApp, Viber and many others allow you to create copies of the correspondence (including the cloud) and do not encrypt the metadata (and sometimes the fact of the conversation is more important than its content). Signal is a little better, but I don’t consider it an ideal messenger for a number of reasons:
As you can see, XMPP is difficult to trust third-party and even more proprietary messengers, even if they were recommended by Snowden, Assange and EFF. Therefore, some organize communication through their messenger - with open-source and plug-ins. For simple correspondence, the OTR plugin is suitable, but it does not support group chat. There are related protocols mpOTR and GOTR in which this function is added.
Anyway, for collective communication it is more convenient to use the open protocol XMPP (Extensible Messaging and Presence Protocol), which was previously called Jabber. XMPP translates as "extensible messaging and presence information," this is a very capacious name. Openness means full availability of source codes. You can raise your XMPP server, do not depend on anyone and do not pay anything for it. There are also a lot of ready-made servers and clients for every taste - for example, desktop Pidgin and Xabber for Android.
Extensibility implies the ability to transfer not only text, but also data of another type, as well as the addition of various functions and encryption schemes. For example, using XMPP, it is easy to transfer voice messages, videos and files, if desired, by encrypting them with TLS or PGP. Not so long ago , the OMEMO extension protocol was created based on XMPP , which uses the same DR from Open Whisper Systems as Signal and WhatsApp, but without the other shortcomings of the latter.
Findings
In modern messengers, support for end-to-end encryption is claimed, but it often turns out that it is implemented with strange features. In addition, there are many other holes in their code that were left by chance or intentionally. The latter is much more likely if you consider how much money and the labor of professionals have been invested in their development. I try to keep a balance between comfort and the usual pleasure of paranoia. I use different instant messengers (which is more convenient for my interlocutors), but I never lead private conversations through them. There are many open source alternatives for this. In addition to Xabber, I would recommend Android users to look at Conversations , a free XMPP client with support for OTR, OMEMO, openPGP and SOCKS5.
Encryption in messengers
Write this article I pushed research Obstacles to the Adoption of Secure Communication Tools ( PDF ). As the authors found out, “the overwhelming majority of survey participants do not understand the basic concept of end-to-end encryption.” Simply put, people usually choose an instant messenger with a heart, not a brain.
To begin with, E2EE has its own characteristics in each messenger. In Signal, it is almost exemplary. WhatsApp is formally the same as Signal, except for one very important point: changing the subscriber’s primary key WhatsApp does not block sending messages to it. At most, you can enable useless notification (which is disabled in the default settings). In Viber, pass-through encryption is inactive by default, and it appeared only in the sixth version. In Telegram E2EE also used only in secret chats, and they are implemented quite strange.
The conflict between Roskomnadzor and Telegram in general has created an excellent advertisement for the latter. Ordinary users now consider the creation of Durov to be a real pain in the back of the special services (or a little lower than it), which can do nothing with a bullet-proof innovative service. Telegram fans compare it with Signal and claim superiority of the first.
However, in cryptography there are no miracles, and especially - in applied. Many mathematically beautiful ideas turn out to be hopelessly spoiled by implementation, when convenience and controllability put it above safety and privacy (and this happens almost always).
Initially, the messengers used the OTR (Off-the-Record) protocol. It uses AES symmetric encryption in CTR mode, the key exchange protocol DH and the SHA-1 hash function. The AES-CTR scheme provides the so-called “controversial” (in a good sense) encryption and the possibility of denying the authorship of the text if it is intercepted. You can always refer to the fact that the intercepted traffic itself has changed the ciphertext so that it corresponds to another variant of decryption of the same length. For example, instead of “go for the bread,” it turned out to “poison the queen” - technically it is possible, and this property is specifically incorporated into the algorithm.
The OTR protocol authenticates the interlocutors and encrypts the correspondence between them. It is safe as long as participants in the conversation regularly check each other’s public key prints and resist attacks against other vectors (including social engineering).
The main disadvantage of OTR is that after sending a new key, you must wait for confirmation from the interlocutor. If it is offline, the connection will be temporarily unavailable. One way out was the Double Ratchet (DR) algorithm, developed five years ago by Trevor Perrin and Moxy Marlinspike in Open Whisper Systems. Today, DR is used in Signal, WhatsApp, Viber and many other instant messengers that support end-to-end encryption by default or as a separate option (secret chats).
A simplified scheme of the algorithm Double Ratchet (source: signal.org). Alice and Bob begin the session by exchanging public keys.
End-to-End Encryption
The E2EE scheme uses a combination of public-key and private-key cryptographic systems. It is obvious in general terms and quite complex at the level of detail. It uses a mass of interrelated keys, some of which must be sent to the server and, moreover, must be loaded onto it before the start of the correspondence, so that it can be started at an arbitrary moment. Let's take a closer look at it.
You probably know the beginning of the scheme, since it is standard for all asymmetric encryption systems - a pair of keys is generated. This is necessary because cryptosystems with one key (like AES) are too difficult to use in pure correspondence. They would have to somehow organize a secure channel to transfer the key (for example, to meet in person), and then do it again with each change of it.
Immediately, everything is as usual in PGP: there are two interlocutors (Alice and Bob), each of which generates its own pair of keys. Then they exchange public keys, keeping their secret secrets secret. Public keys are transmitted over an open channel (for that they are public, let them intercept them for health) and serve two purposes: they allow you to encrypt a message and verify its signature. Accordingly, secret keys are used to decrypt and generate a signature.
Such a cryptosystem somehow works in e-mail, since it is a service for delivering individual encrypted messages of arbitrary length. Using it, the interlocutors do not have to be online at the same time. All messages are accumulated on the server and downloaded from it on demand after the user successfully passes authorization. Decryption occurs locally using secret keys that are not transmitted anywhere. PGP mail is popular, but works far from perfect.
Unfortunately, the pure asymmetric encryption scheme is also not suitable for instant messengers, since these services are focused on intensive online correspondence in the form of a chain of short messages. They must be displayed in a strictly defined order, and the interlocutor may at any time be offline and disrupt the structure of the dialogue.
Also, encrypting multiple short messages with one key is a bad idea. In total for the day of their correspondence hundreds are created (if not thousands). In many messages, the number of ciphertext is minimal and predictable (emoticon, sticker). They also have standard headers that simplify cryptanalysis.
The peculiarity of the correspondence in messengers is that, due to typical metadata, an attacker can intercept a large amount of predictable ciphertext in a short time. His lion's share will correspond to the known clear text. If it is encrypted with one key, then if the attack is successful, all previously written messages will be compromised, and even those that the interlocutors will write in the future.
To prevent this from happening, the messengers provide such properties as direct and reverse secrecy. They imply the impossibility of reading the messages sent earlier and written in the future, having only the current encryption key. To do this, multilayer encryption is used with the transition from asymmetric to symmetric cryptography and additional keys with different lifetime.
Diffie Hellman! Give three!
From open documentationIn Telegram, it is known that authenticated key distribution provides the classic Diffie-Hellman (DH) protocol. It creates a bridge between asymmetric (RSA) and symmetric (AES) encryption, enabling a certain number of interlocutors to conduct encrypted correspondence, transferring only public keys via an open channel. To do this, it generates session keys, which are a shared secret or a common ephemeral key. It is calculated on the basis of the secret key of one interlocutor and the public key of another. Ephemeral keys are authenticated by long-term public keys.
Therefore, for its Signal messenger, Open Whisper Systems uses the Diffie-Hellman triple transformation method X3DH with Curve25519 (Bernstein elliptic curve for fast DH) orX448 . The X3DH uses HMAC-SHA-256 and AES-256 as other cryptographic primitives.
Protocol Extended Triple Diffie - Hellman establishes a shared secret key between two parties that mutually authenticate each other based on public keys. Additionally, the keys are checked immediately after the session is installed and before the start of message transfer. This minimizes the risk of MITM attacks, making them very difficult.
X3DH uses four types of keys, three of which are constantly changing:
- IK (identity keys). Secret keys that are created once and serve as the basis for the formation of all the others;
- EK (ephemeral key). Ephemeral key, which is needed to verify the identity of the interlocutor (without disclosing the true);
- SPk (signed public key, signed proof of knowledge) - in fact, it is an ephemeral key, signed by a secret one. Usually in messengers it changes with frequency from one day to a week. Sometimes, instead of the SPk lifetime, the number of messages is set, after which it changes;
- OPK (one-time public key) - one-time ephemeral key. It is created by the sender before establishing a communication session and is deleted immediately after a successful “handshake” (handshake).
Auxiliary keys are changed in X3DH using the Double Ratchet algorithm. He replaced OTR and introduced the concept of a chain, or a pool, of keys. In case the interlocutor is offline, the creation of an OPK pool is provided. Several one-time ephemeral keys are preloaded to the server and consumed as they communicate. This allows the server to receive encrypted messages, authenticating their sender with a new key pair, even when the recipient is not online. If the OPK pool is exhausted, the server uses a spare EK.
The name “double ratchet” is a reference to the device of the Enigma encryption machine with gear wheels, which eliminated the reverse movement and reuse of previous values. The digital analogy is that DR is used to generate new ephemeral keys that encrypt the next message (or a small portion of messages). At the same time, the ephemeral keys are guaranteed to differ, they do not repeat the previous ones and cannot be predicted in a reasonable attack time.
X3DH is based on the TextSecure protocol, which was later renamed Signal. In pure or slightly modified form, the Signal protocol is used in the same messenger, as well as in WhatsApp, Viber and others. Developers can give protocols their own names, but in fact it is all the same X3DH with a varying set of hash functions, PRNG and other cryptographic primitives.
The problem of group chats.
organization of group chats in instant messengers is discussed in detail in the recent article “WhatsApp, and Threema” ( PDF ). I will give the main conclusions from it.
Our systematic analysis revealed that the integrity of communications (represented by the integrity of all messages) and group membership (determined by the ability of members to manage them) do not have end-to-end protection. In addition, we have shown that reverse secrecy (a key security feature) is not preserved when using the Signal protocol for group chats.
Explanation: The cornerstone of end-to-end encryption is authenticated key distribution using the classic or enhanced DH protocol. It only works for two interlocutors who form a shared secret. It is expected that DH messengers are not used in group chats, and the messaging structure in them is devoid of basic cryptographic properties.
Encryption in group chats. A - the sender, B - the recipient, G - a group of users
The authors show what manipulations can be performed by an attacker controlled server in group chats due to the lack of E2EE in them. They conducted their research on the example of Signal and WhatsApp, but one can hardly expect that this problem has some elegant solution for other messengers.
The weirdness of a telegram
With a telegram, everything is covered with a veil of secrecy. There is only partial information about the MTProto 2.0 protocol. His external audit was not performed, and the open source Telegram model is used in a highly distorted form and exclusively for marketing purposes. Below I will explain why I think so.
Judging by the official description, all undelivered messages are temporarily (we hope) stored on Telegram servers, which are often scattered around the world and combined into a virtual cloud. They are synchronized with each other in order to organize and deliver messages to one or several (in the case of group chat) interlocutors in a specific order as soon as they appear on the network. Therefore, encryption is divided into two stages: in areas of client - server and server - server. This is a common scheme, but it is strange that the direct connection of clients is never used at all.
In Telegram, traffic is transmitted through servers even when opening a secret chat, for which it would be more logical to make a P2P connection. The conclusion is that without permanent use of Telegram servers, the connection in this messenger does not work at all. Other messengers can use their servers only at the initial stage - to compare the current IP addresses of the interlocutors and organize a direct connection between them. Telegram does not know how, and it is damn similar to MITM by design.
For some reason, all the arguments about the resilience of MTProto 2.0 revolve around the fact that the DH algorithm reliably protects against interception. This is not true. The Diffie - Hellman algorithm is just vulnerable to the MITM attack. Moreover, in the case of a Telegram, it is likely to be further weakened at the level of the PRNG.
The problem is that the Telegram client application is guided by a very vague estimate of entropy. Instead of locally generating pseudo-random numbers and sifting out qualitative simple ones, the client requests them from the server. What the PRNG is used on the server, how successful it is, the simple numbers it generates, and whether there are mechanisms on the server for selectively sending prime numbers with certain properties to individual clients — unanswered questions. The client application only performs a check of the random number sent, and it is simplified, since for a thorough test of prime numbers, the smartphone simply does not have enough computing resources for a reasonable time.
Another common argument in favor of Telegram security is open source. However, they do not have the source code of the server part, and the client code is usually irrelevant. Telegram repositories are updated with a long delay (unless the trimmed web version is more or less lively), and only the old versions are always in them. It is not even possible to check whether the source code actually compiles what is being distributed as a ready-made distribution kit.
Therefore, talking about the audit of the messenger is actually meaningless. While experts are digging in the old code for several months, a dozen new versions of Telegram will be released, where huge chunks of code will be rewritten. To make the entire encryption system vulnerable, it is enough to replace one byte — for example, one conditional transition.
The hackathons that Durov arranges will not replace the audit, since they prove nothing. In their tasks, an artificial situation is created in which the attacking side has only one encrypted message. In real life, there are no such restrictions and there are many other vectors for attacking the messenger.
One thousand and one vulnerability
Signal is one of the few instant messengers whose protocol was subject to external audit ( PDF ). The report on its results is very voluminous, so I will quote the main conclusions in my translation.
Our analysis shows that the [protocol] Signal satisfies standard cryptographic assumptions and security properties. We found no serious flaws in its design, which is very encouraging. With real use of Signal, uncertainties remain. Therefore, it is impossible to say whether [the app] Signal always achieves the stated goals.
It is necessary to realize that the analysis of the message transfer protocol is an important stage of the audit, but not the only component of security. Any messenger works in a real and very vulnerable environment. Usually it runs on the latest version of Android, in parallel with hundreds of left-wing applications (some of which probably misuse permissions or even contain Trojan bookmarks), and the account itself is tied to a mobile phone number.
The huge gap is that the confirmation codes come in SMS. They can be intercepted through a known vulnerability in the SS7 cellular communication protocol. So the attacker will get access to all the correspondence without knowing the encryption keys and not even trying to hack Signal / Proteus / MTProto (or another security protocol). The messenger server will change the key itself and helpfully decrypt the last correspondence (at least, undelivered messages). Even your stickpacks will recover. The main thing is convenience, right?
Another gap in the security model is push notifications. Without them, you will not know that a message has come to you, until you manually launch the messenger. With them, you turn the server push-notifications into a legalized "man in the middle." For example, in order for iMessage to work notifications, it sends encryption keys to Apple servers. Already they authenticate users and (at a minimum) decrypt message headers. Restore Apple's account on another device, and you will get everything as it was - right up to the correspondence and Wi-Fi passwords. Almost the same situation with the servers of Google and Microsoft. Or do you still believe in end-to-end encryption with reference to the mobile number and main account on your smartphone?
The problem of unsafe key management and a large attack surface generally affects all instant messengers. WhatsApp, Viber and many others allow you to create copies of the correspondence (including the cloud) and do not encrypt the metadata (and sometimes the fact of the conversation is more important than its content). Signal is a little better, but I don’t consider it an ideal messenger for a number of reasons:
- First, Signal also uses Google's push notification service. Therefore, on a smartphone without Google services (for example, all Chinese models for the domestic market without GApps), it simply does not work.
- Secondly, for voice communication, Signal uses a private RedPhone server.
- Thirdly, Signal (like many other messengers) allows you to open a parallel session on another device, simply by scanning a QR code.
- Fourth, at HITBSecConf2017 they told ( PDF ) about a number of Signal's conceptual problems and demonstrated a successful attack on it.
As you can see, XMPP is difficult to trust third-party and even more proprietary messengers, even if they were recommended by Snowden, Assange and EFF. Therefore, some organize communication through their messenger - with open-source and plug-ins. For simple correspondence, the OTR plugin is suitable, but it does not support group chat. There are related protocols mpOTR and GOTR in which this function is added.
Anyway, for collective communication it is more convenient to use the open protocol XMPP (Extensible Messaging and Presence Protocol), which was previously called Jabber. XMPP translates as "extensible messaging and presence information," this is a very capacious name. Openness means full availability of source codes. You can raise your XMPP server, do not depend on anyone and do not pay anything for it. There are also a lot of ready-made servers and clients for every taste - for example, desktop Pidgin and Xabber for Android.
Extensibility implies the ability to transfer not only text, but also data of another type, as well as the addition of various functions and encryption schemes. For example, using XMPP, it is easy to transfer voice messages, videos and files, if desired, by encrypting them with TLS or PGP. Not so long ago , the OMEMO extension protocol was created based on XMPP , which uses the same DR from Open Whisper Systems as Signal and WhatsApp, but without the other shortcomings of the latter.
Findings
In modern messengers, support for end-to-end encryption is claimed, but it often turns out that it is implemented with strange features. In addition, there are many other holes in their code that were left by chance or intentionally. The latter is much more likely if you consider how much money and the labor of professionals have been invested in their development. I try to keep a balance between comfort and the usual pleasure of paranoia. I use different instant messengers (which is more convenient for my interlocutors), but I never lead private conversations through them. There are many open source alternatives for this. In addition to Xabber, I would recommend Android users to look at Conversations , a free XMPP client with support for OTR, OMEMO, openPGP and SOCKS5.