FAQ for the Technically Inclined

This FAQ about MTProto is intended for advanced users. You may also want to check out our Basic FAQ.
Please note, that client developers are required to comply with the Security Guidelines.

General

Protection against known attacks

Encryption

Authentication


General questions

Q: Why did you go for a custom protocol?

In order to achieve reliability on weak mobile connections as well as speed when dealing with large files (such as photos, large videos and documents up to 1Gb), MTProto uses an original approach. This document is intended to clarify certain details of our setup, as well as address some points that are difficult to understand at first glance.

Q: Where can I read more about the protocol?

Detailed protocol documentation is available here. If you have comments, hit us up on Twitter.

MTProto encryption

Note 1: Each plaintext message to be encrypted in MTProto always contains the following data to be checked upon decryption in order to make the system robust against known problems with the components:

  • server salt (64-Bit)
  • session id
  • message sequence number
  • message length
  • time

Note 2: See additional comments on our use of IGE, SHA-1 and modified encrypt-and-mac.

Q: Why are you not using X? (insert solution)

While other ways of achieving the same cryptographic goals, undoubtedly, exist, we feel that the present solution is both robust and also sucсeeds at our secondary task of beating unencrypted messengers in terms of delivery time and stability.

Q: Why are you mostly relying on classical crypto algorithms?

We prefer to use well-known algorithms, created in the days when bandwidth and processing power were both a much rarer commodity. This has valuable side-effects for modern-day mobile development, provided one takes care of the known drawbacks.

The weakspots of such algorithms are also well-known, and have been exploited for decades. We use these algorithms in such a combination that, to our best knowledge, prevents any known attack from possibly succeeding. Although we’d be grateful to see any evidence of the contrary (so far absent) and update our system accordingly.

Q: I'm a security expert and I think your protocol is not secure.

You are welcome to join in our competition — Pavel Durov is offering $200,000 in BTC to the first person to break MTProto. Check out the announcement and Contest FAQ.

If you have other comments, we would be happy to hear them at security@telegram.org.

Protection against known attacks

Known-Plaintext Attacks

By definition, the known-plaintext attack (KPA) is an attack model for cryptanalysis where the attacker has samples of both the plaintext, and its encrypted version (ciphertext).

AES IGE that is used in MTProto is robust against KPA attacks (see this, if you wonder how one can securely use IGE). On top of that, the plaintext in MTProto always contains server_salt and session id.

Chosen-Plaintext Attacks

By definition, a chosen-plaintext attack (CPA) is an attack model for cryptanalysis which presumes that the attacker has the capability to choose arbitrary plaintexts to be encrypted and obtain the corresponding ciphertexts.

MTProto uses AES in IGE mode (see this, if you wonder how one can securely use IGE) that is secure against non-adaptive CPAs. IGE is known to be not secure against blockwise-adaptive CPA, but MTProto fixes this in the following manner:

Each plaintext message to be encrypted always contains the following to be checked upon decryption:

  • server salt (64-Bit)
  • message sequence number
  • time

On top of this, in order to replace the plaintext, you would also need to use the right AES key and iv, both dependant on the auth_key. This makes MTProto robust against a CPA.

Chosen-Ciphertext Attacks

By definition, a chosen-ciphertext attack (CCA) is an attack model for cryptanalysis in which the cryptanalyst gathers information, at least in part, by choosing a ciphertext and obtaining its decryption under an unknown key. In the attack, an adversary has a chance to enter one or more known ciphertexts into the system and obtain the resulting plaintexts. From these pieces of information the adversary can attempt to recover the hidden secret key used for decryption.

Each time a message is decrypted in MTProto, a check is performed to see whether the msg_key is equal to the SHA-1 of the decrypted data. The plaintext (decrypted data) also always contains message length, server salt and sequence number. This negates known CCAs.

Replay attacks

Replay attacks are denied because each plaintext to be encrypted contains the server salt and the unique message id and sequence number.

Man-in-the-middle attacks

Telegram has two modes of communication — ordinary chats using client-server encryption and Secret Chats using end-to-end encryption that are protected against MITM attacks.

Client-Server communication is protected from MiTM-attacks during DH key generation by means of a server RSA public key embedded into client software. After that, if both clients trust the server software, the Secret Chats between them are protected by the server from MiTM attacks.

The interface offers a way of comparing Secret Chat keys for users who do not trust the server. Visualizations of the key are presented in the form of identicons (example here). By comparing key visualizations users can make sure no MITM attack had taken place.

Encryption

Q: Do you use IGE? IGE is broken!

Yes, we use IGE, but it is not broken in our implementation. The fact that we do not use IGE as MAC together with other properties of our system makes the known attacks on IGE irrelevant.

IGE, just as the ubiquitous CBC, is vulnerable to blockwise-adaptive CPA. But adaptive attacks are only a threat for as long as the same key can be used in several messages (not so in MTProto).

Adaptive attacks are even theoretically impossible in MTProto, because in order to be encrypted the message must be fully formed first, since the key is dependent on the message content. As for non-adaptive CPA, IGE is secure against them, as is CBC.

Q: Are you doing Encrypt-then-MAC, MAC-then-Encrypt or Mac-and-Encrypt?

Our scheme is closer to MAC-and-Encrypt with an essential modification. Namely, the encryption key and iv are hash-dependent.

  • We use SHA1 for integrity check
  • The SHA1 in question is for raw unencrypted data.
  • The message key is SHA1-dependent.
  • Note that the AES key and iv depend on that SHA1.

The resulting data-dependant variable key denies all common attacks.

Q: Why do you use SHA-1 in the place of a MAC?

Technically speaking, in our implementation SHA-1 can be seen as a specific case of a MAC (but not HMAC), since it is also used as an encryption key.

We use it, because it is faster, especially when you need to send photos or large videos (Telegram supports videos and files up to 1Gb in size). And since this means still requiring at least 2^128 operations (instead of 2^256 with, say, SHA-2) to even begin trying to break this scheme, the trade-off seems fair.

Authentication

Q: Is the key verification between clients mandatory?

Secret Chats do not use mandatory authentication via a third-party or pre-shared information. We may later add an option to forbid Secret Chat initialization, unless the user has confirmed the key (using a QR code, NFC, etc.) for advanced users.

Q: Do you have Forward Secrecy?

Forward Secrecy is available for Secret Chats, but requires user action at the moment — it can be achieved by deleting secret chats and creating new ones, or logging out periodically (since logging out kills all secret chats).

Forward Secrecy is supported in the protocol — the primitive p_q_inner_data_temp can be used to generate temporary keys with limited TTL to achieve PFS. We are working on our client apps to bring Forward Secrecy to ordinary Telegram chats. It is currently possible to create a Telegram client that supports Perfect Forward Secrecy using our API.