Why you should stop reading Durov's blog posts

Why you should stop reading Durov's blog posts

maqp

This article debunks Durov's irrational blog post used as a weapon in online debates. The quoted parts are from the original article:


I've been getting this question more often this year. It's based on the wrong assumption that some other popular messaging apps such as WhatsApp are "end-to-end encrypted by default", while Telegram is not. This post is intended to disprove this myth that has been so carefully crafted by Facebook/WhatsApp marketing efforts. Let’s start from the basics.

So right from the start Durov starts with what is called "pivot and deflect": Shift from original disliked question (why doesn't Telegram use E2EE) and draw attention to something you want to cast attention to: "Instead of answering why Telegram isn't E2EE by default, let's discuss a single competing product and its problems regarding its E2EE."

A central theme in Durov's article is whataboutism, that quoting Wikipedia

...attempts to discredit an opponent's position by charging them with hypocrisy without directly refuting or disproving their argument. It is particularly associated with Soviet and Russian propaganda.

Furthermore, to quote John Oliver:

Whataboutism, the practice of changing the subject to someone else's perceived wrongdoing. This technique of saying "What about" is actually an old soviet propaganda tool and the reason it is dangerous is because it implies that all all actions regardless of context share a moral equivalency and since nobody's perfect, all criticism is hypocritical and everybody should do whatever they want.

Could Pavel Durov have received training such propaganda? Possibly.

According to New York Times

Pavel Durov trained in propaganda, studying Sun Tzu, Genghis Khan and Napolen, and he learned to make posters aimed at influencing foreign soldiers.

According to DLD,

In 2005, Pavel completed his training at the Faculty of Military Studies of St. Petersburg State University with a specialization in Propaganda and Psychological Warfare.

To get back to the topic.


It's based on the wrong assumption that some other popular messaging apps such as WhatsApp are "end-to-end encrypted by default"

We need to replace the "it" pronoun to make this statement clear

The question "why isn't Telegram E2EE by default?" is based on the wrong assumption that some other popular messaging apps such as WhatsApp are E2EE by default

What Durov claims here is "People only ask why Telegram is not E2EE, because they incorrectly think WhatsApp is E2EE." This is not true. When people learn Telegram is not E2EE, they want to know why. When people learn WA is not end-to-end encrypted, they also want to know why. Just because WA uses flawed E2EE mechanism, doesn't mean that because neither is perfect, all criticism is invalid and Telegram should be allowed to do whatever they want.


This post is intended to disprove this myth that has been so carefully crafted by Facebook/WhatsApp marketing efforts.

Why is a blog post under "'Why isn't Telegram End-to-End Encrypted by Default?'" written to disprove the claim that WhatsApp is end-to-end encrypted? A reasonable post is allowed to draw comparisons between apps, but this sounds whataboutism at its finest. Also, the writing provides no proof that the concerns expressed towards Telegram's security originate to Facebook's marketing efforts.


Every popular messaging app offers its users some way to back up their messages to prevent data loss. Messaging apps that ignore backups (such as Wickr/Signal/Confide) never reach 1M DAU and remain niche.

It is true many users prefer a possibility to backup their messages. The question is, how this will be done. Dismissing Signal for its smaller user-base is no proof of its lack of security. Nor is it proof that safe backup mechanisms cannot be implemented.


As for popular apps such as WhatsApp, Viber and Line, they rely on Apple iCloud and Google Drive to store their users' message history and prevent data loss in case their users lose their smartphones.

No denying this, although I will point out I've successfully avoided the backups for years. I just take two seconds to select "never" when the nagger pops up every few weeks. It's annoying and shouldn't exist, but I'll live.


These backups are not e2e-encrypted and get decrypted whenever the user buys a new phone and restores their WhatsApp/Viber/Line message history.

This is also true, but Hume's guillotine states,"you can't derive ought from is". Durov's expertise shows when he talks about "e2e-encrypted backups". The "end-to-end encryption" for backed-up messages is the wrong term. A cloud-backup where only the user can access content is called client-side encryption.


It is entirely possible to create a client-side encrypted cloud backup system for end-to-end encrypted messages. Here's how:

1. When you setup the client you ask the user to enter the cloud backup passphrase. To ensure security, you should attempt to measure the entropy and only allow +80-bit passphrase.

2. Your client generates a salt, and using a slow hash function such as Argon2, your client derives a client-side encryption key from the passphrase and salt. The purpose of the slow hash is to slow down key derivation, which has the same effect of using stronger password.

3. Your client then sends copies of all sent and received messages to the service, encrypted on the client-side, using the Argon2 derived key. The salt will also be stored on the server.

4. When you want to restore the backup, you will fetch the salt and encrypted backups from the cloud, derive the decryption key from salt and passphrase using Argon2, and decrypt the backups locally.

The reality is a bit more complex than that, but that just bores down to implementation details.


If setting up a single passphrase for backups sounds troublesome, consider the fact Telegram highly recommends you to do that anyway, in the form of cloud passwords. The difference is, cloud passwords only prevent random hacker that steals your confirmation SMS from the TELCO network from accessing your account. It does not prevent someone from accessing your data if they a) are Telegram staff, or b) hack the server to access the content.

