For people who only read the headline, it's not as bad as the title might suggest. This attack requires backdooring the client, by which point it's already effectively game over in most threat models. The main advantage of this attack is that a compromised client can be sending "encrypted" messages that can actually be trivially decrypted by authorities, but that isn't immediately obvious to someone inspecting network traffic. Needless to say, this is a pretty pointless attack because nobody is manually inspecting every piece of data that their telegram is sending, and the client probably makes so many requests that it's trivial to smuggle data through some other side channel.
The threat model of the attack is targets relying on binary/source transparency of open source clients to protect against (state-sponsored) client backdoors; in that sense, it most closely resembles the Juniper/NetScreen Dual-EC attack, which functioned basically the same way: a backdoor that was essentially not auditable, as the underlying vulnerability was realized cryptographically.
I'm just clarifying. I agree the practical implications of the attack are not really meaningful to a general audience.
I was gonna post "why do people keep calling it 'encrypted' if the encryption is not on by default?" It has always seemed odd to me that it is put into the same category as WhatsApp and Signal (which even those are a bit weird to compare).
What confuses me more is how passionate people are about Telegram. Weirdly I see those posts degrade into Signal vs Telegram and it really feels like apples and oranges but very one sided. I get that Telegram is more feature rich, and that's a good argument, but feels weird that many argue it is also more secure. Some of those arguments even appear in the thread r721 linked.
I like Telegram because it gets my friends & family to not do everything in SMS or iMessage. If I'm the only one using it, what's the point after all? Feature-wise, the app is nice to use, and one I can use on all platforms, even Linux.
Since it has a public API, I can easily make a custom frontend if I ever want to. Most social media does not offer this or tries to lock you into their shitty ecosystem.
I basically just treat it as unencrypted, but the pretend encryption features at least puts the company in a position where blatantly selling data would be a liability. In this respect, I place it on the same level as WhatsApp. Because even if WhatsApp has solid encryption, all it takes is one forced update from Meta to undo all that. They are like the inverse of each other.
My uncle is the only one I know who refused to use Telegram, insisting Signal was better and because he didn't want to use something with vague connections to Russia. Yet even he did not actually use Signal, and simply insisted if we should all switch to something it's either that or he sticks to SMS. So well, when I couldn't sell Signal to anyone else, Telegram it is, sorry uncle, but Verizon is pretty transparent about how they sell all my data.
in short, you don't need access to the device, only to the same network
if you are on the same network and manage either intercept key to bruteforce it or guess encryption key with emoji it's possible to decrypt the whole chat. It works because telegram random generator uses time and some device information which is predictable
the study managed to decrypt 500 messages out of 500 on emulator devices. Brutewforcing takes like a few $100 worth of computing power
Honestly, durovs are exceptional people and enterpreneurs, however their encryption and what they say isn't always what it presented as
can anyone explain why telegram doesn't use an audited e2e implementation? is it really because they wanted more convenient and faster cross-device sync? have they been threatened and/or backdoored by the fsb? they basically stole vk from him, but left him alone w/ telegram?
it's suspicious, but at the same time, iirc, nobody's been able to find a vulnerability in their encryption protocol :shrug
The first version of MTProto was found to have weaknesses.
The reason they rolled their own was because it came out before the Double-Ratchet/Axolotl protocol and OtR (which double-ratchet is essentially based on) was extremely inconvenient to use properly and had its own weaknesses.
> The reason they rolled their own was because it came out before the Double-Ratchet/Axolotl protocol and OtR (which double-ratchet is essentially based on) was extremely inconvenient to use properly and had its own weaknesses.
this actually makes a lot of sense lowkey, thanks :)
Reminder that Telegram has "end to end" encryption only for direct messages; the rest is client-server, which they seem to believe is just as good as end-to-end.
You screenshot doesn't show how you achieved this or that you're even using Linux. There is no option to start a secret chat for me on a right click. Where did you download your client?
I am using telegram-desktop from aur, I clicked the three dots (…) at the top next to the magnifying glass, then info (i) to get to the profile, then there is a “more” (…) button where there was a “Secret” option.
There are basically zero practicing cryptography engineers who would agree with the logic you've used here, but I acknowledge this is also someting Durov believes.
I know it's trite to bring in logical fallacies, but you're hinging a response on an appeal to authority without tackling the logic head on. Worse so, you're also engaging in a bit of hyperbole.
E2EE provides strong theoretical guarantee's, but not so if the client is under the network providers control. Governments have already pressured companies to alter clients (Australia's "Assistance and Access Act" allows compelling backdoors in software).
If you don't trust the operator, it's irrational to trust the client they supply, they can do anything before E2EE even kicks in.
I'm not saying E2EE is useless technology, it's just useless in cases where the provider and the network are the same thing. You are gaining very little over TLS in those cases. You can configure "self-deleting" messages if you're worried about other clients logging in.
Regardless, most reasonable security researches I know are actually more concerned with supply chain attacks than ensuring E2EE everywhere, which is precisely what I'm arguing.
That’s fair for a purely malicious provider in client/server mode (they’ve got the plaintext on the server, no fancy footwork needed), but that’s missing the forest: if the provider is adversarial, E2EE doesn’t magically fix it either. They control the client codebase and distribution (app stores, updates), so backdooring it to snag plaintext pre-encryption is trivial—it’s basically a built-in supply chain vuln they own.
Point is, E2EE only “protects” against server-side compromise if you assume the client is golden, which loops back to trusting the provider not to mess with it. If they’re bad actors, they can (and govts do compel them to) inject client-side leaks (again, see Australia’s TOLA Act forcing software mods), or historical cases like Lavabit’s key handover pressure.
In trusted-provider scenarios (which is most users’ reality), client/server + TLS + encrypted storage suffices against external threats, with less complexity than E2EE’s multi-device key mgmt headaches.
If distrust is total, bail! Because neither model’s your friend. Supply chain worries aren’t a distraction; they’re the real vector, as SolarWinds and Jia Tanning of xz remind us. E2EE’s great tech, but you are pretending that it is a cure-all, which ignores practical realities.
First, the setting for secure messaging cryptography assumes a compromised provider, so this is all entirely besides the point. But second, no, it's not exclusively a problem for a "purely malicious provider". It's also a problem for any provider that is compromised; a serverside compromise is completely fatal to the privacy of every user of a client-server-encrypted system.
There isn't an amount of hand-waving that's going to get you to a place where client-server-only encryption is sufficient for secure messaging.
I am also more concerned about supply chain attacks than I am about attacks on E2EE, generally. But that stops being true in the specific case of secure messaging.
The standard threat model for secure messaging does assume a potentially compromised provider.. that’s exactly why the client-trust issue matters.
If the provider is compromised (maliciously or via hack/subpoena), they can alter the client to capture data before E2EE engages, rendering it moot.
E2EE protects past messages from server-side access, sure, but it doesn’t prevent future compromises via client backdoors, which are a real vector under laws like Australia’s TOLA or US CLOUD Act, again: providers have been compelled to modify software (e.g., Lavabit’s resistance led to shutdown, but others comply quietly).
You’re right that client-server alone fails catastrophically on server compromise, but E2EE isn’t a panacea if the same actor controls the client supply chain.
Trust is binary: If you don’t trust the provider, don’t use their client. reproducible builds help a tiny fraction, but for most, it’s unverifiable.
In partial-trust scenarios (e.g., worrying about hacks but not full malice), client-server with distributed keys and TLS can suffice without E2EE’s complexities.
I’m hand-waving a bit here; but I’m talking about peoples actual realities, not some hypothetical.
How does E2EE hold up if a subpoena forces a silent client update? You won’t know, and history shows that’s the path of least resistance for adversaries.
Client supply chain is moot in the client-server setting. The attackers just target the server and get everything. You only get to raise the salience of the client supply chain when E2EE is already in place. Again: this is an analysis specific to secure messaging.
Slack isn't E2EE secure. The Slack client supply chain is not how I worry about my Slack message history being intercepted.
Re: Slack; yeah, that’s not apples-to-apples for secure 1:1 messaging (it’s enterprise group chat with admins often having god-mode access anyway).
A better comp might be old-school Skype pre-Microsoft: client-server backbone (after ditching full P2P), tight client/network control, no E2EE, yet no major leaks despite heavy scrutiny.
It worked for millions in a “good enough” threat model without pretending to be bulletproof. Secure messaging apps that default to client-server (like Telegram’s non-secret chats) are similar. They pay lip service to groups but prioritise 1:1, and the security theatre of optional E2EE doesn’t change the core trust calculus.
If you don’t trust the provider, don’t trust their code. Simple as.
The security model of Telegram is essentially that of Slack, plus a seldom-used direct E2EE messenger. You literally can't trust Slack or Telegram. You can opt not to trust Signal; I don't care. But it's at least an option.
Nice try sneaking Slack into a 1:1 secure messaging debate… That’s like comparing a corporate chatroom (with admin access) to a personal diary.
Telegram’s client-server default, with optional E2EE, is closer to pre-Microsoft Skype: tight client/network control, 1:1 focus, no major leaks despite a major spotlight on it for a decade+
You dodged Skype because it’s not the piñata Slack is. Weak move.
That's exactly the security model of Telegram. If you want to say "Skype", fine, Skype is also not a trustable secure messenger. I think we've reached an agreement.
Honestly pretty satisfying, I've never managed to drive an argument about Telegram being OK all the way to "Telegram is just as good as Skype".
You’re always so quick to call Signal the gold standard, but in reality, it’s not the untouchable system you claim.
I’d trust pre-Microsoft Skype, Telegram, and Signal about the same; none are bulletproof when the provider controls both client and server.
That’s the real crux, and you’re glossing over it. Skype pre-2011 ran TLS and encrypted storage, held up under global scrutiny with no major leaks, and matched Telegram’s client-server model with optional E2EE.
Post-Microsoft? it got gutted: NSA’s PRISM, Chinese eavesdropping, Mac OS X backdoors, the works.
This proves my point: when client and server are under one roof, a compromise, hack or coercion becomes possible.
Signal’s Double Ratchet E2EE, that locks down past and future messages against server breaches and its open-source code plus reproducible builds invite scrutiny that makes backdoors harder to hide, but here’s the truth: Signal’s client and server are still one entity and they have hid updates from users before. A malicious update, pushed via TOLA or CLOUD Act pressure, can snag plaintext before encryption, E2EE be damned.
Most users don’t verify builds. Transparency’s nice, but it’s not a forcefield. Telegram’s optional E2EE and Skype’s old-school TLS setup aren’t inherently worse for low-threat users who just need protection from external hacks, not state-level malice.
You’re waving Signal’s flag like it’s untouchable, but in practice, the provider’s grip on the client levels the playing field. That’s why I stick to OMEMO or OTR over XMPP or IRC: decentralised, battle-tested protocols that don’t chain me to one entity’s whims. I run them myself, no middleman, no trust roulette. Your “agreement” smells like a victory lap, but you’re dodging the real issue: single-entity control is the Achilles’ heel, not the protocol’s name.
I listened to bits of it and I was disappointed by the lack of push back from Lex who was supper excited because he got to hang out with Durov for a couple of weeks in Dubai - the tl;dr I got from what I heard is that Telegram is amazing and Durov is a visionary freedom fighter. Lex's recent history I'm not surprised though.
He claims: 'So, by the time the head of intelligence services met me to ask about Romania to help them silencing conservative voices in Romania, I was already wary of what can be going on next.'
I call bullshit on this. The 'conservative voices' are muppets doing Russia's bidding who broke all sorts of election laws. There was nothing serious happening on Telegram in Romania that would warrant any foreign intervention, it just doesn't make sense.
Is this really something new? If memory serves, Telegram has had it's own crypto since the beginning, and I don't remember anything about it ever being audited by... Well, anybody?
Granted, I don't know how MTProto actually works all that well, but IMO Telegram should've just used Noise or something. Would've saved them a lot of trouble. Although that doesn't really resolve the underlying problem that people think Telegram is secure when it's not (i.e., you have to explicitly enable E2EE and it's off by default), at least last time I checked. I haven't used telegram in years so my knowledge might be out of date though.
It was audited, found to have some serious flaws[0], then those were rectified.
Most people dislike Telegram because:
A) It takes away from Signals market share
B) They don't enable E2EE by default
C) They're owned by Pavel Durov, the Russian Zuckerberg.
I am aware that it's an unpopular opinion, but the FUD spread against Telegram and the hagiographies of Signal make me think something weird is going on.
Telegram has third party clients, so you can just roll your own client that runs another encryption on top if you want, like Pidgin used to do with OTR.
People in the US prefer Signal over Telegram because Signal was created by people who took security seriously, and Telegram wasn't.
People outside the US prefer telegram because they assume that Signal is probably compromised, or at least highly vulnerable to compromise, by US intelligence - they trust Pavel Durov's history of expropriation and arrest more than they trust some nerds who claim that our product is secure.
As someone that uses Telegram almost every day, the sad true is that most messages are not private. Most people simply don't use "secure chats". Not only it's not the default, but encrypted chats also don't work across devices.
So it shouldn't be a surprise that Signal users speak against Telegram. It's simply not private for most people. It's like recommending using Facebook Messenger (pre-E2EE)... privacy minded people won't do that. Signal itself is criticised by other more privacy minded users because it requires a phone number.
Signal doesn't have the best call quality (voice/video) especially on slow connections, sending media can be a pain in the rear, their desktop client is way too simple, they move slowly, etc. Telegram beats them in almost everything, but not privacy...
Between having to trust Durov forever with our texts and system that uses e2ee by default and may or may not (no proof) have some flaw, I think most people that want privacy will use the option that uses e2ee for everything.
I thought it worked the same as Whatsapp, whereby there's a sort of backdoor connection to the app running on your phone to send messages.
However, after doing a smidge more research it seems like somehow Signal is sharing it's key with the desktop app and only syncing history of messages directly: https://news.ycombinator.com/item?id=15596980
I'm not 100% sure how it works as the server is fake-open-source and not actual open-source.
I've tried to use Matrix a few times and eventually end up leaving. The idea is good, but it's just missing so many nice features that it kinda isn't worth the pain. Features that Telegram just keeps dropping like candy.
This really bugged me. I led adoption of Telegram as our family-internal standard chat tool several years ago because I was more anti-Zuck than I was concerned about backdoors or overt politicization of Telegram. Since the Ukraine war began, there has been literally no positive news about Telegram and Durov has become increasingly political (especially since his arrest in France) in his all-users blasts.
With the amount of known use of Telegram by unsavory actors, combined with Durov's own leveraging of his platform for activism, I've been using Whatsapp more and more lately, and don't feel bad about that.
I respect Signal, but it's missing too many product features and it doesn't have the reach Whatsapp does, so it's not compelling as a switching option at this point, even for family use.
I was pretty ticked off about this. I don't disagree with the message content itself, but having political content pushed to me is a big no-no. If this kind of thing keeps up I'll be dropping my premium sub.
One factual thing that looks off is "the UK is imprisoning thousands for their tweets". I'm not in the UK and not following closely the situation there, but "thousands", really? Genuine doubt, would love to see some evidence.
Otherwise, the "doomer manifest" is OK, but the comically inflated ego of Durov is annoying, him thinking that such banal and commonplace sentiments are worth pushing as an alert message to all users, wrapping everything into announcing his birthday (that he doesn't want to celebrate, oh no).
It's not about the content IMO; it's about the principle. Should not be sending content to users, unless they opted into said content being sent to them.
>Can you point at anything in his message that's not factually correct?
He also got involved in Romanian and Moldovan elections, by sending a message to target users in the day of the elections( when doing campaign is illegal) with claims he presented no evidence for, basically the bastard works for Ruzzia, he might be forced to but the facts do not lie.
For people who only read the headline, it's not as bad as the title might suggest. This attack requires backdooring the client, by which point it's already effectively game over in most threat models. The main advantage of this attack is that a compromised client can be sending "encrypted" messages that can actually be trivially decrypted by authorities, but that isn't immediately obvious to someone inspecting network traffic. Needless to say, this is a pretty pointless attack because nobody is manually inspecting every piece of data that their telegram is sending, and the client probably makes so many requests that it's trivial to smuggle data through some other side channel.
The threat model of the attack is targets relying on binary/source transparency of open source clients to protect against (state-sponsored) client backdoors; in that sense, it most closely resembles the Juniper/NetScreen Dual-EC attack, which functioned basically the same way: a backdoor that was essentially not auditable, as the underlying vulnerability was realized cryptographically.
I'm just clarifying. I agree the practical implications of the attack are not really meaningful to a general audience.
Excellent article about Telegram's encryption from Matt Green (cryptographer, for those who haven't heard of him):
https://blog.cryptographyengineering.com/2024/08/25/telegram...
I was gonna post "why do people keep calling it 'encrypted' if the encryption is not on by default?" It has always seemed odd to me that it is put into the same category as WhatsApp and Signal (which even those are a bit weird to compare).
What confuses me more is how passionate people are about Telegram. Weirdly I see those posts degrade into Signal vs Telegram and it really feels like apples and oranges but very one sided. I get that Telegram is more feature rich, and that's a good argument, but feels weird that many argue it is also more secure. Some of those arguments even appear in the thread r721 linked.
I like Telegram because it gets my friends & family to not do everything in SMS or iMessage. If I'm the only one using it, what's the point after all? Feature-wise, the app is nice to use, and one I can use on all platforms, even Linux.
Since it has a public API, I can easily make a custom frontend if I ever want to. Most social media does not offer this or tries to lock you into their shitty ecosystem.
I basically just treat it as unencrypted, but the pretend encryption features at least puts the company in a position where blatantly selling data would be a liability. In this respect, I place it on the same level as WhatsApp. Because even if WhatsApp has solid encryption, all it takes is one forced update from Meta to undo all that. They are like the inverse of each other.
My uncle is the only one I know who refused to use Telegram, insisting Signal was better and because he didn't want to use something with vague connections to Russia. Yet even he did not actually use Signal, and simply insisted if we should all switch to something it's either that or he sticks to SMS. So well, when I couldn't sell Signal to anyone else, Telegram it is, sorry uncle, but Verizon is pretty transparent about how they sell all my data.
HN discussion (2024): https://news.ycombinator.com/item?id=41350530
Thanks! Macroexpanded:
Is Telegram really an encrypted messaging app? - https://news.ycombinator.com/item?id=41350530 - Aug 2024 (583 comments)
and another one from king of encryption in golang
The Most Backdoor-Looking Bug I’ve Ever Seen
https://words.filippo.io/telegram-ecdh/
Yeah this one isn't relevant at all to the current protocol version.
Note that this is about MTProto 1 and not the MTProto 2 under consideration here.
in short, you don't need access to the device, only to the same network
if you are on the same network and manage either intercept key to bruteforce it or guess encryption key with emoji it's possible to decrypt the whole chat. It works because telegram random generator uses time and some device information which is predictable
the study managed to decrypt 500 messages out of 500 on emulator devices. Brutewforcing takes like a few $100 worth of computing power
Honestly, durovs are exceptional people and enterpreneurs, however their encryption and what they say isn't always what it presented as
In a very real sense you do need access to the device to install the backdoored client.
There is no actual cryptographic weakness presented here...
can anyone explain why telegram doesn't use an audited e2e implementation? is it really because they wanted more convenient and faster cross-device sync? have they been threatened and/or backdoored by the fsb? they basically stole vk from him, but left him alone w/ telegram?
it's suspicious, but at the same time, iirc, nobody's been able to find a vulnerability in their encryption protocol :shrug
People have found vulnerabilities in MTProto.
IIRC, they had even started out with basic mistakes like MAC-then-encrypt.
1,2) NIH syndrome 3) We don't know 4) Expropriation isn't "basically stolen", Telegram was a tiny side project at the time
The first version of MTProto was found to have weaknesses.
The reason they rolled their own was because it came out before the Double-Ratchet/Axolotl protocol and OtR (which double-ratchet is essentially based on) was extremely inconvenient to use properly and had its own weaknesses.
> The reason they rolled their own was because it came out before the Double-Ratchet/Axolotl protocol and OtR (which double-ratchet is essentially based on) was extremely inconvenient to use properly and had its own weaknesses.
this actually makes a lot of sense lowkey, thanks :)
Reminder that Telegram has "end to end" encryption only for direct messages; the rest is client-server, which they seem to believe is just as good as end-to-end.
*for direct messages in secret chats, which you have to enable explicitly and which reduces user expericence in comparison to normal chats.
*only on non-GNU/Linux systems.
You've said this a lot in this thread, but my client on Arch seems to have secret chats.
https://i.imgur.com/Pft8r3B.png
You screenshot doesn't show how you achieved this or that you're even using Linux. There is no option to start a secret chat for me on a right click. Where did you download your client?
This ticket suggests that there's no such option: https://github.com/telegramdesktop/tdesktop/issues/871
See also: https://github.com/telegramdesktop/tdesktop/issues/6491
Those are the same link and they’re 10 years old.
I am using telegram-desktop from aur, I clicked the three dots (…) at the top next to the magnifying glass, then info (i) to get to the profile, then there is a “more” (…) button where there was a “Secret” option.
> telegram-desktop from aur
Thanks, this looks interesting. However, it seems unofficial. There's no such option in the official client from telegram.org.
> Those are the same link
Thanks, I fixed that.
I’m not aware if it’s official or not, but to be clear, I like that telegram allows open source and alternative clients.
It's weird that you can delete a message for you and for the other person too.
I doubt client-server is the only way to accomplish this.
client-server is good enough, if you trust the server.
If you don't trust the server, then you shouldn't trust them to supply you a client either. Since a client is basically "whatever code they decided".
Very few people are building from FOSS, and those that do will include binary blobs too. It's theatre.
There are basically zero practicing cryptography engineers who would agree with the logic you've used here, but I acknowledge this is also someting Durov believes.
I know it's trite to bring in logical fallacies, but you're hinging a response on an appeal to authority without tackling the logic head on. Worse so, you're also engaging in a bit of hyperbole.
E2EE provides strong theoretical guarantee's, but not so if the client is under the network providers control. Governments have already pressured companies to alter clients (Australia's "Assistance and Access Act" allows compelling backdoors in software).
If you don't trust the operator, it's irrational to trust the client they supply, they can do anything before E2EE even kicks in.
I'm not saying E2EE is useless technology, it's just useless in cases where the provider and the network are the same thing. You are gaining very little over TLS in those cases. You can configure "self-deleting" messages if you're worried about other clients logging in.
Regardless, most reasonable security researches I know are actually more concerned with supply chain attacks than ensuring E2EE everywhere, which is precisely what I'm arguing.
An adversary in the client/server cryptography model doesn't need a supply chain attack. They already have the cleartext.
That’s fair for a purely malicious provider in client/server mode (they’ve got the plaintext on the server, no fancy footwork needed), but that’s missing the forest: if the provider is adversarial, E2EE doesn’t magically fix it either. They control the client codebase and distribution (app stores, updates), so backdooring it to snag plaintext pre-encryption is trivial—it’s basically a built-in supply chain vuln they own.
Point is, E2EE only “protects” against server-side compromise if you assume the client is golden, which loops back to trusting the provider not to mess with it. If they’re bad actors, they can (and govts do compel them to) inject client-side leaks (again, see Australia’s TOLA Act forcing software mods), or historical cases like Lavabit’s key handover pressure.
In trusted-provider scenarios (which is most users’ reality), client/server + TLS + encrypted storage suffices against external threats, with less complexity than E2EE’s multi-device key mgmt headaches.
If distrust is total, bail! Because neither model’s your friend. Supply chain worries aren’t a distraction; they’re the real vector, as SolarWinds and Jia Tanning of xz remind us. E2EE’s great tech, but you are pretending that it is a cure-all, which ignores practical realities.
First, the setting for secure messaging cryptography assumes a compromised provider, so this is all entirely besides the point. But second, no, it's not exclusively a problem for a "purely malicious provider". It's also a problem for any provider that is compromised; a serverside compromise is completely fatal to the privacy of every user of a client-server-encrypted system.
There isn't an amount of hand-waving that's going to get you to a place where client-server-only encryption is sufficient for secure messaging.
I am also more concerned about supply chain attacks than I am about attacks on E2EE, generally. But that stops being true in the specific case of secure messaging.
The standard threat model for secure messaging does assume a potentially compromised provider.. that’s exactly why the client-trust issue matters.
If the provider is compromised (maliciously or via hack/subpoena), they can alter the client to capture data before E2EE engages, rendering it moot.
E2EE protects past messages from server-side access, sure, but it doesn’t prevent future compromises via client backdoors, which are a real vector under laws like Australia’s TOLA or US CLOUD Act, again: providers have been compelled to modify software (e.g., Lavabit’s resistance led to shutdown, but others comply quietly).
You’re right that client-server alone fails catastrophically on server compromise, but E2EE isn’t a panacea if the same actor controls the client supply chain.
Trust is binary: If you don’t trust the provider, don’t use their client. reproducible builds help a tiny fraction, but for most, it’s unverifiable.
In partial-trust scenarios (e.g., worrying about hacks but not full malice), client-server with distributed keys and TLS can suffice without E2EE’s complexities.
I’m hand-waving a bit here; but I’m talking about peoples actual realities, not some hypothetical.
How does E2EE hold up if a subpoena forces a silent client update? You won’t know, and history shows that’s the path of least resistance for adversaries.
Client supply chain is moot in the client-server setting. The attackers just target the server and get everything. You only get to raise the salience of the client supply chain when E2EE is already in place. Again: this is an analysis specific to secure messaging.
Slack isn't E2EE secure. The Slack client supply chain is not how I worry about my Slack message history being intercepted.
Re: Slack; yeah, that’s not apples-to-apples for secure 1:1 messaging (it’s enterprise group chat with admins often having god-mode access anyway).
A better comp might be old-school Skype pre-Microsoft: client-server backbone (after ditching full P2P), tight client/network control, no E2EE, yet no major leaks despite heavy scrutiny.
It worked for millions in a “good enough” threat model without pretending to be bulletproof. Secure messaging apps that default to client-server (like Telegram’s non-secret chats) are similar. They pay lip service to groups but prioritise 1:1, and the security theatre of optional E2EE doesn’t change the core trust calculus.
If you don’t trust the provider, don’t trust their code. Simple as.
The security model of Telegram is essentially that of Slack, plus a seldom-used direct E2EE messenger. You literally can't trust Slack or Telegram. You can opt not to trust Signal; I don't care. But it's at least an option.
Nice try sneaking Slack into a 1:1 secure messaging debate… That’s like comparing a corporate chatroom (with admin access) to a personal diary.
Telegram’s client-server default, with optional E2EE, is closer to pre-Microsoft Skype: tight client/network control, 1:1 focus, no major leaks despite a major spotlight on it for a decade+
You dodged Skype because it’s not the piñata Slack is. Weak move.
That's exactly the security model of Telegram. If you want to say "Skype", fine, Skype is also not a trustable secure messenger. I think we've reached an agreement.
Honestly pretty satisfying, I've never managed to drive an argument about Telegram being OK all the way to "Telegram is just as good as Skype".
You’re always so quick to call Signal the gold standard, but in reality, it’s not the untouchable system you claim.
I’d trust pre-Microsoft Skype, Telegram, and Signal about the same; none are bulletproof when the provider controls both client and server.
That’s the real crux, and you’re glossing over it. Skype pre-2011 ran TLS and encrypted storage, held up under global scrutiny with no major leaks, and matched Telegram’s client-server model with optional E2EE.
Post-Microsoft? it got gutted: NSA’s PRISM, Chinese eavesdropping, Mac OS X backdoors, the works.
This proves my point: when client and server are under one roof, a compromise, hack or coercion becomes possible.
Signal’s Double Ratchet E2EE, that locks down past and future messages against server breaches and its open-source code plus reproducible builds invite scrutiny that makes backdoors harder to hide, but here’s the truth: Signal’s client and server are still one entity and they have hid updates from users before. A malicious update, pushed via TOLA or CLOUD Act pressure, can snag plaintext before encryption, E2EE be damned.
Most users don’t verify builds. Transparency’s nice, but it’s not a forcefield. Telegram’s optional E2EE and Skype’s old-school TLS setup aren’t inherently worse for low-threat users who just need protection from external hacks, not state-level malice.
You’re waving Signal’s flag like it’s untouchable, but in practice, the provider’s grip on the client levels the playing field. That’s why I stick to OMEMO or OTR over XMPP or IRC: decentralised, battle-tested protocols that don’t chain me to one entity’s whims. I run them myself, no middleman, no trust roulette. Your “agreement” smells like a victory lap, but you’re dodging the real issue: single-entity control is the Achilles’ heel, not the protocol’s name.
(2023)
Lex Friedman recently did an interview with Durov: https://lexfridman.com/pavel-durov/
I listened to bits of it and I was disappointed by the lack of push back from Lex who was supper excited because he got to hang out with Durov for a couple of weeks in Dubai - the tl;dr I got from what I heard is that Telegram is amazing and Durov is a visionary freedom fighter. Lex's recent history I'm not surprised though.
Here's the transcript of the section about encryption: https://lexfridman.com/pavel-durov-transcript#chapter15_encr... I'll let you judge for yourself.
I'll comment on another section though because I'm somewhat knowledgeable having followed the subject closely in the media and by knowing the country: https://lexfridman.com/pavel-durov-transcript#chapter7_roman...
He claims: 'So, by the time the head of intelligence services met me to ask about Romania to help them silencing conservative voices in Romania, I was already wary of what can be going on next.'
I call bullshit on this. The 'conservative voices' are muppets doing Russia's bidding who broke all sorts of election laws. There was nothing serious happening on Telegram in Romania that would warrant any foreign intervention, it just doesn't make sense.
Is this really something new? If memory serves, Telegram has had it's own crypto since the beginning, and I don't remember anything about it ever being audited by... Well, anybody?
Granted, I don't know how MTProto actually works all that well, but IMO Telegram should've just used Noise or something. Would've saved them a lot of trouble. Although that doesn't really resolve the underlying problem that people think Telegram is secure when it's not (i.e., you have to explicitly enable E2EE and it's off by default), at least last time I checked. I haven't used telegram in years so my knowledge might be out of date though.
Well, the article is from 2023, but what you remember is most likely MTProto version 1, which was even more ridiculously broken, iirc
> Granted, I don't know how MTProto actually works all that well
I suppose it's what the actual goals of the app are, potentially it works out very well for someone.
It was audited, found to have some serious flaws[0], then those were rectified.
Most people dislike Telegram because:
A) It takes away from Signals market share
B) They don't enable E2EE by default
C) They're owned by Pavel Durov, the Russian Zuckerberg.
I am aware that it's an unpopular opinion, but the FUD spread against Telegram and the hagiographies of Signal make me think something weird is going on.
Telegram has third party clients, so you can just roll your own client that runs another encryption on top if you want, like Pidgin used to do with OTR.
[0]: https://mtpsym.github.io
People in the US prefer Signal over Telegram because Signal was created by people who took security seriously, and Telegram wasn't.
People outside the US prefer telegram because they assume that Signal is probably compromised, or at least highly vulnerable to compromise, by US intelligence - they trust Pavel Durov's history of expropriation and arrest more than they trust some nerds who claim that our product is secure.
As someone that uses Telegram almost every day, the sad true is that most messages are not private. Most people simply don't use "secure chats". Not only it's not the default, but encrypted chats also don't work across devices.
So it shouldn't be a surprise that Signal users speak against Telegram. It's simply not private for most people. It's like recommending using Facebook Messenger (pre-E2EE)... privacy minded people won't do that. Signal itself is criticised by other more privacy minded users because it requires a phone number.
Signal doesn't have the best call quality (voice/video) especially on slow connections, sending media can be a pain in the rear, their desktop client is way too simple, they move slowly, etc. Telegram beats them in almost everything, but not privacy...
Between having to trust Durov forever with our texts and system that uses e2ee by default and may or may not (no proof) have some flaw, I think most people that want privacy will use the option that uses e2ee for everything.
D) They don't enable E2EE for groups at all
E) (I believe) don't enable E2EE with more than one device
D) True aside from group calls afaik
E) Neither does Whatsapp/Signal; they rely on a backdoor interface to your phone to send messages.
Signal desktop can send & receive messages while your phone is off, so that doesn't seem correct.
Oh, hey, TIL: https://news.ycombinator.com/item?id=15596980
Wonder how that works then? Weird.
Signal very definitely does multiparty end-to-end secure messaging.
Weird, every time I mention Signal on HN tptacek responds.
But I'm having trouble discerning what you mean.
Either you're saying group chats are encrypted E2EE - which, I never claimed.
Or, you're mentioning that you can have multiple phones/devices on the same account, which doesn't work the last time I checked.
You replied to a claim that Telegram doesn't do E2EE for groups saying 'Neither does Whatsapp/Signal'.
That's wrong as `tptacek noted. If you meant something else, that wasn't clear.
> E) (I believe) don't enable E2EE with more than one device
my response was:
> E) Neither does Signal/Whatsapp.
The thread of the "E" topic is relevant here, i'm not claiming that Signal/Whatsapp support (or do not support) encryption for group chats.
Sorry that it wasn't clear, I thought referring to them directly by letter would make it easier to differentiate.
It does work. How do you think Signal desktop works?
I thought it worked the same as Whatsapp, whereby there's a sort of backdoor connection to the app running on your phone to send messages.
However, after doing a smidge more research it seems like somehow Signal is sharing it's key with the desktop app and only syncing history of messages directly: https://news.ycombinator.com/item?id=15596980
I'm not 100% sure how it works as the server is fake-open-source and not actual open-source.
Whatsapp doesn't need a connection to your phone anymore either. It used to be the case until a few years ago though.
E) Yet it works fine on Matrix.
I've tried to use Matrix a few times and eventually end up leaving. The idea is good, but it's just missing so many nice features that it kinda isn't worth the pain. Features that Telegram just keeps dropping like candy.
Your complains are quite vague. It seems to be working fine for me.
F) They don't allow E2EE on GNU/Linux, including phones and desktop.
I like how you sandwiched "the encryption story is bad" between two irrelevant social claims.
D) They moved to the enshittification phase and started displaying ads
I mean Durov is going down the deep end in the last few weeks. Messaging all Telegram user with an Emergency feature with a doomer manifest.
https://t.me/durov/452
This really bugged me. I led adoption of Telegram as our family-internal standard chat tool several years ago because I was more anti-Zuck than I was concerned about backdoors or overt politicization of Telegram. Since the Ukraine war began, there has been literally no positive news about Telegram and Durov has become increasingly political (especially since his arrest in France) in his all-users blasts.
With the amount of known use of Telegram by unsavory actors, combined with Durov's own leveraging of his platform for activism, I've been using Whatsapp more and more lately, and don't feel bad about that.
I respect Signal, but it's missing too many product features and it doesn't have the reach Whatsapp does, so it's not compelling as a switching option at this point, even for family use.
I was pretty ticked off about this. I don't disagree with the message content itself, but having political content pushed to me is a big no-no. If this kind of thing keeps up I'll be dropping my premium sub.
> with a doomer manifest
Can you point at anything in his message that's not factually correct?
One factual thing that looks off is "the UK is imprisoning thousands for their tweets". I'm not in the UK and not following closely the situation there, but "thousands", really? Genuine doubt, would love to see some evidence.
Otherwise, the "doomer manifest" is OK, but the comically inflated ego of Durov is annoying, him thinking that such banal and commonplace sentiments are worth pushing as an alert message to all users, wrapping everything into announcing his birthday (that he doesn't want to celebrate, oh no).
It's not about the content IMO; it's about the principle. Should not be sending content to users, unless they opted into said content being sent to them.
There is a grossly sexist omission in "built by our fathers"
>Can you point at anything in his message that's not factually correct?
He also got involved in Romanian and Moldovan elections, by sending a message to target users in the day of the elections( when doing campaign is illegal) with claims he presented no evidence for, basically the bastard works for Ruzzia, he might be forced to but the facts do not lie.
Seems pretty cognizant of the modd of entire HN front page past few weeks honestly
telegram is NOT safe. Far from it.