8 ms·

So, here's the thing I'd like somebody to explain to me. Telegram encryption spec is published, and the client is open source. This means you can verify that th

So, here's the thing I'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. Telegram regularly has contests to break its encryption with a reward of 300K USD https://telegram.org/blog/cryptocontest https://telegram.org/blog/cryptocontest If it'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? 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 https://golem.ph.utexas.edu/category/2014/10/new_evidence_of_nsa_weakening.html https://golem.ph.utexas.edu/category/2014/10/new_evidence_of...

xashor 8y ago
>Telegram regularly has contests to break its encryption with a reward of 300K USD https://telegram.org/blog/cryptocontest https://telegram.org/blog/cryptocontest >If it'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? regulary != 2 times with limited time. Also, E2EE is not only about decrypting a message. E.g. signing messages as someone else isn'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. But that aside, Telegram's encryption is probably good enough. But we already have standards that are good enough. Why risk it? For example, from On the CCA (in)Security of MTProto[0]: >Telegram is a popular messaging app which supports end-to-end encrypted communication. In Spring 2015 we performed an audit of Telegram'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. >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. >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. And that aside, E2EE is not default and neither E2E group chats or E2E video calls are supported. This is the biggest security problem. [0] https://dl.acm.org/citation.cfm?id=2994468 https://dl.acm.org/citation.cfm?id=2994468
- x092 8y ago
  MtProto has since been changed to satisfy IND-CCA requirements: https://core.telegram.org/techfaq#what-about-ind-cca https://core.telegram.org/techfaq#what-about-ind-cca
  - xashor 8y ago
    Yeah, I'm not sure about it. I'm not a security expert that can look at the protocol for some weeks and come to a conclusion. Believing them after they did things wrong is not very convincing. Given some years and many eyes, and I might believe it. But until then?
- yogthos 8y ago
  The key point in all this is that nobody seems to have a working exploit to show. Traditionally, when people claim that something is insecure they have to provide tangible evidence of that being the case. I'm not aware of any published exploits that show MTProto to be insecure. People also seem to conflate the fact that encryption is not on by default, or that it doesn't apply to stuff like voice chat with questions about the quality of the protocol. This is a completely separate topic of discussion.
  - pseudalopex 8y ago
    Operational security is part of security. The article is not "Why MTProto is insecure". Traditionally when people claim a system is cryptographically secure it's after rigorous analysis. MTProto isn't scientifically interesting. Two short contests several years ago don't make it financially interesting. The groups with the most incentive to break it have the least incentive to publish.
alkyl 8y ago
Can you elaborate on Signal being supported by the NSA? I’ve never come across anything suggesting this. I’m not sure how Signal was supported financially between 2015 and 2018 — maybe out of Moxie’s own pocket from Whisper Systems acquisition by Twitter? — but right now its continued development is supported by a $50,000,000 donation[0] from Brian Acton of WhatsApp. [0] https://signal.org/blog/signal-foundation/ https://signal.org/blog/signal-foundation/
- BoumTAC 8y ago
  I think he refer to this https://thebaffler.com/salvos/the-crypto-keepers-levine https://thebaffler.com/salvos/the-crypto-keepers-levine
  - SlowRobotAhead 8y ago
    What a bizarre article!! The author can’t seem to tell his story without tossing attacks at the NRA and guns - while admitting that there is a point to everyone having the same level of access to things the government might use against you (be it encryption or guns). The author seems to embrace that the unbelievable idea from the media that “Trump won, now you need to encrypt your email”... while that sentiment ignores it was Obama admin that was prosecuting whistleblowers more than anyone before, using the NSA to unmask citizens in political oppsoition, the IRS targeting, and under Clinton pushed the “Internet freedom” policies... I feel like the article was gaslighting itself. And then finally at the bottom, Signal is funded by a company that is associated with a government group. Which is concerning, no doubt. Just what a strange and often seemingly self-arguing article! Maybe I just don’t understand the author at all.
  - geofft 8y ago
    That article (accurately) points to Signal's initial funding by the Open Technology Fund, an program that gives grants to internet freedom technologies that line up with US interests and is funded by Radio Free Asia, which is under the State Department. Radio Free Asia was previously CIA-funded, many many years before the creation of the Open Technology Fund. (Also, Radio Free Asia, both in the past and in the present, is working on problems where being secure against large governments is much more useful than having back doors.) It has never been NSA-affiliated (unless you count "being part of the US government" as NSA-affiliated). The relationship between Signal and the State Department is solely one of funding, not of technical interaction, let alone technical endorsement.
