Cryptographic Weaknesses in Telegram's MTProto

Kind of, they detail a MitM attack and a way to extract plaintext from a client but both of them seem very impractical to do.

Arm-Chair Quaterbacker response -

"In particular, Telegram encrypts acknowledgement messages, i.e. messages that encode that a previous message was indeed received, but the way it handles the re-sending of unacknowledged messages leaks whether such an acknowledgement was sent and received. "

That ^ bit is indeed of interest. Having this ability could be useful in two ways that immediately spring to mind if I were a 'james bond villain'

I am currently taking a skim through the paper which for the curious is available at https://mtpsym.github.io/paper.pdf (52 pages)

[Edit] Will leave it to those better qualified regarding the math but uhhmm yeah, A good summary is yes, there were somethings that could have been exploited and were patched by the Telegram team and a bug bounty awarded (as noted in the article). The thing I found of interest bit turned out indeed to be in the 'highly theoretical' realm. As in "only on a wet Wednesday when the wind is blowing from the west at a precise angle way"

Kinda

> We also show how an attacker can mount an “attacker-in-the-middle” attack on the initial key negotiation between the client and the server. This allows an attacker to impersonate the server to the client, allowing to break confidentiality and integrity of the communication. Luckily, this attack is also quite difficult to carry out, as it requires sending billions of messages to a Telegram server within minutes.

The most practical of the four attacks appears to be the message reordering in that it is something that actually could be done and might potentially mean something. The attacker would be unlikely to know the content of the encrypted messages in an instant messaging system to do some sort of meaningful attack. In the case where the messages were not waiting on a server for an offline client the attacker would have the difficulty of having to buffer the messages themselves in a way which would not break communications entirely. IM is fairly interactive end to end most of the time so message reordering is not much of a threat.

Hardware (Originator) timestamped for ordering on the receivers end at the encrypted package unwrap point plus the SMS solution of "delete/discard any unsent/undeliverable messages after x days?" Does that solve both issues?