In the light of these results, we can affirm that MTProto 2.0 does not present any logical flaw. Vulnerabilities can arise only from the cryptographic primitives, from implementation flaws (e.g. insufficient checks), from side-channels exfiltration (such as timing or traffic analysis), or from incorrect user behaviour. Hence, these are the aspects which deserve further investigation and particular care in the implementation and use of this protocol.
The basic encryption primitive of MTProto 2.0 is assumed to be a perfect authenticated encryption scheme (IND-CCA and INT-CTXT). Although no attack on this scheme is known to date, these properties need to be formally proved in order to deem MTProto 2.0 definitely secure. This proof cannot be done in a symbolic model like ProVerif’s, but it can be achieved in a computational model, using tools like CryptoVerif or EasyCrypt [5, 2], which we leave to future work. However, even in the very unlikely case that a flaw is found in the encryption scheme, the results in this paper would be still valid: the protocol could be used just by replacing the encryption scheme, and no other changes would be required.
[/quote]
This analysis the protocol, not the cryptographic primitives, which was what get criticized
“ Following this approach, in our model we consider the message encryption scheme used in MTProto 2.0 as a robust authenticated-encryption scheme, abstracting from its actual implementation.”
So yeah, they’re abstracting away the AE part of it, which may not be an accurate reflection of what telegram uses.
That being said, they’re aware this is a strong assumption:
“ Namely, the only assumption we make is that the latter is an authenticated encryption scheme, guaranteeing both integrity of ciphertext (INT-CTXT) and indistinguishability of chosen plaintext (IND-CPA). These properties are difficult to prove in a symbolic model like ProVerif’s, but can be proved in a computational model, e.g. using tools like CryptoVerif or EasyCrypt [5, 2]. This assumption may appear strong, especially considering that Telegram has been widely criticized for its design choices (such as ad hoc cryptographic primitives and an unusual encryption mode), and vulnerabilities have been found in MTProto v1.0 (but actually, none of these attacks have been replicated on the new MTProto 2.0). Still, proving the logical correctness of the protocol under a fairly general threat model is very important because, if a weakness in the protocol exists, it must be looked for in the “lower-level” part of the protocol, among the chosen cryptographic functions and other implementation choices.”
As far as I can tell, AES256-IGE is a made up mode used only by Telegram. That’s far from being a standard choice. I don’t know what authenticated encryption scheme they build on it, but on a very brief look, it doesn’t look authenticated at all.
It’s written in patent-ese, but it looks like a mediocre attempt at an efficient authenticated encryption scheme, and it doesn’t appear to use the building blocks of modern schemes. I can’t even find a coherent description of what the “non-cryptographic manipulation detection code” is or what properties are required.
Meanwhile, the Telegram protocol is new. Surely it should use a standard AEAD with a security proof.
In the light of these results, we can affirm that MTProto 2.0 does not present any logical flaw. Vulnerabilities can arise only from the cryptographic primitives, from implementation flaws (e.g. insufficient checks), from side-channels exfiltration (such as timing or traffic analysis), or from incorrect user behaviour. Hence, these are the aspects which deserve further investigation and particular care in the implementation and use of this protocol.
The basic encryption primitive of MTProto 2.0 is assumed to be a perfect authenticated encryption scheme (IND-CCA and INT-CTXT). Although no attack on this scheme is known to date, these properties need to be formally proved in order to deem MTProto 2.0 definitely secure. This proof cannot be done in a symbolic model like ProVerif’s, but it can be achieved in a computational model, using tools like CryptoVerif or EasyCrypt [5, 2], which we leave to future work. However, even in the very unlikely case that a flaw is found in the encryption scheme, the results in this paper would be still valid: the protocol could be used just by replacing the encryption scheme, and no other changes would be required.
[/quote]
This analysis the protocol, not the cryptographic primitives, which was what get criticized