LurkersWillLurk 8y ago
Telegram's crypto contest is questionable (see "A Crypto Challenge for the Telegram Developers" https://hackerfall.com/story/a-crypto-challenge-for-the-telegram-developers-1 https://hackerfall.com/story/a-crypto-challenge-for-the-tele... and https://news.ycombinator.com/item?id=6936539 https://news.ycombinator.com/item?id=6936539 for previous discussion) > Signal is endorsed by NSA Uh, what? This isn't true.
prophesi 8y ago
Personally, the main rub for me is "Telegram's end-to-end encryption is not turned on by default," which null and voids all of this.
saagarjha 8y ago
> the client is open source 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: https://github.com/overtake/TelegramSwift/issues/163 https://github.com/overtake/TelegramSwift/issues/163
- dijit 8y ago
  Sorry, that's just not true. I have telegram-desktop (on Linux) which is unofficially distributed and compiled on my laptop via AUR[0], FDroid also has a version of telegram which is compiled from sources and not taken from pkg's released by the Telegram group, although they remove non-free parts apparently[1]. I'm not sure about iOS as I don't currently have the means to verify the content of my App Store iOS installed version of telegram, but the fact is that there are (at least) 2 client implementations commonly used that are compiled from source. [0]: https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/telegram-desktop https://git.archlinux.org/svntogit/community.git/tree/trunk/... [1]: https://www.reddit.com/r/fdroid/comments/9gmkob/why_is_telegram_in_f_droid/e6m2is5/ https://www.reddit.com/r/fdroid/comments/9gmkob/why_is_teleg...
  - j16sdiz 8y ago
    how is it not true? the version in github works, but the version on play store different a lot from it..
    - dijit 8y ago
      >and the code posted to GitHub do not match; Well, I was challenging this assertion. "Does not match" what thing exactly? My point was that people are using the non-packaged versions (I mean, I'm not FOSS mad, I'm just a user and I'm using the FOSS version almost by accident). I would prefer the FOSS version to be 1:1 what is in the repo (or, even the upstream of the non-free version), but I see the situation as more chrome/chromium. We're not shitting on chrome for being "the most secure webbrowser" despite having non-free elements. Seemingly because large US tech companies deserve more respect than a guy who was essentially exiled from his country for not handing over his users data? Sounds like a double standard. Telegrams OSS edition works, so if they're sneaking things in it would have to be a backdoor, which would be INCREDIBLY damaging to their endeavour if it was found, and it would be relatively trivial to find too. So I'm not sure where this FUD is coming from. Making the argument about the server not being FOSS is valid though, but then if the E2EE is good enough on the client then the server is basically a relay and can't pilfer anything except metadata. (which, if we're honest, is what governments are after anyway)
