Crypto is sometimes about feelings and maybes, not necessarily that an actual, working exploit trivially exists. Aspects of Telegram's crypto design and the UX

Crypto is sometimes about feelings and maybes, not necessarily that an actual, working exploit trivially exists. Aspects of Telegram's crypto design and the UX do not give confidence. To give a specific scenario to illustrate my point, the BEAST attack on TLS happened in 2014, but we knew that CBC was vulnerable to this specific attack since ~2002 (Vaudenay) and that malleability was a concern even earlier. At the time, however, for TLS it was considered impractical and only of academic concern. Had someone offered a sum of money to prove TLS hadn't accounted for this design flaw at the time, nobody would've been able to claim it. The modern reliance and widespread adoption of ajax and client-side web apps made an actual attacker-controlled-plaintext scenario required for this exploit a reality. We're paying much more attention now to concerns like constant time code, invalid curve attacks, IND-CCA2 etc not because attacks are obviously possible now, but because we can't always predict when they may become viable in the future. However, Telegram's choices seem to ignore much of the conventional, hard-earned crypto wisdom. Statements like this: "Properties like IND-CCA are convenient for theoretical definitions and scientific inquiry, but they are not directly related to the actual security of communication." are really concerning - IND-CCA is directly related to the security of communication. It's very definition is that, if provided with some known chosen ciphertext/plaintext pairs (ciphertext controlled by the attacker), can the attacker later distinguish two messages encrypted under the scheme. In plain english, schemes that do not have this property start to leak information to the attacker if there is a small partial compromise. There's been a whole bunch of recent issues (particularly with RSA) where the lack of CCA-security has caused a possible attack. Nobody else in the secure messaging space is trying to argue such security definitions are inconsequential. If the article is correct, it seems not only are they dismissive of it, but they've made no effort to fix it. As for your last paragraph, I do not dispute your claim NSA have deliberately attempted to weaken encryption. Dual_EC_DRBG is direct evidence of this. However this is orthogonal to the issue at hand. So far as we know, there is no public evidence Signal and the NSA have collaborated (or of coercion) (your article is about general attempts to weaken cryptography, not Signal). Signal's protocol uses NIST Algorithms, but then so does Telegram. The curve choices in Signal's protocol were developed independently of NIST and NSA. I don't see any evidence Signal is endorsed by the NSA. If anything, the deployment of end-to-end encryption pioneered by Signal is concerning Five Eyes governments to the point they are legislating lawful interception requirements. I stress, to avoid sounding like "FUD", that I'm not claiming telegram is insecure. I am, however, claiming Telegram's choices are concerning and that as a result I do not trust it as a secure messenger. They could fix this by reviewing their choices and being less dismissive of crypto research. I'm not associated with Signal in any way, I don't even use it. I use a competing product for secure messaging (and I'm not affiliated with them either).