Very secure servers are openly documented (Kerckhoff's principle).
Snake oil purporting itself as secure is always very hush hush and comes with claims of security.
Besides, other messengers like Signal have already made the server open source, and they have native clients that end-to-end encrypt everything, so you don't even have to trust server.
Durov requiring you to trust the server shows he has no idea how to build secure systems. He and his team are amateurs in security engineering.
Telegram offering bells and whistles that leaks everything to the service provider is not an argument for Telegram the same way "it launches the video game" isn't an argument for video game cracks that carry ransomware.
Both are called Trojan Horses and are considered malware.
The bigger issue is Telegram advertises it as more private option to WhatsApp although Telegram collects more metadata, and also the message content. People think Telegram is more private, they don't use it as a public forum replacement. Also, institutions running Telegram have people form closer working groups that become groups for friends, who don't necessarily realize they should be moving to Signal the moment the members start sharing things they don't want everyone to know.
Yup but the issue is Telegram already has two separate groups, normal groups (3-200 users), and supergroups (200-200,000 users). For end-to-end encrypted groups, Threema supports 256 members, Signal 1000, Wire 2000, and Matrix has no upper limit. Surely Telegram could deploy E2EE for normal groups. Nobody assumes groups with more than 200 members are private anyway.
>Durov who supposedly lives in exile has visited Russia over 50 times
Durov's exile marketing makes him look like he's Alexei Navalny. Navalny was a true dissident and critic and he was first poisoned, and then later arrested when he returned. He was was then imprisoned and he died in prison.
Durov has been visiting Russia more than I've been visiting my friends over the same period. Him returning to Russia that many times shows he isn't really living in exile. He's not on the run, and he's not getting arrested when he visits Russia. The disparity between the stories forces one to ask, is he working with the Russian government instead. He can prove he isn't by deploying ubiquitous end-to-end encryption, until then there's very little reason to suspect he isn't, again given the mismatch between what's claimed (the exile) and what's happening behind the scenes (the visits the public doesn't know about).
That article doesn't even mention the cracking contest. The XOR-nonce bug was also found by Valsorda in 2021 https://words.filippo.io/telegram-ecdh/ so looks like that 2013 post you linked to never even led to a fix during the EIGHT years. No idea if it still exists.
Also, you can't be racist towards Russian government that's OBVIOUSLY evil. From Navalny, to Bucha, to bombing hospitals, to kidnapping children, to the illegal war in the first place.
I'm not going to speak for the author of that article. But I agree with his conclusion. Telegram is indistinguishable from a honeypot.
In the world of infosec, stuff isn't secure until someone proves you wrong (which you reject assuming racism). Stuff is secure when you prove it's secure.
Practically every major secure messaging app vendor has proven they can not be a honeypot, by end-to-end encrypting their communications, offering open source clients with public key fingerprints to verify that end-to-end encryption is working correctly.
Telegram hasn't done that. Telegram's lack of end-to-end encryption, paired with zero effort for metadata protection (not even stuff like sealed sender) shows they don't give a damn about actual security.
But what they do is also what an FSB op would do.
* It would advertise "heavily encrypted" and bash WhatsApp day after day convincing average Janes and Joes about it being really really secure, and confuse readers who take a closer look, with claims of all chats using MTProto but also calling both client-server and end-to-end encryption protocols MTProto.
* It would construct a narrative that the face of the app is a rebel dissident in exile.
* It would be banned temporarily or poorly
* It's role would be obfuscated by releasing an obviously backdoored app like Max, to make Telegram seem safe compared to it. Like Russian intelligence really believed they could use Max to monitor Russian dissidents. FSB isn't dumb. Russian military deception is world famous. https://en.wikipedia.org/wiki/Russian_military_deception
The backdoor sits in the fact nothing is end-to-end encrypted, groups can't be E2EE, but troll army can still defend it, claiming it does have 1:1 E2EE if you want. Yes, it does, if you really want the highest friction UX possible. People try and drop secret chats when they want to be able to alt-tab into the conversation instead of digging into their phones 100 times a day. This backdoor is ingenious because the users can only blame themselves when their 1:1 messages end up to the server.
A good messaging app creator knows this, so they make E2EE default so that users don't encounter such friction. E.g. Signal allows you to have E2EE 1:1 and group chats between all of your devices. That's what proper privacy by design looks like. Would Telegram do that, they would've proven they stand for their users, and I'd actually recommend them.
Data is a toxic asset. Even if Telegram isn't a honeypot, it's a massive data collecting apparatus, that has all that data sit on its servers, from which the hacking team of any major intelligence agency can access it en mass. That's the life of 1B users worldwide. So ultimately, it doesn't even matter if Telegram is a honeypot, it's equally usable to https://en.wikipedia.org/wiki/Fancy_Bear or NSA TAO or whoever.
This isn't about hating on Russians. This is about Durov not passing the minimum bar of what modern secure communication is about.
You've so far claimed telegram is the best with nothing to back that claim, ignored every counter argument, attacked argument of someone other than me, and you're now replaying Russian government shill tactics to try to rally people behind you for emotional reasons, when I'm explicitly giving technical critique.
>telegram is the safest encrypted messaging app. Period, full stop.
Yes, let's see
* Not end-to-end encrypted by default
* No end-to-end encrypted groups
* No end-to-end encryption on any desktop client by the vendor, forcing cross-platform users to drop secret chats. This includes 81% of working age people who sit on their computer during work day, and 100% of college students and IT workers.
* Lacks ALL metadata protection from server like phone number, IP-address and thus geolocation, contact list, group memberships, quantity and schedule of communication, data types. In fact --
* Secret chats leak additional metadata about intent to hide content from TG as the vendor.
In this context "heavily" means "we can't legally claim it's end-to-end encrypted because it's not".
Also it's not even post quantum, so it's not heavy. Telegram's Diffie-Hellman breaks instantly with a quantum computer large enough to run Shor against it.
Also, the keys sit on the servers' RAM, no matter what they lie. There is no global distributed RAM system, especially one that encrypts data in distributed fashion and works at the negligible latencies that Telegram boasts.
Probably not. It's been ~13 years when Snowden said what the NSA is doing is going around the encryption by hacking endpoints. Post quantum cryptography doesn't change any of that. You can still lift TLS keys with exploits for transparent MITM. I'd imagine it's much better ROI to look for vulnerabilities with Mythos, than to attack the algorithms.
PSA: https://dr.loudness-war.info/ is a great place to look for info on dynamic range of releases, and also, a great place to find new music with excellent dynamic range.
What are you hinting here? Surely you can make a positive claim with evidence to back it? A CEO of a big project like SimpleX wouldn't stoop as low as Pavel Durov?
Same guy, always pretending we've never had the same discussion over and over here, Reddit and privacyguides, for years. You're always running away.
>The protocol is designed to provide packet-level anonymity
Anything you do to harden SimpleX on server side does not matter to user. Unless the client protects the user it's not really helpful. The user only has your word that the server is stripping the IP address from the package.
> so that neither of the servers can see which IP address talks to which IP address
Two computers that could be run by the same entity. Also, the entire public infrastructure is again either Akamai or Runonflux. 50% of SimpleX chats' metadata is accessible by a single company, which is not even you so you have no control over it.
>always choose server operated by another operator, to mitigate collusion risks.
How does Alice, Bob and Charlie choose a third VPS provider when there's only two?
>My problem with Tor is that after all these years it takes zero steps to prevent collusion and data sharing by Tor node operators [...] that independent parties run relays in the circuit - is simply untrue
I don't know how to tell you this, but 10,000 Tor relays is absolutely more diverse than two VPS provider companies.
You're already supporting Tor. You're already running Onion Service servers.
How about you stop running to the mountains once again, go visit what I wrote to you in the PrivacyGuides threads on Cwtch vs SimpleX and actually consider that.
>If people want to use Tor, it's their choice, and the app supports it. But we won't be integrating it.
Then maybe it's time to strip the "no identifiers" bullshit from your marketing language. If you can't be open upfront about the client leaking the IP-address and you're not fixing the leak, I have zero problems referring to you as the snake oil you are.
The point is there is no public key capability in BB84 that requires pre-sharing a symmetric key.
You absolutely do get forward secrecy with pre-shared keys. You just need to make the protocol derive the next key with a cryptographic hash function, and deliver the iteration count with the packet so the recipient knows which key is the correct one. This is called a SCMIP or hash ratchet, and it's used e.g. in Signal protocol.
(As implementation details, you'll also want to hash the hash ratchet counter with the key to prevent theoretical loops, and you'll probably want to encrypt the ratchet counter during delivery with static header key, or the very least authenticate it.)
QKD is interesting from the PoV of perfect secrecy. But AFAIK with e.g. BB84, the basis orientation communication (used to detect OTP delivery eavesdropping) is done with Wegman-Carter (unconditionally secure) authentication using... a pre-shared key.
So if you're only interested in computational security that is post-quantum, why not pre-share a symmetric key for some AEAD scheme? You'll get forward secrecy with hash ratchet and neither provides future secrecy in principle.
Neither solves the bootstrap and QKD requires a really, really expensive and complex infrastructure just to provide perfect secrecy which we're fine without.
Plus the company likes to advertise their product as more metadata-private than Tor Onion Service based messaging apps like Cwtch.
They lie by omission when they say that the service doesn't have any user IDs. What they really mean is, the application does not add its own long term identifiers. But by default, the application takes zero steps to anonymize your IP address from the server, meaning the server can very probably tell users apart.
It's also ridiculous that the entire public server infrastructure is hosted under two companies: Akamai and Runonflux. Roughly 50% of your conversations can be end-to-end correlated by a single VPS company.