It is true e.g. WhatsApp with cloud-backups turned on is as insecure as Telegram cloud chats (3rd party can see message content), but again, a single bad implementation does not mean you can not have secure cloud backups (I already showed you how to do that above), and it also does not mean Telegram couldn't implement one themselves if they had the expertise to implement basic cryptographic protocols.


While it may seem that you, as a user, have the freedom to opt out of these backups, in reality there’s little room for choice: even if you opt out (which is unusual and sometimes tricky), people you chat with most likely won’t.
This creates a situation when messages you send and receive end up not e2e-encrypted in the cloud without you even realizing it. You have zero transparency on what is really e2e-encrypted and what is backed up. You rely on e2e encryption and trust the “no third party can access my messages” mantra, but your private data is in fact vulnerable to hackers and governments that can get access to it via the cloud storage. If you think this is a minor threat, think again: according to stats WhatsApp shared during Google IO last year, most of the “e2e-encrypted” chats on WhatsApp eventually get backed up and stored in the cloud, not e2e-encrypted."

This is true, a system that uses bad opt-in backup mechanism is dangerous if your peers neglect proper security practices. The only thing that could be worse would be if the service provider did that choice for you. Which is the case with Telegram group chats, and cross-platform one-on-one chats. Secret Chats are safe both from the IM server and from cloud backups which is great, but unless secret chats are possible everywhere, you're not really able to opt-out of cloud-backups. You still need to have group chats, and with WhatsApp, there's perhaps a 1% chance everyone in the group has backups disabled. With Telegram, the service forces that chance to 0%. And again, there's no secret chats to help you when it comes to groups.

The quoted section basically ends with the message "You can't have client-side encrypted backups with WhatsApp anyway, so you might as well send all that data to us, we'll keep it more secure. Pinky promise."


There is the argument that if users are aware that their messages are not protected from third parties, they will self-censor accordingly, and that they will be more safe. This sounds plausible, but there's two problems.

 Firstly, the amount of users who associate Telegram's chats with security without understanding the first thing about computer security is staggering. I major in computer science, and I can't count the number of times fellow CS students have been astounded to hear Telegram isn't E2EE by default. They've just assumed it's secure because they hear Telegram mentioned in the same news article as Signal: "...encrypted messengers like Signal, WhatsApp, or Teleggram...".

