<story><title>Why Telegram is insecure (2015)</title><url>https://medium.com/@thegrugq/operational-telegram-cbbaadb9013a</url></story><parent_chain><item><author>yogthos</author><text>So, here&amp;#x27;s the thing I&amp;#x27;d like somebody to explain to me. Telegram encryption spec is published, and the client is open source. This means you can verify that the server is following the spec by creating a clean room client implementation. You could even create a green field server implementation if you wanted.&lt;p&gt;Telegram regularly has contests to break its encryption with a reward of 300K USD &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;telegram.org&amp;#x2F;blog&amp;#x2F;cryptocontest&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;telegram.org&amp;#x2F;blog&amp;#x2F;cryptocontest&lt;/a&gt;&lt;p&gt;If it&amp;#x27;s not secure, then surely people would be cashing in on that sweet money. So, why is it that we constantly see articles talking about how insecure Telegram encryption is, but nobody is showing a proof of concept attack or collecting the prize?&lt;p&gt;Unless somebody puts their money where their mouth is and shows an actual exploit with code, it seems like pure FUD to me. On top of that, it appears that attacks on Telegram often come from people associated with Signal in some way. Signal is endorsed by NSA who have a history of promoting weak encryption that they have found backdoors into. I hope everybody still remembers this debacle &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;golem.ph.utexas.edu&amp;#x2F;category&amp;#x2F;2014&amp;#x2F;10&amp;#x2F;new_evidence_of_nsa_weakening.html&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;golem.ph.utexas.edu&amp;#x2F;category&amp;#x2F;2014&amp;#x2F;10&amp;#x2F;new_evidence_of...&lt;/a&gt;</text></item></parent_chain><comment><author>saagarjha</author><text>&amp;gt; the client is open source&lt;p&gt;Uh, no it’s not. The client (which happens to seemingly violate a bunch of open-source licenses) and the code posted to GitHub do not match; occasionally a source dump is posted online but there’s no indication how this relates to what they are shipping, as the released binaries differ and update much more frequently. The author is quite unresponsive about this: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;overtake&amp;#x2F;TelegramSwift&amp;#x2F;issues&amp;#x2F;163&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;overtake&amp;#x2F;TelegramSwift&amp;#x2F;issues&amp;#x2F;163&lt;/a&gt;</text></comment>
<story><title>Why Telegram is insecure (2015)</title><url>https://medium.com/@thegrugq/operational-telegram-cbbaadb9013a</url></story><parent_chain><item><author>yogthos</author><text>So, here&amp;#x27;s the thing I&amp;#x27;d like somebody to explain to me. Telegram encryption spec is published, and the client is open source. This means you can verify that the server is following the spec by creating a clean room client implementation. You could even create a green field server implementation if you wanted.&lt;p&gt;Telegram regularly has contests to break its encryption with a reward of 300K USD &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;telegram.org&amp;#x2F;blog&amp;#x2F;cryptocontest&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;telegram.org&amp;#x2F;blog&amp;#x2F;cryptocontest&lt;/a&gt;&lt;p&gt;If it&amp;#x27;s not secure, then surely people would be cashing in on that sweet money. So, why is it that we constantly see articles talking about how insecure Telegram encryption is, but nobody is showing a proof of concept attack or collecting the prize?&lt;p&gt;Unless somebody puts their money where their mouth is and shows an actual exploit with code, it seems like pure FUD to me. On top of that, it appears that attacks on Telegram often come from people associated with Signal in some way. Signal is endorsed by NSA who have a history of promoting weak encryption that they have found backdoors into. I hope everybody still remembers this debacle &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;golem.ph.utexas.edu&amp;#x2F;category&amp;#x2F;2014&amp;#x2F;10&amp;#x2F;new_evidence_of_nsa_weakening.html&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;golem.ph.utexas.edu&amp;#x2F;category&amp;#x2F;2014&amp;#x2F;10&amp;#x2F;new_evidence_of...&lt;/a&gt;</text></item></parent_chain><comment><author>xashor</author><text>&amp;gt;Telegram regularly has contests to break its encryption with a reward of 300K USD &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;telegram.org&amp;#x2F;blog&amp;#x2F;cryptocontest&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;telegram.org&amp;#x2F;blog&amp;#x2F;cryptocontest&lt;/a&gt;&lt;p&gt;&amp;gt;If it&amp;#x27;s not secure, then surely people would be cashing in on that sweet money. So, why is it that we constantly see articles talking about how insecure Telegram encryption is, but nobody is showing a proof of concept attack or collecting the prize?&lt;p&gt;regulary != 2 times with limited time. Also, E2EE is not only about decrypting a message. E.g. signing messages as someone else isn&amp;#x27;t awarded. Also, you might need a lot of computation power. SHA-1 used in MTProto 1.0 for example is practically pretty secure, but not against a well funded attack.&lt;p&gt;But that aside, Telegram&amp;#x27;s encryption &lt;i&gt;is probably&lt;/i&gt; good enough. But we already have standards that &lt;i&gt;are&lt;/i&gt; good enough. Why risk it?&lt;p&gt;For example, from On the CCA (in)Security of MTProto[0]:&lt;p&gt;&amp;gt;Telegram is a popular messaging app which supports end-to-end encrypted communication. In Spring 2015 we performed an audit of Telegram&amp;#x27;s Android source code. This short paper summarizes our findings. Our main discovery is that the symmetric encryption scheme used in Telegram -- known as MTProto -- is not IND-CCA secure, since it is possible to turn any ciphertext into a different ciphertext that decrypts to the same message.&lt;p&gt;&amp;gt;We stress that this is a theoretical attack on the definition of security and we do not see any way of turning the attack into a full plaintext-recovery attack. At the same time, we see no reason why one should use a less secure encryption scheme when more secure (and at least as efficient) solutions exist.&lt;p&gt;&amp;gt;The take-home message (once again) is that well-studied, provably secure encryption schemes that achieve strong definitions of security (e.g., authenticated-encryption) are to be preferred to home-brewed encryption schemes.&lt;p&gt;And that aside, E2EE is not default and neither E2E group chats or E2E video calls are supported. This is the biggest security problem.&lt;p&gt;[0] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;dl.acm.org&amp;#x2F;citation.cfm?id=2994468&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;dl.acm.org&amp;#x2F;citation.cfm?id=2994468&lt;/a&gt;</text></comment>