zahllos 8y ago
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).
philsnow 8y ago
The crypto is not the problem, the UX is the problem. Any time there is opportunity for the user to be confused, they will be. It's ultimately the user's responsibility to make sure their comms are secure, so it's probably prudent to choose an app that presents the cleanest, least confusing path. Nobody (really) complains about PGP's crypto, but there are dozens of articles rightly criticizing its 80s-era "UX".
K2L8M11N2 8y ago
This[0] is why the challenge is bunk. [0]: https://web.archive.org/web/20171213214126/https://moxie.org/blog/telegram-crypto-challenge/ https://web.archive.org/web/20171213214126/https://moxie.org...
throwawaymath 8y ago
Explaining this will require setting up a bit of terminology. I'm not going to comment on Telegram's security because I don't want to get involved in a Signal-Telegram flame war. But I can at least explain why the contest is a poor methodology for ascertaining the security of a cryptosystem. To begin, when researchers publish or analyze cryptographic algorithms, they model the interaction of legitimate users and adversaries. Two legitimate users will engage in communication and an adversary will sit "in the middle", trying to break ciphertext confidentiality or authenticity (or both). Generally the adversary is allowed to tamper with or reply messages from Alice to Bob and vice versa. Adversaries are alsl given various capabilities of interacting with the cryptosystem and messages therein, and if the cryptosystem is secure against an ever more capable adversary, we say it is "____-secure." Researchers model the interactions in this way to more closely approximate real world, repetitive usage instead of an isolated simulacra. So let's talk about cryptanalytic attacks. There are known plaintext, chosen plaintext, known ciphertext and chosen ciphertext attacks. The attack always has a ciphertext, so known ciphertext is the lowest form (least assured) level of cryptanalysis. A known plaintext attack gives the attacker a corresponding ciphertext and a plaintext. A chosen plaintext attack affords the attacker the ability to use an encryption oracle to encrypt arbitrary plaintexts and see the ciphertexts. And likewise, a chosen ciphertext (the most powerful attack) allows an adversary to decrypt arbitrary ciphertexts. The Telegram contest requires you to provide the plaintext corresponding to a single ciphertext. You are not given access to real time encryption or decryption within a channel and you are not provided with the ability to attempt cryptanalysis on numerous messages. You can't even tamper with messages or try to replay them, because you have an isolated ciphertext to examine. Everything else is outside the scope of the contest. That means the only thing you're allowed to do is a known ciphertext attack. A known ciphertext attack is extremely difficult to pull off even for weak cryptography and it does not resemble the structure of a real world attack. For example, legitimate attacks on TLS are not known ciphertext attacks. That's why the Telegram contest is synthetic. Again, I'm not going to comment on its actual security. But if you want to do real cryptanalysis, you hire a team of cryptographers who didn't design the thing and try to break it with a more generous suite of capabilities that better resemble real world scenarios. The critiques from the cryptographic community should be examined on their own merits, and not judged according to whether or not they've successfully broken something under a known ciphertext attack.
toss1 8y ago
The state actors who have the serious requirements to break into Telegram have zero care about the bug bounty. Moreover it is in their interest that the vulnerabilities remain in the wild. Meanwhile, the bug bounty contests are limited time, several times. Good for publicity, but hard for individual actors to capitalize upon (more likely to take on-and-off work over a long period).
geofft 8y ago
> If it's not secure, then surely people would be cashing in on that sweet money. Because that's not how cryptography works. Remember that there is no mathematical proof that working cryptography even exists. Cryptography relies on "one-way trap-door functions," i.e., functions that cannot be inverted unless you have the secret key, and the existence of one-way trap-door functions implies P ≠ NP. Because we have no proof of P ≠ NP and it may well turn out to be the case that P = NP (surprising as it might be), we have no proof that cryptography is even possible. So, what do cryptographers actually mean? In practice they mostly mean that something has been subject to attacks for years and the public mathematical / cryptanalytic community hasn't found any cracks in the armor. We expect RSA to be secure because people have been working on efficient factoring since at least when we named the P vs. NP problem and arguably for centuries and we haven't made any real progress. We expect block ciphers and hashing algorithms to be secure because they're subject to public scrutiny. The last time we had a contest for a hash function https://en.wikipedia.org/wiki/NIST_hash_function_competition https://en.wikipedia.org/wiki/NIST_hash_function_competition, there were multiple good finalists, none of which were cracked in their entirety. They each were refined as people found attacks against artificially weakened versions of the functions, on the grounds that attacks get stronger over time. And even so only one was endorsed, and even so consensus is, as far as I can tell, to use a newly strengthened version of one of the finalists (BLAKE2) instead of the actual winner (Keccak). And certainly nobody would recommend using any of the other finalists, simply because the attention of the public research community is no longer on them, even though they haven't been publicly broken. It is very easy to make up an encryption algorithm or cryptosystem, run a contest for a few months, and not find a winner. That falls far short of the standards professional cryptographers have for solid cryptography. As with hash functions, it may be the case that nobody has found a specific weakness in Telegram's crypto, but using it when it's not the focus of research / not built on the best primitives the research community has to offer is unnecessary risk. > Signal is endorsed by NSA Please provide evidence of this. As far as I know, this is a lie.