Secondly, people don't know who's reading their messages, because they don't know which entities may have compromised the server to eavesdrop on their messages. Telegram server is a very, very tempting target (I'll get back to this later). When you don't know who's listening, you can't be sure what you can or can not say. Furthermore, there is very high risk that the messages will leak, eventually. It only needs to happen once. The Telegram server architecture is proprietary and there's no way to guarantee this will never happen. If all messages were end-to-end encrypted, and proper client-side encryption for backups was always used, we wouldn't have to worry about this.


WhatsApp's approach has other architectural drawbacks that invalidate end-to-end encryption for 99% of private conversations, but in this post I’ll focus mainly on backups for simplicity.

The source for the "99%" states the following:

"WhatsApp aggressively pushes users to enable backups to third-party services by Apple and Google. Even if you don't backup your messages, it is extremely likely that your chat partners are doing so. It is likely that they don‘t even remember dismissing an annoying notification with a “yes” a long time ago. The interface provides no way of knowing whether or not your messages are being backed up. Meanwhile, for group chats of five members, there’s a 99% probability that all messages are stored on Apple‘s or Google’s servers in the US."

The "other architectural drawbacks" aren't discussed by the source. The entire chapter only talks about backups. The 99% are not sourced from anywhere or calculated by the citation. Durov is citing made-up statistics without implying it's a conjecture.


Moving on to "How Niche Messaging Apps Handle Backups".

Users don’t want to lose their entire message history when they lose/change their phones so apps of this kind never become massively popular.

"Never" is a strong word. Signal is gaining popularity although not at the rate of Telegram. Telegram's problem is security doesn't keep evolving, and without E2EE-by default, it's much faster to create new features. But there are only so many features users are going to need. Signal has been pushing secure features at slow rate. Eventually it will be as feature-complete as Telegram. At some point phones and networks will be fast enough to make large E2EE group chats seem instantaneous. At that point Telegram can only compete by making features more secure, but at that point, they will stumble on the fact E2EE can not be glued on top, every feature needs to be built with E2EE in mind. This is why it takes time for Signal to implement new features: it's hard.


...such as Secret Chats in Telegram or their copycat versions in Viber or Facebook Messenger

A copycat secret chat tries to give the impression Telegram is the original inventor of E2EE, but in reality you should call Telegram's secret chat a copycat of OTR-messaging: End-to-end encryption for instant messaging has existed since ~2004. Telegram's E2EE isn't an original concept, and protocol-wise, the E2EE WhatsApp and Facebook Messenger use (Signal protocol), is much more secure. It's of course not possible to verify implementation of Signal protocol in proprietary software, but the point I'm trying to make here is, Signal-protocol used by these clients is not trying to copy anything from Telegram's secret chats, although Durov seems to imply that.


"Consequence of (1) – people using these apps can be targeted by governments as those who have something to hide. Due to the limited distribution of such apps, the government can identify and track individuals whose phones connect to the corresponding IP addresses. This is something that is already happening in case of tools like Tor, and, to a lesser extent, of some messaging apps. Yasha Levine is publishing a brilliant investigation about it."

This is a serious problem and the only way to avoid that is for everyone to use them. Here's a problem: it's easier for state level actors to target Telegram users who opt-in for E2EE secret chats, than it is to single out users who use ubiquitous E2EE e.g. Signal provides. Telegram server knows which users use end-to-end encryption, and thus, any governmental entity who hacks the server also knows which users use E2EE. That's not the case e.g. with Signal, because everyone knows every message from cookie recipe to top secret documents from whistleblower to journalist transit through the same encryption. Nobody's setting up secret chat just so that they can discuss mundane things, so using secret chats reveals intention to hide.

