Telegram’s Contest
By going through the attack models, I wanted to get across an idea that’s very important when reasoning about crypto security. I’ll repeat it again: If you want to show that a system is secure, give the adversary as much power as possible, and if they still can’t break it, the security is good. Knowing that the system is secure in a weak model, like KPA, does not mean it’s secure in a stronger (and more realistic) model like CCA. If a tank is bullet-proof, it might not be RPG-proof.
Okay, enough crypto theory. Back to the real problem: Telegram’s contest. The contest works like this:
Every day, Paul sends a message to Nick containing an email address. You win the contest by sending an email to that address. You get a transcript of the network traffic coming in and out of Paul’s account. According to the faq, you can send arbitrary packets to the server, but you can’t intercept/modify the communication.
The problem should be clear now: Telegram’s contest does not give the adversary enough power. The adversary doesn’t doesn’t get known plaintexts, can’t choose plaintexts, can’t choose ciphertexts, can’t modify network traffic, or anything like we covered in the previous sections. The contest barely fits into the known plaintext attack (KPA) model.
If nobody wins the contest, it does not mean Telegram is secure. It means Telegram might be secure within the constraints of the contest. However, there are extremely weak systems that can survive a Telegram-style contest, so if nobody wins the contest, it won’t give us any more confidence in Telegram’s security.
So how good is Telegram’s crypto?
Telegram’s design seems to disregard all of the important crypto research from the past two decades. Their protocol is described here, and here’s a diagram of their encryption:
Telegram's Encryption
Some problems are immediately apparent:
They use the broken SHA1 hash function.
They include a hash of the plaintext message in the ciphertext. Essentially, they are trying to do “Mac and Encrypt” which is not secure. They should be doing “Encrypt then Mac” with HMAC-SHA512.
They rely on an obscure cipher mode called “Infinite Garble Extension.”
Some really weird stuff about factoring 64-bit integers as part of the protocol.
They do not authenticate public keys.
If their protocol is secure, it is so by accident, not because of good design. They claim the protocol was designed by “six ACM champions” and “Ph.Ds in math.” Quite frankly, the protocol looks like it was made by an amateur. The tight coupling between primitives suggests the designer was not familiar with basic constructs, like authenticated encryption, that you can find in any cryptography textbook.
