Telegram Analysis

Introduction

Telegram, founded in 2013 by Pavel and Nikolai Durov, has grown to exceed 900 million monthly active users as of 2025. It is, by any measure, one of the most consequential communication platforms of the current decade. Its influence on messaging -- channels with unlimited subscribers, supergroups with up to 200,000 members, seamless cross-device synchronization, a rich bot ecosystem, and an open client API -- has reshaped user expectations for what a messenger should offer. Any serious analysis of the messaging landscape must reckon with Telegram's achievements.

However, an academic assessment of Telegram must distinguish between product success and cryptographic rigor. Telegram's architecture embodies a deliberate engineering decision: prioritize feature richness and user experience over end-to-end encryption by default. This decision has concrete, measurable consequences for user privacy that are often obscured by the platform's marketing as a "secure" or "private" messenger. This chapter provides a detailed technical examination of Telegram's encryption model, its server-side data access, the academic criticism of its custom cryptographic protocol, and the structural reasons why its architecture is incompatible with the security guarantees provided by Zentalk.

Telegram's Dual Encryption Model

Telegram's Dual Encryption Model

User A

Cloud Chat (Default)

TLS to Server

Server Decrypts

Stored in Plaintext

Re-encrypted to B

Secret Chat (Manual)

MTProto E2EE

Server Sees Ciphertext

Cannot Decrypt

Forwarded as-is

User B

Server has full access

No multi-device, no cloud backup

95%+ of Telegram traffic

Rarely used

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

Left: Cloud Chats (default) -- the server decrypts, stores, and re-encrypts every message. Right: Secret Chats (opt-in) -- end-to-end encrypted but restricted to single-device, one-to-one conversations.

Cloud Chats: Server-Side Encryption Only

Telegram's default messaging mode, "Cloud Chats," employs a client-server encryption model rather than end-to-end encryption. Messages are encrypted in transit between the client and Telegram's servers using MTProto 2.0, but the servers decrypt, process, store, and re-encrypt messages for delivery to recipients. This is functionally equivalent to the transport-layer encryption (TLS) used by any HTTPS website: it protects against network eavesdroppers but provides no protection against the service operator itself.

The architectural consequence is unambiguous: Telegram possesses the cryptographic keys necessary to read every Cloud Chat message on its servers. The message plaintext is available to Telegram's infrastructure for indexing, search, content processing, and -- critically -- disclosure to third parties upon legal compulsion. This is not a speculative vulnerability; it is the documented and intended behavior of the system.

Telegram's FAQ describes this model as providing "distributed infrastructure" where encryption keys are "split into parts" stored in "different jurisdictions." The technical reality is that key splitting across jurisdictions is an organizational access-control measure, not a cryptographic guarantee. It may increase the number of legal orders required to compel disclosure, but it does not change the fundamental fact: the keys exist, the plaintext is recoverable, and the system operator has the technical capability to decrypt any Cloud Chat message. Distributed key storage is a policy protection, subject to the same fragilities as all policy protections -- it can be circumvented by organizational decision, legal compulsion across cooperating jurisdictions, insider action, or infrastructure compromise.

The contrast with end-to-end encryption is categorical. In an E2EE system such as Zentalk's Signal Protocol implementation, the decryption key exists only on the recipient's device. The server processes opaque ciphertext. No organizational decision, legal order, or infrastructure breach can produce the plaintext, because the mathematical structure of the encryption makes decryption without the key computationally infeasible. This is the distinction between policy-based privacy and mathematical privacy articulated in Section 1.3.1 of this paper.

Secret Chats: Optional End-to-End Encryption

Telegram offers an alternative mode, "Secret Chats," that does provide end-to-end encryption using MTProto 2.0's encryption layer. Secret Chats employ a Diffie-Hellman key exchange to establish a shared secret between two parties, with messages encrypted using AES-256-IGE (Infinite Garble Extension) and authenticated with SHA-256.

However, Secret Chats carry three significant architectural limitations that severely constrain their utility:

Single-device restriction

Secret Chats are bound to the device on which they were initiated and do not sync across devices. Users must choose between cloud sync and encryption -- most choose sync.

No group support

Secret Chats are limited to one-to-one conversations and cannot be used in groups, supergroups, or channels -- the features that define Telegram's differentiation.

Opt-in friction

Secret Chats require explicit activation through a separate menu option. Security research consistently shows that opt-in mechanisms are used by a small minority of users.

The result is a dual-tier privacy model: a widely used mode with no end-to-end encryption, and a rarely used mode with encryption but without the features that make the platform attractive. This architectural bifurcation is not an accident; it is a direct consequence of the design decision to prioritize server-side features over client-side encryption.

MTProto 2.0: A Custom Cryptographic Protocol

Telegram does not use any established, peer-reviewed cryptographic protocol for messaging. Instead, it employs MTProto 2.0, a protocol designed in-house by Nikolai Durov. MTProto has undergone several revisions since Telegram's launch, including a significant redesign from MTProto 1.0 to MTProto 2.0 in 2017 to address publicly identified weaknesses.