To my knowledge, no statistics have ever been released about how many people actually use secret chats. Whether it actually is used (especially when you can't continue the E2EE conversation once you sit down, put your phone in your pocket, and open your laptop to get some work done), or whether it's just a glued-on-top feature used to furiously defend the insecure parts of the app in internet feuds.

The Telegram Way

"Back in 2013, when we were launching Telegram, we carefully considered both approaches. We knew we didn’t want to violate our users’ privacy by shifting the responsibility for their data to third-party backups like WhatsApp or Viber do. Neither did we want to deprive our users of functionality that they enjoyed in other apps and doom Telegram to join the ranks of niche apps."

The users are rightfully concerned about all third parties. The first party is me. The second party is my friend. The third party is everyone else, and they have no business reading my messages. This includes

  • the ISP and network backbone service providers. For that TLS is enough security
  • Google/Apple as cloud backup provider. For that, I need to keep refusing WhatsApp backups and hope my friends do the same.
  • the messaging service provider, whether it's Telegram, Signal, or WhatsApp. TLS encryption only protects you until data hits the messaging service provider's server. To protect you at that point, you need end-to-end encryption.

This is because

  1. The service provider can at will sell that data. It can do it legally (if stated in their ToS or if the ToS changes -- something Telegram reserves the right to do) or illegally (if they think they won't get caught). Telegram doesn't do either of those (we hope).
  2. Any messaging service provider who doesn't end-to-end encrypt by default also makes creates a treasure dove of private messages, up for grabs to anyone who hacks the server. Thus even if Durov doesn't have malicious intentions, he's playing into the hands of state-level actors who are most interested about the billions of group messages that can not be end-to-end encrypted, even when the users would want to.
So after some research we decided to introduce 2 kinds of chats – Secret chats and Cloud chats. Secret chats are e2e-encrypted chats that never under any circumstances get backed up. Cloud chats are encrypted in the same way, but also have a built-in cloud backup. Cloud chats are designed for the majority of users – the majority that in another app like WhatsApp would rely on less secure third-party backup storage. Unlike what you have in niche apps, the traffic between cloud chat users and secret chat users on Telegram is mixed (the encryption is the same in both cases, but in cloud chats our servers do have access to the encryption key), so individuals can not be singled out and targeted based on the fact that they use secret chats and thus have something to hide.

Now, this is where things get interesting. This requires careful dissection.

Secret chats are e2e-encrypted chats that never under any circumstances get backed up.

This is true. Telegram uses a protocol called MTProto for end-to-end encryption.

Cloud chats are encrypted in the same way, but also have a built-in cloud backup.

Here's how the reader understands this: "Cloud chats are e2e-encrypted chats, that also have a built-in cloud backup." It's fundamentally idiotic to call both encryption protocols MTProto, because while what you're saying is semantically true (same name), it's also deceiving because in reality you should be saying:

"Secret-chats are end-to-end encrypted. Cloud chats are not. Cloud chats use encryption between client and server, and the server can see message content."


Cloud chats are designed for the majority of users – the majority that in another app like WhatsApp would rely on less secure third-party backup storage.

Here Durov states that majority of users prefer letting him and anyone who hacks the server read their messages as long as it also means backups. It is possible to backup E2EE messages to cloud in a safe way (again, shown above), he just doesn't want you to pay attention to the fact. Or he doesn't want to implement it because that would lock him out of your messages.


"Unlike what you have in niche apps, the traffic between cloud chat users and secret chat users on Telegram is mixed (the encryption is the same in both cases, but in cloud chats our servers do have access to the encryption key)"

This is very misleading. Compared to "niche" apps, Telegram uses one version of MTProto for client-server connections, and another version of MTProto for end-to-end encryption. Durov is using the tone "unlike what you have in niche apps" like it is a bad thing: "Unlike niche apps, we're not always end-to-end encrypting!" (How dare niche apps encrypt everything!)

He then quickly shifts focus to the fact that the Telegram's "encryption is the same". He does say the server has access to the key, but the user should understand what that means. The server can read every cloud message.

Durov says the two MProto protocols look the same

so [that] individuals can not be singled out and targeted based on the fact that they use secret chats and thus have something to hide.

This is mandatory, and nothing worth applauding. Signal wraps all E2EE connections inside a TLS-encrypted connection. TLS is a standard protocol between client and server, so you could say it's always using secret chat inside cloud chat connection.

This means no-one, not even server can tell whether the message is intended to be private from the server or not. In the case of Telegram, enabling secret chats explicitly tells the server "this is something I'm not willing to let even you guys read". Which is very valuable information in itself, and something both worth selling, and something worth obtaining by hacking the server.


Moving on to "4 Reasons Why The Telegram Way Makes More Sense"

"1) Unlike WhatsApp, we don’t give out our users’ data to third parties via backups. Instead, we rely on our own distributed cross-jurisdictional encrypted cloud storage which we believe is much more protected than what megacorporations like Google and Apple can offer. To give you an idea about this difference: while Telegram has disclosed no private data to third-parties from its cloud so far, this year alone Apple satisfied 80% of data requests from the Chinese (!) government (and is even building a data-center for private iCloud data in China)."

Immediately I want you to pay attention to the industry standard weasel-word "believe". When you "believe" it's much more protected, you're basically claiming without evidence.

Next, let's dive into the "distributed cross-jurisdictional encrypted cloud storage".


Durov points to this article where the system is described the following way:

"To protect the data that is not covered by end-to-end encryption, Telegram uses a distributed infrastructure. Cloud chat data is stored in multiple data centers around the globe that are controlled by different legal entities spread across different jurisdictions. The relevant decryption keys are split into parts and are never kept in the same place as the data they protect. As a result, several court orders from different jurisdictions are required to force us to give up any data.
Thanks to this structure, we can ensure that no single government or block of like-minded countries can intrude on people's privacy and freedom of expression. Telegram can be forced to give up data only if an issue is grave and universal enough to pass the scrutiny of several different legal systems around the world.
To this day, we have disclosed 0 bytes of user data to third parties, including governments."


Let's take this in pieces:

"Cloud chat data is stored in multiple data centers around the globe that are controlled by different legal entities spread across different jurisdictions."

The number of data centers is not disclosed, neither is the number of countries, or legal entities.

"The relevant decryption keys are split into parts and are never kept in the same place as the data they protect."

To debunk this claim requires understanding technical side of the implementation. In most servers, data is encrypted before it's written on the disk. This is called full disk encryption (FDE), and it prevents someone who physically infiltrates the data-center and steals a hard drive from the NAS rack from reading your messages. Full disk encryption uses symmetric encryption like AES-XEX, which means the key used to encrypt data before writing it to disk is the same key that can be used to decrypt the data when it's read from the disk.

It is possible the symmetric key is persistently stored using e.g. Shamir's secret sharing and that the necessary parts to put the key together have been distributed to multiple countries. But that's not how the disk encryption uses it. In order for the disk encryption to work, the key must by definition sit in the working memory (RAM) of the server, and it is accessible to anyone who compromises the server.

Furthermore, full-disk-encryption is what is called on-the-fly encryption (OTFE) [8], which means when you're using the computer, the encryption is transparent to you. The computer I'm using right now is using full disk encryption, and I don't have to decrypt every bit I read from the drive, I use the computer just like any other, except that the computer automatically encrypts and decrypts data that moves in and out of the disk.

What I can also do is make a remote connection (like SSH or SFTP) from my other computer to this computer. And when I do that, I can also access the data on this computer, despite full-disk-encryption.

What this would also mean is, if someone were to remotely hack my computer, they could read my data despite full disk encryption as long as the computer is powered on. And at that point it would not help me at all, if I had split the piece of paper to which I've written my disk encryption key (and which I enter to the computer when I power it on) into multiple parts and mailed them to Belau, Brazil and Belgium. Once the attacker is in the system, it's over.

There might be another, slightly more sophisticated way encryption could be used across servers. According to this tweet, Telegram servers are located in "London for European users, Singapore for Asian, San Francisco for American."

I live in Europe, so I would connect the server in London. I would send my cloud message there, and Telegram would then encrypt the message and split the ciphertext in three pieces and store the pieces to the three data centers, one to each. Now, only the server in London can decrypt the message, and no server is in possession of the entire ciphertext. But then something happens: my buddy who also lives in Europe wants to read the message I sent them. They will also contact Telegram's London server. The data center in London will then contact the Singaporean and SF servers, fetch the ciphertexts, decrypt the cloud message on London's end, and then send it to them, encrypted using the client-server version of MTProto.

Now, interestingly I'm also able to talk someone in the US over Telegram. Which means Telegram either establishes a separate connection for me to SF server (or connects them to the London server I use). That would be very weird. A much, much more likely scenario is, the message transits from me to London server, from there to SF server, and from there to my buddy in the US. I can also join US-based group in Telegram.

These two indicate a Telegram server in London can fetch messages from SF server's storage provided I have the authorization for that. As a user I of course can't fetch messages my friend has sent to their friends, but both Telegram developers and anyone who hacks the server and bypasses that authentication step, can.

The only way this would not be possible would be if the server delivered ciphertexts only the recipients had they keys for. That technology exists, and it's called end-to-end encryption.

My point is, because a single server must by definition be able to deliver us messages from all over the world, a single remotely hacked server can therefore be used to access any Telegram users' cloud chats. A single server can also thus most likely be issued a subpoena that forces the service provider to obtain that data.

The "distributed cross-jurisdictional encrypted cloud storage" is thus, to use a technical term, bullshit. It's up to the Telegram developers to disclose the real mechanism of how they're able to break the laws of physics and have one server be able to deliver plaintext message to user without having access to it by itself.


"As a result, several court orders from different jurisdictions are required to force us to give up any data."

Again if a single server can access all messages regardless of where they are stored, it's unclear why a per-country court order wouldn't work.


"To give you an idea about this difference: while Telegram has disclosed no private data to third-parties from its cloud so far, this year alone Apple satisfied 80% of data requests from the Chinese (!) government (and is even building a data-center for private iCloud data in China)."

There are a lot of weasel words here. Perhaps Telegram considers your messages not "private data", they're after all shared with the Telegram developers. They are not saying "Telegram has disclosed no cloud messages". The definition of third-party is not clear either. Perhaps LEA is the second party when a lawful request is obtained. Thirdly, it might not be their cloud service but rack space leased from some company. We don't know. Also could be they're just lying. The fact you need to rely on their word is enough reason to prefer privacy by design.

When all messages are accessible if and when the server is hacked, there is no need to make legal requests to the service. Most large countries have dedicated hacking teams at this point, and Telegram's service is like I said, a very juicy target. A great way for Russian intelligence to obtain dissident information is to ban the service for not disclosing keys (saves them face) and then to hack the server to spy on everyone who places false trust on cloud chat's security architecture.


I want to make one important point clear before we move on with the main article.

That is disclosure. If a breach would happen and billions of messages would leak to say Russian intelligence. What would Durov say? "I'm really sorry guys, we have since patched the vulnerability in our server, and to make sure this never happens again, we have crossed our fingers the attackers did not establish persistence with a rootkit, and that no other vulnerability will ever be found".

They most certainly wouldn't say "Ok, we fucked up. We're putting the service down until every client uses end-to-end encryption by default, whether it's a group conversation or not. We're going to ensure this never happens again". Because they can't make the latter statement, they can only say the one that doesn't inspire trust, and they know that will destroy them.

Thus they would be faced with two options: 1) Destroy user trust by disclosing the attack by telling they have no way to prevent future attacks or 2) Destroy user trust but only if they get caught for not disclosing the attack. Which one would they choose?

