> Because the applied crypto community points out issue after issue after issue with their product and is met with variations of "nuh uh, it's fine!"
Well, no. That's the thing. That's a Hollywood version of it. He said she said it's all horrible piece of shit, because of something someone else said earlier on an unrelated subject. What makes rounds is the regurgitated abstract hate towards Telegram, whereby the factual matter has been long forgotten.
Let me put it this way - name a couple of open design issues with the current Telegram protocol.
"Let me put it this way - name a couple of open design issues with the current Telegram protocol."
Sorry, it doesn't work this way: 'When someone hands you a security system and says, "I believe this is secure," the first thing you have to ask is, "Who the hell are you?" Show me what you've broken to demonstrate that your assertion of the system's security means something.'
The GP said there were numerous issues identified with Telegram's design, all of which were brushed aside by Telegram devs. I asked to name a couple of them.
The use of encrypt and MAC is the one that should jump out at even a crypto neophyte.
There are some nice proofs around this[1] that I've read before. The important one is that encrypt then MAC guarantees INT-CTXT: it's computationally infeasible to produce a ciphertext not before sent by the sender. INT-CTXT implies INT-PTXT which is the weaker claim but typically the one people associate with the function of a MAC: that you can't forge a plaintext the sender never sent.
While E&M isn't immediately bad it has been used as an avenue for attack[2]. If Telegram's aes_ige_decrypt() function accidentally overflows a buffer... and because they're doing E&M it must call aes_ige_decrypt() on whatever message I decide to send it.
Now, Telegram can claim that those attacks don't apply because of their use of IGE, and they may very well be correct! But then we move into IGE: there are known attacks that show chosen error introductions can cause the stream to resynchronize without error[3]. What does that mean in practice? Who knows: we know IGE is broken, but we don't know how badly because no one actually studies IGE, or knows how it is implemented in this system!
The real failings here: Telegram uses a MAC with less security guarantees AND a cipher mode that would be charitably described as anonymous, instead of using a provably secure MAC along with well-studied modes.
Now, I'm a big security dummy (seriously) but if there's one thing people far smarter than me have banged in my head, it's this: you follow the well-beaten path precisely because it is well-beaten. When you start venturing off the trail into the woods of funky block cipher modes and known-problematic MAC modes, your margins get a lot thinner.
It's been awhile since I looked at anything in Telegram and I forget what MAC they use. That diagram makes it look like instead of a MAC, they're using a simple digest of the message --- which is not a MAC.
Well, no. That's the thing. That's a Hollywood version of it. He said she said it's all horrible piece of shit, because of something someone else said earlier on an unrelated subject. What makes rounds is the regurgitated abstract hate towards Telegram, whereby the factual matter has been long forgotten.
Let me put it this way - name a couple of open design issues with the current Telegram protocol.