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 dependent 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
msg_key is equal to the SHA-256 of a fragment of the
auth_key concatenated with the decrypted message (including 12…1024 bytes of random padding). The plaintext (decrypted data) also always contains message length, server salt and sequence number. This negates known CCAs.
What about IND-CCA?
MTProto 2.0 satisfies the conditions for indistinguishability under chosen ciphertext attack (IND-CCA).
Replay attacks
Replay attacks are denied because each plaintext to be encrypted contains the server salt and the unique
message idand sequence number.
This means that each message can only be sent once.
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.
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.
Hash collisions for Diffie-Hellman Keys
Currently, the fingerprint uses 128-bits of SHA-1 concatenated with 160 bits from the SHA-256 of the key, yielding a total of 288 fingerprint bits, thus negating the possibility of hash-collision attacks.
Length extension attacks
By definition, length extension attacks are a type of attack when certain types of hashes are misused as message authentication codes, allowing for inclusion of extra information.
A message in MTProto consists of an
msg_key, equal to the SHA-256 of a fragment of the
auth_key concatenated with the plaintext (including
some additional parameters and 12…1024 bytes of random padding), followed by the ciphertext. The attacker cannot append extra bytes to the end and recompute the SHA-256, since the SHA-256 is computed from the plaintext, not the ciphertext, and the attacker has no way to obtain the ciphertext corresponding to the extra plaintext bytes she may want to add.
Apart from that, changing the
msg_key would also change the AES decryption key for the message in a way unpredictable for the attacker, so even the original prefix would decrypt to garbage — which would be immediately detected since the app performs a
security check to ensure that the SHA-256 of the plaintext (combined with a fragment of the
auth_key) matches the
msg_key received.
Encrypted CDNs
As of Telegram 4.2, we support encrypted CDNs for caching media from public channels with over 100.000 members. The CDN caching nodes are located in regions with significant Telegram traffic where we wouldn't want to place Telegram servers for various reasons.
For technical details of the implementation, encryption and verification of data,
see the CDN manual.
See
this document for a Persian version of this FAQ.
بخش فارسی
Q: Why did you decide to use CDNs?
We use our own distributed servers to speed up downloads in regions where freedom of speech is guaranteed — and even there
we don't take this for granted. But when Telegram becomes immensely popular in other areas, we can only rely on CDNs which we treat rather like ISPs from the technical standpoint in that they only get encrypted data they can't decipher.
Thanks to this technology, the download speed for public photos and videos can become significantly higher in regions like Turkey, Indonesia, South America, India, Iran or Iraq without the slightest compromise in security.
Q: Can the CDN decipher the files?
No. Each file that is to be sent to the CDN is encrypted with a unique key using AES-256-CTR encryption. The CDN can't access the data it stores because these keys are only accessible to the main MTProto server and to the authorized client.
Q: Can the CDN substitute the data with their own version?
No. Data downloaded from CDN caching nodes is always verified by the receiving Telegram app by way of a hash: attackers won’t be able to replace any files with their own versions.
Q: Can the CDN delete any files?
No. CDN nodes only cache encrypted
copies of files, originals are stored on the Telegram servers. The user is notified about receiving the file by the Telegram server. If the CDN caching node doesn't give the file to the user, the user will receive the file from the Telegram server directly.
Q: Can CDNs be used for censorship?
No. All original files are stored on the Telegram servers. The CDNs only get encrypted data — and they can't decipher it. They can't substitute any data. And in case of any problems with the CDN, the file will be simply delivered to the users directly from the Telegram servers. Users will always get their data, nobody can stop this.
Q: Can I verify this?
Yes. Anyone can verify our CDN implementation by checking the
source code of Telegram apps and inspecting traffic.
Q: Does this affect private data?
No. The CDN caching nodes are not a part of the Telegram cloud. CDN caching nodes are used only for caching popular public media from massive channels. Private data never goes there.
Q: Is this connected with government requests to move private data to their territory?
No. We haven't entered in any agreements with any government regarding the CDNs and the CDNs are not part of any deal. The only purpose of CDNs is to securely improve connectivity in high demand regions where Telegram can't place its servers.
Q: Does this give some countries any influence over Telegram?
No. We have taken special precautions to make sure that no country gains any leverage over Telegram by way of the CDN caching nodes:
- The CDNs do not belong to Telegram – all the risks are on a third-party company that supplies us with CDN nodes around the world.
- We did not invest anything in these CDNs and will only be paying for traffic that is used to pass cached items from our main clusters and to the end users.
As the result, if any country decides to mess with the CDN in their region, they gain nothing except for reducing connectivity for their own citizens – and Telegram loses nothing of value.
support.apple.com