The use of a custom protocol in a high-stakes security application is itself a significant concern. The cryptographic community maintains a strong consensus, articulated by Bruce Schneier and others, that designing cryptographic protocols is extraordinarily difficult and that even expert designers routinely introduce subtle flaws. The Signal Protocol, by contrast, was developed by experienced cryptographers (Moxie Marlinspike and Trevor Perrin), subjected to formal academic analysis [Cohn-Gordon et al. 2020], and adopted as the basis for encryption in WhatsApp, Facebook Messenger, Google Messages, and Skype. Its security properties have been formally verified using the Tamarin prover. MTProto has received no comparable level of formal verification.

Academic Criticism of MTProto

The most rigorous academic analysis of MTProto was published by Albrecht, Marekov, Sheridan, and Mayfield at Royal Holloway, University of London. Their 2022 paper, Four Attacks and a Proof for Telegram, presented a formal security analysis of MTProto 2.0 and identified four distinct attack classes:

Timing-based message reordering

An active attacker could manipulate message ordering without detection. The binding between sequence numbers and message content was found to be insufficiently strong.

Client-to-server plaintext recovery

Under constrained conditions involving a malicious server or compromised server key, portions of client-to-server communication could be recovered -- a theoretical weakening of Secret Chat encryption.

IND-CCA violations

MTProto 2.0's encryption did not satisfy the IND-CCA2 security definition in certain configurations -- considered the minimum acceptable security level for modern encryption schemes.

Padding oracle potential

The protocol's use of padding could in principle enable padding oracle attacks that reveal information about plaintext content through error behavior.

Albrecht et al. noted that MTProto 2.0 was a substantial improvement over its predecessor and that some of the identified weaknesses were theoretical rather than practically exploitable with current resources. They also provided a constructive proof that with specific modifications, MTProto 2.0 could be shown to satisfy a well-defined security notion (IND-CCA under random oracle model). Nevertheless, the paper's conclusion was unambiguous: MTProto 2.0 is weaker than established protocols like the Signal Protocol, and the decision to design a custom protocol rather than adopt an existing, well-analyzed one remains difficult to justify from a cryptographic standpoint.

It is worth noting the absence of comparable findings for the Signal Protocol. The formal analysis by Cohn-Gordon et al. [16] proved that the Signal Protocol satisfies a strong security model (multi-stage key exchange security with post-compromise security), and no analogous attack paper has identified theoretical weaknesses in Signal's construction.

Server-Side Data Access

What Telegram's Servers Can See

Because Cloud Chats are the default and dominant communication mode, Telegram's servers have access to a comprehensive dataset for the majority of user interactions:

Full message content

All text, voice messages, photos, videos, documents, and files sent through Cloud Chats are stored in a form Telegram can decrypt, including personal, business, and group conversations.

Group and channel data

Complete membership lists, join dates, roles, and participation history for all groups and channels. For public channels with millions of subscribers, this maps users' information consumption patterns.

Contact information

Phone numbers (required for registration), contact list uploads, and the social graph derived from mutual contacts and group co-membership.

User activity metadata

Connection timestamps, last-seen status, online/offline transitions, typing indicators, read receipts, IP addresses, device identifiers, and session information -- enabling detailed behavioral profiling.

Media and files

All media shared through Cloud Chats is stored on Telegram's CDN unencrypted relative to the server operator, including files up to 2 GB.

The "Distributed Infrastructure" Claim

Telegram describes its infrastructure as "distributed" across multiple jurisdictions, with encryption keys split so that no single jurisdiction's legal process can compel full disclosure. This claim warrants careful analysis.

First, "distributed infrastructure" in Telegram's usage refers to corporate server placement across data centers in multiple countries. This is standard practice for any global web service for latency and reliability purposes, and it does not constitute decentralization in the technical sense used in distributed systems literature (see Chapter 1, Section 1.6). The infrastructure is wholly owned, operated, and controlled by Telegram FZ-LLC (Dubai) and its associated entities. There is no independent operation of nodes, no permissionless participation, no cryptographic enforcement of operator honesty, and no mechanism by which users can verify the claimed key-splitting arrangement.

Second, the key-splitting claim is unverifiable. Telegram's server-side code is proprietary and has never been published or independently audited. Users must trust Telegram's assertion that keys are split across jurisdictions, that no single entity holds all key fragments, and that the recombination process requires multi-jurisdictional legal compulsion. This is precisely the kind of policy-based assurance whose fragility is a central theme of this paper.

The 2024 Compliance Shift

In September 2024, following the arrest of CEO Pavel Durov in France on charges related to platform moderation, Telegram updated its privacy policy and began cooperating with law enforcement requests for user data across multiple jurisdictions. The updated FAQ stated that Telegram would disclose IP addresses and phone numbers of users suspected of criminal activity in response to valid legal orders.

This event is significant not because data sharing with law enforcement is inherently inappropriate -- legitimate legal process is a feature of functioning legal systems -- but because it concretely demonstrated the consequences of the architectural choice to retain decryptable user data. Telegram could comply with these requests precisely because its infrastructure stores the data in accessible form. The platform's years of marketing as a haven for private communication were revealed to depend on a policy choice (the decision not to share data) rather than a technical constraint (the inability to share data).

