As mentioned in the recent post ” Is Telegram Safe?” Or as I was looking for a bookmark in MTProto “- Telegram is a super secure messenger for smartphones, so secure that for its hacking a contest with an impressive prize was announced. In that post, an effective attack on its protocol ( MTProto ) was described , the brief essence of which is that “the Telegram server can pick up such a nonce, at which the keys of users will coincide even with the MITM-attack and no one will know that they are listening ” , where under the nonceimplied a “random” sequence of data involved in setting the key would seem to be just to increase the entropy, but in fact it allowed the administrators of Telegram servers to easily and, most importantly, not detectable for users to perform a Man-in-the-middle (MITM) attack on the protocol by exchange of keys. Some even considered the code section responsible for the vulnerability – a bookmark.
To Telegram’s credit, it was quickly acknowledged that the vulnerability was present and its correction was announced in the next version of the messenger, and the author was promised a reward – ibeatle wrote: ” From now on, there will always be zero in the nonce, and in the next layer we will necessarily remove this field from the scheme and explain in the documentation . ” Meanwhile, in the description of protocol 1 we already see that the ill-fated ‘ xor nonce ‘ has disappeared, and the code has changed for the better. Pavel Durov said: ” Just in case, I will explain to the mass users: there was no data leakage, the vulnerability is closed, there is no danger .” All is well that ends well.
But did the vulnerability disappear and did Telegram become protected from an undetectable MITM? There is an opinion that did not become and administrators of Telegram servers can still listen to users so that checking the keys will show that they coincide.
For this it is enough to apply the attack of the degenerate key to the Diffie-Hellman protocol (DH). The previous attack was part of the keying protocol algorithm, which occurs right after DH, but there is also DH itself. The documentation has an attempt to protect against some attacks on DH – it is prescribed to check the public parameters p and g: ” client is expected to check whether p is safe 2048-bit prime, and that g generates a cyclic subgroup of order (p-1) / 2. “But nothing is said about checking the public keys g_a and g_b.For
the attack, it is enough for the server to replace both parameters g_a and g_b sent from clients A and B by one (1) .In this case, both users, as a result of calculating the private key, the unit will turn out. the server (or any other observer attack session) knowing this property DH protocol can easily decrypt and read their messages. Although outwardly everything looks “encrypted.” Moreover, key_fingerprint this degenerate key is visually indistinguishable from normal th complex key as fingerprint, it is not the key itself, and sha1 kriptohesh the key.
To fix this vulnerability, it would be sufficient for the messenger to verify that the sent g_a and g_b are not equal to one.