xashor 8y ago

>Telegram regularly has contests to break its encryption with a reward of 300K USD https://telegram.org/blog/cryptocontest https://telegram.org/blog/cryptocontest >If it'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? regulary != 2 times with limited time. Also, E2EE is not only about decrypting a message. E.g. signing messages as someone else isn'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. But that aside, Telegram's encryption is probably good enough. But we already have standards that are good enough. Why risk it? For example, from On the CCA (in)Security of MTProto[0]: >Telegram is a popular messaging app which supports end-to-end encrypted communication. In Spring 2015 we performed an audit of Telegram'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. >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. >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. And that aside, E2EE is not default and neither E2E group chats or E2E video calls are supported. This is the biggest security problem. [0] https://dl.acm.org/citation.cfm?id=2994468 https://dl.acm.org/citation.cfm?id=2994468

x092 8y ago
MtProto has since been changed to satisfy IND-CCA requirements: https://core.telegram.org/techfaq#what-about-ind-cca https://core.telegram.org/techfaq#what-about-ind-cca
- xashor 8y ago
  Yeah, I'm not sure about it. I'm not a security expert that can look at the protocol for some weeks and come to a conclusion. Believing them after they did things wrong is not very convincing. Given some years and many eyes, and I might believe it. But until then?
yogthos 8y ago
The key point in all this is that nobody seems to have a working exploit to show. Traditionally, when people claim that something is insecure they have to provide tangible evidence of that being the case. I'm not aware of any published exploits that show MTProto to be insecure. People also seem to conflate the fact that encryption is not on by default, or that it doesn't apply to stuff like voice chat with questions about the quality of the protocol. This is a completely separate topic of discussion.
- pseudalopex 8y ago
  Operational security is part of security. The article is not "Why MTProto is insecure". Traditionally when people claim a system is cryptographically secure it's after rigorous analysis. MTProto isn't scientifically interesting. Two short contests several years ago don't make it financially interesting. The groups with the most incentive to break it have the least incentive to publish.

alkyl 8y ago

Can you elaborate on Signal being supported by the NSA? I’ve never come across anything suggesting this. I’m not sure how Signal was supported financially between 2015 and 2018 — maybe out of Moxie’s own pocket from Whisper Systems acquisition by Twitter? — but right now its continued development is supported by a $50,000,000 donation[0] from Brian Acton of WhatsApp. [0] https://signal.org/blog/signal-foundation/ https://signal.org/blog/signal-foundation/

BoumTAC 8y ago
I think he refer to this https://thebaffler.com/salvos/the-crypto-keepers-levine https://thebaffler.com/salvos/the-crypto-keepers-levine
- SlowRobotAhead 8y ago
  What a bizarre article!! The author can’t seem to tell his story without tossing attacks at the NRA and guns - while admitting that there is a point to everyone having the same level of access to things the government might use against you (be it encryption or guns). The author seems to embrace that the unbelievable idea from the media that “Trump won, now you need to encrypt your email”... while that sentiment ignores it was Obama admin that was prosecuting whistleblowers more than anyone before, using the NSA to unmask citizens in political oppsoition, the IRS targeting, and under Clinton pushed the “Internet freedom” policies... I feel like the article was gaslighting itself. And then finally at the bottom, Signal is funded by a company that is associated with a government group. Which is concerning, no doubt. Just what a strange and often seemingly self-arguing article! Maybe I just don’t understand the author at all.
- geofft 8y ago
  That article (accurately) points to Signal's initial funding by the Open Technology Fund, an program that gives grants to internet freedom technologies that line up with US interests and is funded by Radio Free Asia, which is under the State Department. Radio Free Asia was previously CIA-funded, many many years before the creation of the Open Technology Fund. (Also, Radio Free Asia, both in the past and in the present, is working on problems where being secure against large governments is much more useful than having back doors.) It has never been NSA-affiliated (unless you count "being part of the US government" as NSA-affiliated). The relationship between Signal and the State Department is solely one of funding, not of technical interaction, let alone technical endorsement.