The contrast with a mathematically private architecture is instructive. If a comparable legal order were directed at a Zentalk mesh node operator, the operator could comply fully -- producing encrypted ciphertext, hashed addresses, and erasure-coded data fragments -- and the result would be cryptographically useless without the users' private keys. Compliance is not refused; it is rendered moot by the architecture. This is the practical consequence of the distinction between "we choose not to read your messages" (policy) and "we cannot read your messages" (mathematics).

Feature-Privacy Trade-off

Structural Reasons for Server-Side Processing

Telegram's architectural choice to forgo default end-to-end encryption is not arbitrary; it enables a set of features that are structurally incompatible with E2EE in a naive implementation:

Server-side search

Telegram maintains a searchable index of message content on its servers -- impossible with E2EE. Zentalk uses client-side search over locally cached decrypted messages instead.

Seamless cross-device synchronization

Telegram stores the message corpus server-side for instant access on new devices. Zentalk handles this through deterministic key derivation and mesh-stored encrypted history that new devices retrieve and decrypt locally.

Channels and supergroups at scale

Telegram avoids per-subscriber encryption costs by distributing plaintext from the server. Zentalk distributes a shared channel key via pairwise E2EE sessions, accepting higher key distribution overhead to maintain encryption.

Rich content processing

Features like link previews, inline bots, and sticker suggestions require server-side content understanding. Zentalk generates these client-side where possible and accepts that some server-dependent features are architecturally excluded.

Instantaneous media loading

Telegram pre-processes and caches media on its CDN for near-instant loading. E2EE media requires download and decryption, introducing latency. Zentalk mitigates this with adaptive chunk-based delivery and client-side caching.

The Honest Assessment

Telegram's architects made a rational engineering decision: the features enabled by server-side access -- instant sync, global search, massive channels, rich bots, server-processed media -- provide tangible, daily utility to hundreds of millions of users. These features drove Telegram's growth from a niche privacy tool to a mainstream communication platform competing with WhatsApp and WeChat.

The cost of this decision is borne by users who believe, based on Telegram's marketing, that their communications are private. The term "private" in Telegram's self-description refers to the company's stated policy not to share data, not to any mathematical guarantee of confidentiality. As the 2024 compliance shift demonstrated, policy is mutable; mathematics is not.

Comparative Architectural Summary

Dimension	Telegram	Zentalk
Default encryption	Server-side only (Cloud Chats)	E2EE (Signal Protocol + post-quantum hybrid)
E2EE availability	Opt-in, 1:1 only (Secret Chats)	All messages, groups, and channels by default
Cryptographic protocol	MTProto 2.0 (custom, in-house)	Signal Protocol (peer-reviewed, formally verified)
Post-quantum protection	None	X25519 + Kyber-768 hybrid (NIST FIPS 203)
Server message access	Full plaintext for Cloud Chats	Zero: server processes only ciphertext
Cross-device sync	Instant (server stores plaintext)	Deterministic key derivation + encrypted mesh retrieval
Message search	Server-side full-text index	Client-side search over decrypted local cache
Group/channel encryption	None (Cloud) / unavailable (Secret)	Shared key via pairwise E2EE (Chapter 7)
Infrastructure model	Corporate-controlled data centers	Permissionless validator mesh with staking
Metadata access	Full (contacts, timing, IP, activity)	Minimized (hashed addresses, sealed sender, encrypted indicators)
Data disclosure capability	Full compliance possible	Cryptographic inability: only ciphertext available
Independent audit of protocol	No formal verification published	Signal Protocol formally verified [Cohn-Gordon et al. 2020]

Conclusion

Telegram deserves recognition for demonstrating that a messaging platform can scale to hundreds of millions of users while maintaining fast performance, a rich feature set, and an open client API. Its channel model has become the de facto standard for large-scale content distribution in messaging. Its bot platform has spawned an ecosystem of third-party integrations. Its willingness to resist government pressure (prior to 2024) was, while it lasted, a meaningful stance.

None of this alters the cryptographic assessment. Telegram's default mode provides no end-to-end encryption. Its optional E2EE mode is restricted to single-device, one-to-one conversations. Its custom cryptographic protocol, MTProto 2.0, has documented theoretical weaknesses not present in the Signal Protocol. Its servers possess the technical capability to read the vast majority of user messages. Its "distributed infrastructure" is a corporate organizational measure, not a cryptographic or decentralization guarantee. And the 2024 policy shift confirmed that the company will exercise its data access capabilities when subjected to sufficient legal pressure.

Zentalk's architecture demonstrates that the features Telegram users value -- groups, channels, cross-device access, media sharing -- can be provided without requiring the server to access message content. The engineering cost is real: client-side search is more limited than server-side search, key distribution adds overhead to channel operations, and some server-dependent features (server-side link previews, content-aware bots) must be reimplemented or excluded. These are genuine trade-offs, openly acknowledged. But they are trade-offs between convenience and mathematical privacy -- and in this paper's assessment, mathematical privacy is the non-negotiable foundation on which all other guarantees must rest.