No end-to-end encryption by default. WhatsApp has.
No end-to-end encryption for groups. WhatsApp has.
No end-to-end encryption on desktop. WhatsApp has.
No break-in key-recovery. WhatsApp has.
Inferring Telegram's security from public statements of *checks notes* former KGB officer and FSB director -- agencies that wrote majority of the literature in maskirovka, isn't exactly reliable, wouldn't you agree?
Telegram has private chats. I don't pay attention to his words, indeed. Way before the Ukrainian war, Russia had a massive campaign trying to block Telegram and they failed on a technical level. This has never happened with WhatsApp.
>I know the default assumption with Telegram is that they can read all your messages
The client is open source. It's trivial to verify this is 100% factually happening. They have access to every group message. Every desktop message. Every message by default. If you enable secret chats for 1:1 mobile chats, you are now disclosing to Telegram you're actively trying to hide something from them, and if there ever was metadata worth it for Keith Alexander to kill someone over, it's that.
>they seem less cooperative and I never got the notion that they ever read private messages until the Macron incident
Thus, I wouldn't be as much concerned about what they're handing EUROPOL, but what they're handing FSB/SVR.
Even if Telegram never co-operated with Russian intelligence, who here thinks Telegram team, that can't pull off the basic thing of "make everything E2EE" that ~all of its competition has successfully done, can harden their servers against Russian state sponsored hackers like Fancy Bear, who obviously would never make noise about successful breach and data exfiltration.
>How come they are able to be this exception despite not having end to end encryption by default?
They've pushed out lie about storing cloud chats across different servers in different jurisdictions. Maybe that scared some prosecutors off. Or maybe FVEY is inside TG's servers too, and they don't like the idea of going after users as that would incentivize deployment of usable E2EE.
Currently, the Russian government is trying to squeeze people out of Telegram and move them over to MAX: https://caspianpost.com/regions/russia-tightens-telegram-res...
WhatsApp also operates in Russia, despite Instagram and Facebook being banned. So I wouldn't count on its E2EE either.
Signal still requires a phone number and proprietary Google blobs on mobile. Many third-party Telegram clients exist - Signal allows none.
The real story is, MAX is there to scare people into Telegram. Durov isn't your friend, neither is Putin who doesn't bother blocking connections to the server.
>So I wouldn't count on its E2EE either.
This is the worst way to assses E2EE deployment. 5D-chess.
>Signal still requires a phone number and proprietary Google blobs on mobile.
Telegram also requires a phone number. If you didn't have double standards, I bet you'd have no standards.
>Many third-party Telegram clients exist
The official implementation and default encryption matters. 99.99% just assume Telegram is secure because Putin supposedly tries to block it. They don't know it's not E2EE. And no third party TG desktop client offers cross-platform E2EE or E2EE groups. IIRC there's exactly one desktop client that tries to offer E2EE 1:1 chats but that's not seamless. TG has no idea how to make seamless E2EE like Signal.
You ignoring that Signal is both open source and always E2EE and complaining about it's "proprieatry blobs" yet looking past TG's atrocious E2EE speaks volumes.
>This is the worst way to assses E2EE deployment. 5D-chess.
How would you explain the fact that WhatsApp remains unblocked in Russia, when all other major messengers except Telegram and Meta's own products all got banned there?
>Telegram also requires a phone number. If you didn't have double standards, I bet you'd have no standards.
Not my point. I'm pointing out a flaw that both messengers share.
>TG has no idea how to make seamless E2EE like Signal.
Because it's never seamless. Loading your messages on Signal can take quite a while. Also if you receive a message over 2 weeks ago without checking your phone in the meantime, you may as well have never received it.
>You ignoring that Signal is both open source and always E2EE and complaining about it's "proprieatry blobs" yet looking past TG's atrocious E2EE speaks volumes.
Why are you ignoring the fact Signal actively prohibits third-party clients? Why the air quotes on proprieatry blobs? Yes, Telegram is far from perfect, and inferior to Signal when it comes to E2EE. But what makes you reject the proprieatry blob claim when it's true? Because your favorite messenger is being attacked?
Yeah Telegram only has 1:1 opt-in E2EE, that you can't use across your devices, so either you or your buddy quickly gets tired of whipping out their phone when they're sitting at their laptop, and just replies you through Telegram's non-E2EE cloud chats, and that's the backdoor. The user activated it. It's "their fault".
>I don't really see how it's possible to mitigate client compromise.
You could of course offload plaintext input and output along with cryptographic operations and key management to separate devices that interact with the networked device unidirectionally over hardware data diodes, that prevent malware from getting in or getting the keys out.
Throw in some v3 Onion Services for p2p ciphertext routing, and decent ciphersuite and you've successfully made it to at least three watch lists just by reading this. Anyway, here's one I made earlier https://github.com/maqp/tfc
Signal protocol prevents replay attacks as every message is encrypted with new key. Either it's next hash ratchet key, or next future secret key with new entropy mixed via next DH shared key.
Private keys, probably not. WhatsApp is E2EE meaning your device generates the private key with OS's CSPRNG. (Like I also said above), exfiltration of signing keys might allow MITM but that's still possible to detect e.g. if you RE the client and spot the code that does it.
Wouldn't ratchet keys prevent MITM too? In other words if MITM has your keys and decrypts your message, then your keys are out of sync from now on. Or do I misunderstand that?
The ratchets would have different state yes. The MITM would mix in different entropy into the keys' states. It's only detectable if the MITM ever stops. But since the identity key exfiltration only needs to happen once per lifetime of installation (longer if key is backed up), the MITM could just continue forever since it's just a few cycles to run the protocol in the server. You can then choose whether to read the messages or just ignore them.
One interesting way to detect this would be to observe sender's outgoing and recipient's incoming ciphertexts inside the client-to-server TLS that can be MITM'd by users. Since the ratchet state differs, so do the keys, and thus under same plaintext, so do the ciphertexts. That would be really easy way to detect MITM.
Whatsapp didn't implement Signal's protocol verbatim. They appropriated the core cryptographic security and then re-implemented the rest on their own servers. This removes all guarantees of secrecy as long as they can run arbitrary code on the servers they own.
Nice! Hey, question: I noticed Signal at one point had same address on Google Play Store as WA. Can you tell us if Signal devs shared office space with WA during integration of the Signal protocol? Related to that, did they hold WA devs' hand during the process, meaning at least at the time it was sort of greenlighted by Moxie or something. If this is stuff under NDA I fully understand but anything you can share I'd love to hear.
Well the thing is, the key exfiltration code would probably reside outside the TCB. Not particularly hard to have some function grab the signing keys, and send them to the server. Then you can impersonate as the user in MITM. That exfiltration is one-time and it's quite hard to recover from.
I'd much rather not have blind faith on WhatsApp doing the right thing, and instead just use Signal so I can verify myself it's key management is doing only what it should.
Speculating over the correctness of E2EE implementation isn't productive, considering the metadata leak we know Meta takes full advantage of, is enough reason to stick proper platforms like Signal.
> That exfiltration is one-time and it's quite hard to recover from.
Not quite true with Signal's double ratchet though, right? Because keys are routinely getting rolled, you have to continuously exfiltrate the new keys.
No I said signing keys. If you're doing MITM all the time because there's no alternative path to route ciphertexts, you get to generate all those double-ratchet keys. And then you have a separate ratchet for the other peer in the opposite direction.
Last time I checked, by default, WhatsApp features no fingerprint change warnings by default, so users will not even notice if you MITM them. The attack I described is for situations where the two users would enable non-blocking key change warnings and try to compare the fingerprints.
Not saying this attack happens by any means. Just that this is theoretically possible, and leaves the smallest trail. Which is why it helps that you can verify on Signal it's not exfiltrating your identity keys.
Ah right, I didn't think about just outright MitMing from the get-go. If WhatsApp doesn't show the user anything about fingerprints, then yeah, that's a real hole.
Not that I trust Facebook or anything but wouldn’t a motivated investigator be able to find this key exfiltration “function” or code by now? Unless there is some remote code execution flow going on.
WhatsApp performs dynamic code loading from memory, GrapheneOS detects it when you open the app, and blocking this causes the app to crash during startup. So we know that static analysis of the APK is not giving us the whole picture of what actually executes.
This DCL could be fetching some forward_to_NSA() function from a server and registering it to be called on every outgoing message. It would be trivial to hide in tcpdumps, best approach would be tracing with Frida and looking at syscalls to attempt to isolate what is actually being loaded, but it is also trivial for apps to detect they are being debugged and conditionally avoid loading the incriminating code in this instance. This code would only run in environments where the interested parties are sure there is no chance of detection, which is enough of the endpoints that even if you personally can set off the anti-tracing conditions without falling foul of whatever attestation Meta likely have going on, everyone you text will be participating unknowingly in the dragnet anyway.
"Many forms of dynamic code loading, especially those that use remote sources, violate Google Play policies and may lead to a suspension of your app from Google Play."
I don’t know these OS’s well enough. Can you MitM the dynamic code loads by adding a CA to the OS’s trusted list? I’ve done this in Python apps because there’s only 2 or 3 places that it might check to verify a TLS cert.
>Not that I trust Facebook or anything but wouldn’t a motivated investigator be able to find this key exfiltration “function” or code by now?
Yeah I'd imagine it would have been found by know. Then again, who knows when they'd add it, and if some future update removes it. Google isn't scanning every line for every version. I prefer to eliminate this kind of 5D-guesswork categorically, and just use FOSS messaging apps.
Something that wasn't mentioned in the article - if you're coming from Windows and using Foobar2000, you'll want DeadBeeF https://deadbeef.sourceforge.io/
Do Foobar2000 Components work with WINE? I try installing components on MacOS and they say Nope, only Windows is supported for this plugin. My workaround is to use Ableton Live and Bluehole (for audio routing) but it is CPU expensive.
No end-to-end encryption for groups. WhatsApp has.
No end-to-end encryption on desktop. WhatsApp has.
No break-in key-recovery. WhatsApp has.
Inferring Telegram's security from public statements of *checks notes* former KGB officer and FSB director -- agencies that wrote majority of the literature in maskirovka, isn't exactly reliable, wouldn't you agree?
reply