As already mentioned in a recent post “
Is Telegram Safe? Or, as I was looking for a bookmark in MTProto, ”
Telegram is a super secure messenger for smartphones that is so secure that a contest with an impressive prize was announced for its breaking. 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 a nonce in which the keys of users coincide even during a MITM attack and no one will know that they are listening to it " where
nonce meant “random” data sequence involved in setting the key, it would seem, simply to increase entropy, but in reality it enabled the administrators of Telegram servers to easily and, most importantly,
not detectable for users to perform
Man-in-middle (MITM) attack on pr tocol to exchange keys. Some even found the code section responsible for the vulnerability - bookmark.
To the credit of Telegram, quite quickly it was recognized that the vulnerability is present and its correction was announced in the next version of the messenger, and the author is
promised a reward -
ibeatle writes: "
from now on, zero will always come to zero, and in the next layer we will definitely 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 mass users: there was no data leakage, the vulnerability is closed, there is no danger ." All is well that ends well.
But has the vulnerability disappeared and has Telegram become protected from an
undetectable MITM? There is an opinion that the administrators of Telegram servers
still could not listen to users so that the verification of the keys will show that they match.
To do this, it suffices to use a degenerate key attack on the
Diffie-Hellman (DH) protocol. The previous attack was on a part of the key establishment protocol algorithm that occurs immediately
after DH, but there is also DH itself. In the documentation, there is an attempt to protect against some attacks on DH - it is prescribed to check the public parameters of p and g: "it
’s a 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.
')
To carry out an attack, it is enough for the server to replace both parameters
g_a and
g_b by
one (1) sent from clients A and
B. In this case, both users as a result of the calculation of the private key will also have units. The server (and any other observing attacked session) knowing this property of the DH protocol will be able to calmly decrypt and read their messages. Although outwardly, everything will look "encrypted." Moreover, the
key_fingerprint of this degenerate key will not be visually distinguishable from a normal complex key, since the fingerprint is not the key itself, but the sha1 cryptohash from the key.
To fix this vulnerability, a messenger would be enough to check that the
g_a and
g_b sent are not equal to one.
_________
1 Copy of the protocol description dated December 22:
archive.is/Z8Keu