Moving on.


"2) Unlike WhatsApp, we can allow our users to access their Telegram message history from several devices at once thanks to our built-in instant cloud sync. Thus we can provide easy and consistent UX on macs, PCs, iPads and even linux servers."

This is not true. WhatsApp can be used with a Web-client that is linked with the phone client at the start of session. This is not very safe as repeated JS delivery problem exists, but Signal does this better by using a native client, and unlike WhatsApp, you can use Signal desktop client even if the phone is powered off.


"3) Unlike on WhatsApp, on Telegram you don’t have to store your entire message history on your phone all the time – you can always download older messages and media on demand when you need them. This saves a lot of disk space and memory, which is particularly important for our users in the developing markets. On Telegram, shortage of local storage never leads to data loss."

This can also be achieved with properly implemented cloud-backups. The connection is supposed to be forward secret and ephemeral. Try reading the statement again in the context "If you just let us read your messages". For example, "If you just let us read your messages, you don't have to store your entire message history on your phone all the time..." etc. Do they still sounds features, or something Facebook would say?


4) Unlike WhatsApp, Telegram is able to provide its users with advanced functionality, such as persistent group chats with up to 10,000 members or channels with no limit on max size.

"persistent group chats" is again just an euphemism for "we store everything on our server" which is not advanced functionality. It's the same thing the entire article has been about.

