This FAQ covers questions about the previous version of MTProto (v.1.0) that is now deprecated.
For questions about encryption used in up-to-date Telegram clients, kindly refer to this document.
The principal differences from version 1.0 (described here and here for reference) are as follows:
The current version of MTProto uses SHA-256 in all the critical locations. MTProto 1.0 used to rely on SHA-1.
Even though it is possible for a well-funded attacker to find collisions in SHA-1, crafting a collision alone did not break the MTProto encryption scheme due to the way SHA-1 was used in the protocol. We did not use SHA-1 in any areas where collisions are important, such as digital signatures or file identification.
We used SHA as a component in the KDF and for a security check after transmission. Even if an attacker could create messages with a chosen SHA-1 (a far greater achievement than merely finding a collision), it would not give them any advantage. This is because we used the SHA-1 of the plaintext *, while MTProto passed the ciphertext encrypted with a key unknown to the attacker. In order to threaten this setup, one would need not a collision in SHA-1(ciphertext), but a collision in SHA-1(AES_Decrypt(key_unknown_to_attacker, ciphertext)).
It is important that the plaintext always contains message length, server salt, session_id and other data not known to the attacker. It is crucial that AES decryption keys depend both on msg_key, and on auth_key, known only to the parties involved in the exchange.
The current version of MTProto satisfies the criteria for IND-CCA. MTProto 1.0 used to deviate from this property without any effect on message security.
Properties like IND-CCA are convenient for theoretical definitions and scientific inquiry, but they are not directly related to the actual security of communication. There are cases when IND-CCA compliance can be critical, but in the case of MTProto (1.0) the deviation from this property was a minor issue and did not affect message security. Namely, under certain circumstances a ciphertext could be modified so that it would have been accepted and decrypted to the same plaintext as the original unmodified ciphertext. It was impossible for the attacker to tamper with or decipher the plaintext.
The gist, for non-technical readers, is this: Under certain circumstances somebody could take an encrypted message after it was sent (without knowing what was inside), change some symbols in the ciphertext (without being able to alter the actual message inside), and pass it on to you. After decryption, you would receive the same message that was sent and only you and the sender would know what was in it.
To put this case into familiar terms:
A postal worker could write 'Haha' (using invisible ink!) on the outside of a sealed package that he delivers to you. It didn't stop the package from being delivered, it doesn't allow them to change the contents of the package, and it doesn't allow them to see what was inside.
Earlier versions of Telegram used a 128-bit fingerprint to create the key visualization. It was theoretically possible to spoof it, provided a man-in-the-middle attacker was prepared to spend hundreds of billions of dollars to spoof one secret chat (even using GPUs or ASICs). It would've also taken such a secret chat an entire month to be created instead of mere seconds, which would've certainly been hard to ignore.
Currently, the fingerprint uses an additional 160 bits from the SHA-256 of the key, yielding a total of 288 fingerprint bits, which makes the already infeasible attacks completely impossible.