LurkersWillLurk 8y ago

Telegram's crypto contest is questionable (see "A Crypto Challenge for the Telegram Developers" https://hackerfall.com/story/a-crypto-challenge-for-the-telegram-developers-1 https://hackerfall.com/story/a-crypto-challenge-for-the-tele... and https://news.ycombinator.com/item?id=6936539 https://news.ycombinator.com/item?id=6936539 for previous discussion) > Signal is endorsed by NSA Uh, what? This isn't true.

prophesi 8y ago

Personally, the main rub for me is "Telegram's end-to-end encryption is not turned on by default," which null and voids all of this.

saagarjha 8y ago

> the client is open source 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: https://github.com/overtake/TelegramSwift/issues/163 https://github.com/overtake/TelegramSwift/issues/163

dijit 8y ago
Sorry, that's just not true. I have telegram-desktop (on Linux) which is unofficially distributed and compiled on my laptop via AUR[0], FDroid also has a version of telegram which is compiled from sources and not taken from pkg's released by the Telegram group, although they remove non-free parts apparently[1]. I'm not sure about iOS as I don't currently have the means to verify the content of my App Store iOS installed version of telegram, but the fact is that there are (at least) 2 client implementations commonly used that are compiled from source. [0]: https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/telegram-desktop https://git.archlinux.org/svntogit/community.git/tree/trunk/... [1]: https://www.reddit.com/r/fdroid/comments/9gmkob/why_is_telegram_in_f_droid/e6m2is5/ https://www.reddit.com/r/fdroid/comments/9gmkob/why_is_teleg...
- j16sdiz 8y ago
  how is it not true? the version in github works, but the version on play store different a lot from it..
  - dijit 8y ago
    >and the code posted to GitHub do not match; Well, I was challenging this assertion. "Does not match" what thing exactly? My point was that people are using the non-packaged versions (I mean, I'm not FOSS mad, I'm just a user and I'm using the FOSS version almost by accident). I would prefer the FOSS version to be 1:1 what is in the repo (or, even the upstream of the non-free version), but I see the situation as more chrome/chromium. We're not shitting on chrome for being "the most secure webbrowser" despite having non-free elements. Seemingly because large US tech companies deserve more respect than a guy who was essentially exiled from his country for not handing over his users data? Sounds like a double standard. Telegrams OSS edition works, so if they're sneaking things in it would have to be a backdoor, which would be INCREDIBLY damaging to their endeavour if it was found, and it would be relatively trivial to find too. So I'm not sure where this FUD is coming from. Making the argument about the server not being FOSS is valid though, but then if the E2EE is good enough on the client then the server is basically a relay and can't pilfer anything except metadata. (which, if we're honest, is what governments are after anyway)

zahllos 8y ago

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).

philsnow 8y ago

The crypto is not the problem, the UX is the problem. Any time there is opportunity for the user to be confused, they will be. It's ultimately the user's responsibility to make sure their comms are secure, so it's probably prudent to choose an app that presents the cleanest, least confusing path. Nobody (really) complains about PGP's crypto, but there are dozens of articles rightly criticizing its 80s-era "UX".

K2L8M11N2 8y ago

This[0] is why the challenge is bunk. [0]: https://web.archive.org/web/20171213214126/https://moxie.org/blog/telegram-crypto-challenge/ https://web.archive.org/web/20171213214126/https://moxie.org...

throwawaymath 8y ago