Scalability to 10,000 users is actually a great feature for cloud chats. So what's going on, why am I turning on my heels? Well, hear me out. With 10,000 users it's impossible to have reasonable expectation of privacy, it's extremely probable the group chat can be joined by anyone, or that someone in the group is leaking messages. A reasonable advice to obtain privacy in such group is not end-to-end encryption, but to be anonymous.

Leaving out the issue of phone-number based registration, the problem with Telegram is, the feature that's supposed to protect your anonymity in this case is fundamentally flawed. If an attacker adds your phone number from a large list of phone numbers, they can deanonymize you in that group. This has been a massive problem in Hong Kong protests where authoritarian country like China can automate attacks against the entire city's population. There is a solution to this problem in Telegram's privacy settings, but it is opt-in, and practically nobody knows about it.

For smaller groups where the expectation of privacy can still be assumed reasonably well, say for 5..50, perhaps up to 200 members (the risk increases gradually, not instantly), end-to-end encryption is still possible. Computers are getting faster so you can multi-cast individually end-to-end encrypted messages to groups faster and faster. Group key exchanges are improving too and may some day take over.

A dangerous part in Telegram providing no end-to-end encryption for small groups where it's entirely doable, is non-E2EE group chats will always be faster and thus, more convenient. This resembles a dark pattern called Roach Motel -- "an easy or straightforward path to get into something, but is difficult to get out of". It's easy to start using super fast group chats, but it's really difficult to get others to move into more safe but slower alternative.

