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
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/...
[1]: https://www.reddit.com/r/fdroid/comments/9gmkob/why_is_teleg...
I’ll save you the work: Telegram has updated more often that this repository[1] has been committed to, so the code is perpetually out of date, if it ever shipped at all (apparently it doesn’t compile?). The author has mentioned[2] that they will open source their new client once it has been released, but that promise has not been kept.
the version in github works, but the version on play store different a lot from it..
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)
Chrome is not GPL.
You can also compile the official client yourself.
I mean, I could, but the Telegram developers being so opaque about this doesn’t make me feel like this is a good use of my time.
> There are many implementations already.
As far as I can tell, the only implementations for the platforms I care about are the “official” ones (in the sense that they are placed under some random person’s GitHub account and linked to by the Telegram website).
> You can also compile the official client yourself.
I have never been able to get this to work. Either way, what I compile from the “sources” they have put online and what they are shipping are two different things.
Telethon (https://github.com/LonamiWebs/Telethon) is a decent up to date (with MTProto) independent clean-room client implementation in the form of a Python lib.
You might consider trying to take care about it.
" The founder of chat app Telegram has publicly claimed that feds pressured the company to weaken its encryption or install a backdoor.
He said, During our team's 1-week visit to the US last year we had two attempts to bribe our devs by US agencies + pressure on me from the FBI. "
https://www.theregister.co.uk/2017/06/14/telegram_boss_backd...
That’s good…
> there's code in GitHub that you can compile and run a working client
No, not really. The code pushed to GitHub doesn’t really compile and the author of the project is quite unhelpful in resolving these issues.
> Whether updates are being dropped in a timely fashion or not does not change anything.
It does: the project is licensed under the GPL, and in a sense “benefits” from having the name of the license associated with their product. But they are not compliant with software licenses, they’re basically source-available maybe possibly if you beg them enough, except also the sources they publish cannot be verified to and likely do not correspond to what they are currently shipping. For a project who’s entire goal should be increasing trust in their product’s security, keeping the development process opaque and violating open source licenses (in addition to their adoption of custom crypto, which I will ignore for this because I cannot comment on it) does not inspire trust at all. Plus it’s just plain annoying.
Which means we must trust Telegram developers to not sell out our data to corrupt law enforcement agencies.
The service is free. Which means they would need to get profitable. Which means they would parse the chats or are already doing it.
Sorry, do you have source for this claim?
>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.
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.
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.
> Signal is endorsed by NSA
Uh, what? This isn't true.
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.
The relationship between Signal and the State Department is solely one of funding, not of technical interaction, let alone technical endorsement.
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.
Open Whisper Systems is an independent project, receiving grants and donations through the fiscal sponsorship of the Freedom of the Press Foundation. Last year, the Signal Foundation was created and funded by the aforementioned large donation from Brian Acton, which will take over this role once the IRS approves its 501(c)(3) charitable status.
That money will, minus whatever portion the Freedom of the Press Foundation keeps to cover its overhead, be spent on Signal. And donations for Signal to this foundation are tax-deductible to the extent 501(c)(3) charitable donations usually are.
I have no connection with any of the people, projects, or organizations we've been discussing. But I am the president of another fiscal sponsor 501(c)(3) nonprofit in the free/open source software space, so I'm very familiar with this model.
Nobody (really) complains about PGP's crypto, but there are dozens of articles rightly criticizing its 80s-era "UX".
[0]: https://web.archive.org/web/20171213214126/https://moxie.org...
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, 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.
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).
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.
When I see the equivalent done for Telegram I'll start taking the claims seriously, until then it's just noise.
> Telegram regularly has contests to break its encryption with a reward of 300K USD
> If it's not secure, then surely people would be cashing in on that sweet money.
Like I said in my first comment, all I'm doing is explaining why a contest requiring known ciphertext attacks is not evidence of cryptographic security. You originally spoke to this point, and I am responding about that point in particular because it's a topic I know intimately well.
You can double down on your second point about there being no published exploits; that's not something I can confidently speak to. I think there are reasonable counterpoints citing serious vulnerabilities are not always publicized, but I'll leave it to others to discuss that point.
It's not my goal to convince you that Telegram is insecure. What is important from my perspective is that you understand contests are in fact contrived and noisy, and should not be considered evidence of cryptographic security whatsoever.
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).
In terms of issues with each of these, Wire has occasional bugs and hiccups (UX wise) and would be unsuitable for large groups exchanging messages (every device implies an entirely new ratchet, users own multiple devices, and all Wire group chats are client-fan-out, meaning pairwise ratchets with all members. Users with more than one device, even if they communicate one-on-one, are effectively in a group session). However the group message problem implies trade-offs and doesn't have an easy solution, so this shouldn't be seen as game-ending criticism (there's an ongoing effort involving people from all three messengers to figure out group messaging in a safe and scalable way, called Message Layer Security). WhatsApp is much more feature stable, but compromises on client-fan-out to make group messaging simpler. I think Signal also does client fan-out. I think Signal were also a bit dismissive of the low order point issue in their protocol (https://research.kudelskisecurity.com/2017/04/25/should-ecdh...), but it's arguable whether this is an issue at all their instantiation of DH (https://moderncrypto.org/mail-archive/curves/2017/000896.htm...). So in terms of cryptography, all three are state-of-the-art.
I haven't really used Threema, but for completeness I had a brief look at their crypto "whitepaper". In it they say:
"Due to the inherently asynchronous nature of mobile messengers, providing reliable Forward Secrecy on the end-to-end layer is difficult. Key negotiation for a new chat session would require the other party to be online before the first message can be sent. Experimental schemes like caching pre-generated temporary keys from the clients on the servers increase the server and protocol complexity, ... Due to these and the following considerations, Threema has implemented Forward Secrecy on the transport layer only..."
This means Threema's forward secrecy is based entirely on TLS and doesn't apply to the end-to-end exchange. Also, Signal, Wire and WhatsApp use variants of Signal Protocol and these do pre-keying. It's hardly experimental.
There are other considerations and arguments you can make, such as jurisdiction, use of phone numbers, openness of code, who the parent company is and whether they have a voracious love for hoarding data to rival the NSA, federation etc. I'll leave those. I was responding mostly to the "if you can't break it it's obviously secure" challenge.
tl;dr for a normal person against the average adversary or an only vaguely-interested well-if-we-can-collect-it-why-not NSA, any of Signal, WhatsApp or Wire would be fine.
Say what you will about Telegram, but at least you're getting what's advertised. WhatsApp is a complete black box that's owned by a predatory company whose business is selling user data.
Telegram regularly has contests to break its encryption with a reward of 300K USD 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...