[HN Gopher] Subverting Telegram's end-to-end encryption (2023)
___________________________________________________________________
Subverting Telegram's end-to-end encryption (2023)
Author : pona-a
Score : 93 points
Date : 2025-10-14 15:23 UTC (7 hours ago)
(HTM) web link (tosc.iacr.org)
(TXT) w3m dump (tosc.iacr.org)
| ethin wrote:
| 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.
| jansper39 wrote:
| > 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.
| dijit wrote:
| 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
| hiimkeks wrote:
| D) They don't enable E2EE for groups at all
|
| E) (I believe) don't enable E2EE with more than one device
| dijit wrote:
| D) True aside from group calls afaik
|
| E) Neither does Whatsapp/Signal; they rely on a backdoor
| interface to your phone to send messages.
| tptacek wrote:
| Signal very definitely does multiparty end-to-end secure
| messaging.
| dijit wrote:
| 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.
| mahemm wrote:
| 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.
| dijit wrote:
| > 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.
| rockskon wrote:
| It does work. How do you think Signal desktop works?
| dijit wrote:
| 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.
| porridgeraisin wrote:
| Whatsapp doesn't need a connection to your phone anymore
| either. It used to be the case until a few years ago
| though.
| fsflover wrote:
| E) Yet it works fine on Matrix.
| skeledrew wrote:
| 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.
| fsflover wrote:
| Your complains are quite vague. It seems to be working
| fine for me.
| the_gipsy wrote:
| Too much candy is unhealthy.
| crtasm wrote:
| Signal desktop can send & receive messages while your
| phone is off, so that doesn't seem correct.
| dijit wrote:
| Oh, hey, TIL:
| https://news.ycombinator.com/item?id=15596980
|
| Wonder how that works then? Weird.
| fsflover wrote:
| F) They don't allow E2EE on GNU/Linux, including phones and
| desktop.
| tptacek wrote:
| I like how you sandwiched "the encryption story is bad"
| between two irrelevant social claims.
| s17n wrote:
| 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.
| BoredPositron wrote:
| 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
| asacrowflies wrote:
| Seems pretty cognizant of the modd of entire HN front page
| past few weeks honestly
| BoredPositron wrote:
| I don't care I didn't subscribe to anything from him. I'd
| rather take a Coldplay album than political opinions.
| ur-whale wrote:
| > with a doomer manifest
|
| Can you point at anything in his message that's not
| factually correct?
| simion314 wrote:
| >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.
| skeledrew wrote:
| 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.
| a57721 wrote:
| 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).
| jazzyjackson wrote:
| There is a grossly sexist omission in "built by our
| fathers"
| skeledrew wrote:
| 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.
| eitally wrote:
| 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.
| weberer wrote:
| D) They moved to the enshittification phase and started
| displaying ads
| celsoazevedo wrote:
| 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.
| hiimkeks wrote:
| Well, the article is from 2023, but what you remember is most
| likely MTProto version 1, which was even more ridiculously
| broken, iirc
| ProofHouse wrote:
| telegram is NOT safe. Far from it.
| tptacek wrote:
| 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.
| ynoxinul wrote:
| *for direct messages in secret chats, which you have to enable
| explicitly and which reduces user expericence in comparison to
| normal chats.
| fsflover wrote:
| *only on non-GNU/Linux systems.
| dijit wrote:
| 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
| fsflover wrote:
| 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
| dijit wrote:
| 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.
| fsflover wrote:
| > 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.
| dijit wrote:
| I'm not aware if it's official or not, but to be clear, I
| _like_ that telegram allows open source and alternative
| clients.
| dijit wrote:
| 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.
| tptacek wrote:
| 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.
| dijit wrote:
| 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.
| tptacek wrote:
| An adversary in the client/server cryptography model
| doesn't need a supply chain attack. They already have the
| cleartext.
| dijit wrote:
| 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.
| tptacek wrote:
| 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.
| dijit wrote:
| 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.
| tptacek wrote:
| 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.
| dijit wrote:
| 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.
| tptacek wrote:
| 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.
| dijit wrote:
| 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 pinata Slack is.
| Weak move.
| tptacek wrote:
| 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".
| dijit wrote:
| 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.
| the_gipsy wrote:
| Isn't the point of a protocol that you can bring your own,
| trusted clients?
|
| Aren't there other telegram clients?
| dijit wrote:
| Yep. Lots.
|
| * Plus Messenger (Google Play)
|
| * Nicegram (App Store/Google Play)
|
| * Nekogram (via TG channel or GitHub)
|
| * Neko X (f-droid)
|
| * Forkgram (f-droid)
|
| * Mercurrygram (f-droid)
|
| * AyuGram (both Desktop & Mobile)
|
| * 64Gram (Desktop/GitHub)
|
| * Kotatogram (Desktop/GitHub)
|
| everything listed here: https://telegram.org/apps
|
| and a bunch more that I don't remember off the top of my
| gead
| j45 wrote:
| 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.
| GranPC wrote:
| (2023)
| gruez wrote:
| 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.
| tptacek wrote:
| 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.
| supermatou wrote:
| 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...
| defraudbah wrote:
| and another one from king of encryption in golang
|
| The Most Backdoor-Looking Bug I've Ever Seen
|
| https://words.filippo.io/telegram-ecdh/
| upofadown wrote:
| Note that this is about MTProto 1 and not the MTProto 2 under
| consideration here.
| emptysongglass wrote:
| Yeah this one isn't relevant at all to the current protocol
| version.
| r721 wrote:
| HN discussion (2024):
| https://news.ycombinator.com/item?id=41350530
| dang wrote:
| Thanks! Macroexpanded:
|
| _Is Telegram really an encrypted messaging app?_ -
| https://news.ycombinator.com/item?id=41350530 - Aug 2024 (583
| comments)
| godelski wrote:
| 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.
| yesco wrote:
| 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.
| codedokode wrote:
| > Since it has a public API, I can easily make a custom
| frontend if I ever want to.
|
| Note that you need to get an API key for that, and there
| are additional conditions for getting it (for example, you
| cannot remove ads in your version, you cannot remove
| Instagram-like "stories", and so on).
| taminka wrote:
| 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
| tptacek wrote:
| People have found vulnerabilities in MTProto.
| sedatk wrote:
| IIRC, they had even started out with basic mistakes like MAC-
| then-encrypt.
| dijit wrote:
| 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.
| taminka wrote:
| > 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 :)
| chupasaurus wrote:
| 1,2) NIH syndrome 3) We don't know 4) Expropriation isn't
| "basically stolen", Telegram was a tiny side project at the
| time
| defraudbah wrote:
| 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
| upofadown wrote:
| 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...
| cimi_ wrote:
| 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.
___________________________________________________________________
(page generated 2025-10-14 23:01 UTC)