Telegram shouldn't be applauded for making their group chats the fastest, but shunned for "cheating", for using an insecure method nobody else can beat at speed because then it wouldn't be secure. Again, thankfully, the differences are getting smaller and smaller as network speeds increase and smart phones can encrypt messages to larger and larger Signal groups (that have no upper group size limit BTW) in say, 100 milliseconds. The encryption part is parallelizable, and it's not the case we need to implement new, slower ciphers to fight off attackers.

To get back to the topic, defending non-E2EE group chats because super groups need to exist, is downright stupid. The limit for a super group is 200 members. A good idea would be to have E2EE for normal groups, and then drop E2EE for future messages when it grows to a super group.


4) [continued] These technologies can not be implemented within the “e2ee+third-party backups” paradigm. Our roadmap is filled with features that are impossible to build on a obsolete architecture like WhatsApp's that has to rely on third-party backups instead of relying on its own built-in cloud accessible in real-time.

This touches on what I talked about above about cheating. Applications like Signal and WhatsApp aren't obsolete. They are implementing features with E2EE in mind. It's of course easy to fill road map with neat features because all the client does is upload, download, and manage data that sits on server. It's easy to make a Telegram command that edits a message that sits on the server. With Signal you need to evaluate whether a message that can alter data on your device has implications to rights of the recipient to keep the chat log as it is. You also need to device an E2EE protocol for commands that allows doing it.