Explaining this will require setting up a bit of terminology. I'm not going to comment on Telegram's security because I don't want to get involved in a Signal-Telegram flame war. But I can at least explain why the contest is a poor methodology for ascertaining the security of a cryptosystem. To begin, when researchers publish or analyze cryptographic algorithms, they model the interaction of legitimate users and adversaries. Two legitimate users will engage in communication and an adversary will sit "in the middle", trying to break ciphertext confidentiality or authenticity (or both). Generally the adversary is allowed to tamper with or reply messages from Alice to Bob and vice versa. Adversaries are alsl given various capabilities of interacting with the cryptosystem and messages therein, and if the cryptosystem is secure against an ever more capable adversary, we say it is "____-secure." Researchers model the interactions in this way to more closely approximate real world, repetitive usage instead of an isolated simulacra. So let's talk about cryptanalytic attacks. There are known plaintext, chosen plaintext, known ciphertext and chosen ciphertext attacks. The attack always has a ciphertext, so known ciphertext is the lowest form (least assured) level of cryptanalysis. A known plaintext attack gives the attacker a corresponding ciphertext and a plaintext. A chosen plaintext attack affords the attacker the ability to use an encryption oracle to encrypt arbitrary plaintexts and see the ciphertexts. And likewise, a chosen ciphertext (the most powerful attack) allows an adversary to decrypt arbitrary ciphertexts. The Telegram contest requires you to provide the plaintext corresponding to a single ciphertext. You are not given access to real time encryption or decryption within a channel and you are not provided with the ability to attempt cryptanalysis on numerous messages. You can't even tamper with messages or try to replay them, because you have an isolated ciphertext to examine. Everything else is outside the scope of the contest. That means the only thing you're allowed to do is a known ciphertext attack. A known ciphertext attack is extremely difficult to pull off even for weak cryptography and it does not resemble the structure of a real world attack. For example, legitimate attacks on TLS are not known ciphertext attacks. That's why the Telegram contest is synthetic. Again, I'm not going to comment on its actual security. But if you want to do real cryptanalysis, you hire a team of cryptographers who didn't design the thing and try to break it with a more generous suite of capabilities that better resemble real world scenarios. The critiques from the cryptographic community should be examined on their own merits, and not judged according to whether or not they've successfully broken something under a known ciphertext attack.

toss1 8y ago

The state actors who have the serious requirements to break into Telegram have zero care about the bug bounty. Moreover it is in their interest that the vulnerabilities remain in the wild. Meanwhile, the bug bounty contests are limited time, several times. Good for publicity, but hard for individual actors to capitalize upon (more likely to take on-and-off work over a long period).

geofft 8y ago

> If it's not secure, then surely people would be cashing in on that sweet money. Because that's not how cryptography works. Remember that there is no mathematical proof that working cryptography even exists. Cryptography relies on "one-way trap-door functions," i.e., functions that cannot be inverted unless you have the secret key, and the existence of one-way trap-door functions implies P ≠ NP. Because we have no proof of P ≠ NP and it may well turn out to be the case that P = NP (surprising as it might be), we have no proof that cryptography is even possible. So, what do cryptographers actually mean? In practice they mostly mean that something has been subject to attacks for years and the public mathematical / cryptanalytic community hasn't found any cracks in the armor. We expect RSA to be secure because people have been working on efficient factoring since at least when we named the P vs. NP problem and arguably for centuries and we haven't made any real progress. We expect block ciphers and hashing algorithms to be secure because they're subject to public scrutiny. The last time we had a contest for a hash function https://en.wikipedia.org/wiki/NIST_hash_function_competition https://en.wikipedia.org/wiki/NIST_hash_function_competition, there were multiple good finalists, none of which were cracked in their entirety. They each were refined as people found attacks against artificially weakened versions of the functions, on the grounds that attacks get stronger over time. And even so only one was endorsed, and even so consensus is, as far as I can tell, to use a newly strengthened version of one of the finalists (BLAKE2) instead of the actual winner (Keccak). And certainly nobody would recommend using any of the other finalists, simply because the attention of the public research community is no longer on them, even though they haven't been publicly broken. It is very easy to make up an encryption algorithm or cryptosystem, run a contest for a few months, and not find a winner. That falls far short of the standards professional cryptographers have for solid cryptography. As with hash functions, it may be the case that nobody has found a specific weakness in Telegram's crypto, but using it when it's not the focus of research / not built on the best primitives the research community has to offer is unnecessary risk. > Signal is endorsed by NSA Please provide evidence of this. As far as I know, this is a lie.