Signal also makes trade-offs about who manages the group: If its not the server, there can't be an admin for the group who can kick users. WhatsApp OTOH allows admin to control the group by having server kick out members of the group. This gives WhatsApp control over members in that group, and allows access to metadata wrt. the group. This also applies to Telegram -- the service has control over the group and its metadata as well as content. With Signal the server sees neither content nor metadata about which users are in the group.

These tradeoffs are fundamental, and indeed, some things can not be implemented but that's okay, because they can not be obtained without losing security. The features are not features but either accidents waiting to happen, or something that makes other parts of the system insecure.


"These are the reasons why we, ultimately, decided to go with the “two kinds of chats” approach, which is more secure (Telegram cloud is better protected than Apple/Google storage), more transparent (you can actually see which of your e2e-encrypted messages go to the cloud and which don’t) and more feature-rich (we can implement features that I mentioned above and many more in the future). "

There is no no transparency into how Telegram server is actually protected, what OS the server is running, how often it's patched etc., and as per previous reasoning, there's no incentive for Telegram to disclose server side hacks. It's hard to quantify security between data centers of Apple, Google, and Telegram. It's only clear that if no compromise has occurred at the point 92% Fortune 500 have been targeted, they're either in the wrong business and should be hardening the services of Fortune 500 companies for astronomical amounts of money, or, they may not be honest when they say they haven't been compromised. What makes this worse is, just like Telegram staff, state-level actors that hack Telegram servers have no incentive to disclose the hack because for them it's a gold mine of personal information. The hacktivists who would disclose hacking Telegram servers would go to jail for it, so they also have no incentive.


"We believe our “two kinds of chats” approach makes more sense in the long run, which is why it has since been copied by Kakao (2014), Line (2015), and last year by Google Allo and Facebook Messenger."

It is interesting in the article Durov both condemns the flawed E2EE of WhatsApp (owned by Facebook), and then applauds Facebook Messenger for using opt-in, off-by-default E2EE, when it suits his need to validate Telegram's insecure-by-default design.


"I think the myth about Telegram being less secure than WhatsApp originated in a misleading 2016 article by Gizmodo (“Why you should never use Telegram”) which claimed a lot of things that are not true. A member of our team wrote an extensive review of that article exposing some of the misconceptions that I’ve also described in this post."

Great, another thing to refute some other time. Meanwhile I understand a tech journalist's article doesn't carry much weight on its own, so I'd like to point out two comments by two actual cryptographers:




To this day, I have yet to see a single recommendation to use Telegram by any cryptographer. That alone should say enough about Telegram's "security".


"Every year Facebook – the company that owns WhatsApp – spends millions of dollars on marketing, influencing journalists and bloggers. By contrast, Telegram has spent zero dollars on marketing since we started in 2013. Nevertheless, every day at least half a million new users sign up for Telegram, and Telegram's organic annual growth rate exceeds 50%. We owe this growth only to you – our users and the Telegram community.
I hope this post gives an idea about how Telegram works and why we believe our architecture makes more sense than that of the older apps."

Telegram hasn't disclosed its financial records, thus there's no way to verify they don't spend money on astroturfing campaigns.


To recap

Just because WhatsApp doesn't do things in an ideal way is no justification to do things equally bad. Leaving out end-to-end encryption from majority of chats is irresponsible, and will lead to eventual leak of massive amounts of user data.

Telegram claims user data is not an asset for them, yet they fail to realize that user data is a massive, massive liability. Lack of mitigation strategies in the event of compromise highly incentivizes against disclosing a hack.

Cloud backups are important to people but properly implemented client-side encryption is a great way to get cloud backups.

The only place where Telegram cloud chats need to exist in technical sense is when we talk about very large groups where expectation of privacy is nonexistent anyway. Non-super-groups should use end-to-end encryption.

Report Page