On Our Telegram MTProto Review

On May 18, 2026, iStories, part of the OCCRP investigative network, published a piece describing a Symbolic Software technical review of Telegram’s MTProto protocol. The review, titled Telegram’s MTProto: Assessing Deanonymization Potential for a Network Attacker and identified as GNMX-01, was commissioned in 2025 by Global Network Solutions, Inc. (“GNM”), the Telegram infrastructure provider that figures centrally in OCCRP’s 2025 investigation Telegram, the FSB, and the Man in the Middle. We did not publish the report. It entered the public record because GNM attached it to a civil filing in Switzerland, and iStories obtained it from the materials of that case.

We are publishing this post because the report is now being characterised through third-party paraphrase in coverage of a contested matter, and we would prefer the substance to stand without that mediation. The full report is available for download.

The conditions of the engagement

The report could not have been written without the following conditions, which are reproduced verbatim in Section 2.4:

• Symbolic Software retains full editorial control over all findings, conclusions, and recommendations presented in this report;
• Symbolic Software has the unconditional right to reach any conclusion deemed technically appropriate based on the evidence, regardless of whether such conclusions align with the expectations or preferences of any party;
• No party may modify, censor, or otherwise interfere with the technical content or conclusions of this report;
• Symbolic Software maintains sole authority over the methodology, scope, and presentation of the technical analysis;
• The integrity of this report and its findings shall be preserved in any publication or distribution.

These were non-negotiable prerequisites of the engagement, and the commissioner agreed to them. Their relevance to the present situation is clear. The final clause in particular continues to bind the commissioner, even though the route by which the report became public was the commissioner’s own decision.

A second methodological note deserves quoting alongside that disclaimer. The OCCRP investigation’s principal technical source is Michał “rysiek” Woźniak, who formerly served as OCCRP’s Head of Infrastructure and Information Security. OCCRP disclosed this conflict of interest in the original reporting. The report addresses it directly in a footnote:

Mr. Woźniak’s technical claims were independently verified to be correct regardless of this potential conflict of interest. The political claims and personal opinions made in Mr. Woźniak’s technical analysis were disregarded during our independent verification.

The same standard runs through the report in both directions. Testable technical claims are evaluated against the evidence. Characterisations that blend technical fact with geopolitical framing are noted as falling outside the scope of technical validation, regardless of which party offers them.

The core technical finding

Telegram’s MTProto protocol prepends a 64-bit auth_key_id to the external header of every encrypted message. The identifier is the 64 lower-order bits of a SHA-1 hash of the 2048-bit authorisation key established at registration. MTProto 2.0 continues to use SHA-1 here even though it migrated to SHA-256 elsewhere, because the identifier must outlive any single protocol version. The underlying authorisation key is long-lived by design: it is generated on the client device, never transmitted over the network, and tied to the device’s persistent state.

The question the report examined was whether this identifier is exposed to passive network observers in deployed clients. On every platform tested, it is.

• Telegram for Android. We replicated Michał Woźniak’s prior analysis of Telegram for Android v11.9.2 (5901). MTProto runs over plain TCP under a trivial obfuscation layer. Telegram’s own documentation describes that layer as designed only to defeat naïve protocol detection, not to provide cryptographic protection. The obfuscation is an XOR with a pseudo-random stream derived from a public, documented initialisation procedure, so deobfuscation is computationally trivial. After deobfuscation, the auth_key_id appears in cleartext in the external header of every MTProto message.
• Telegram Desktop on macOS (version 11.15.275369 at the time of testing). The desktop client connects to Telegram’s servers on port 443, the canonical HTTPS port, but the traffic is not HTTPS. We verified this with four independent techniques:
  • TLS fingerprinting of the initial packets of each connection. No TLS ClientHello was ever observed, and the connections began immediately with MTProto exchanges.
  • Certificate validation. No TLS certificates were exchanged at any point.
  • Packet structure analysis. The MTProto external header, including the 64-bit auth_key_id and the 128-bit message key, begins immediately after the TCP header, with no intervening TLS record layer.
  • Selective traffic blocking. We configured local firewall rules to block outbound HTTPS to Telegram’s IP ranges while permitting plain TCP on port 443. Telegram continued to function normally, confirming that it does not depend on TLS at all.

The use of port 443 appears designed to evade simple firewall rules and censorship classifiers that block non-standard ports while allowing HTTPS. It does not deliver transport-layer encryption. The Telegram Desktop codebase is shared with the Windows and Linux builds, so the finding almost certainly generalises.

To characterise persistence, we observed the auth_key_id across a range of conditions that would normally defeat or interrupt other forms of network-layer tracking. The result was uniform across all of them.

With Perfect Forward Secrecy enabled, the visible identifier corresponds to a temporary key rather than the permanent one. The report walks through in some detail why this does not address the tracking problem. The temporary keys remain valid and unchanged for their full lifetime, which is typically 24 hours, and during that lifetime the temporary auth_key_id is just as observable and just as persistent as a permanent one would be. The binding step that ties a new temporary key to the permanent key is itself a network-observable event from the same client, typically from the same IP address. The old temporary auth_key_id is used to negotiate and authorise the new one, and both appear in succession in the traffic. A passive observer maintaining a record of these binding events can follow a device across arbitrary numbers of rotations. In the report’s words, PFS “is designed to protect against post factum decryption of message contents if keys are later compromised — it is not designed to prevent real-time traffic analysis or device tracking.” It does what it was specified to do. Transport-layer tracking is a separate problem.

The capability this creates is straightforward, and it does not require an active attacker. The report enumerates the in-scope adversary classes: ISPs along the network path, mobile carriers’ deep packet inspection systems, corporate and institutional network administrators, public WiFi operators, parties operating at internet exchange points or in transit, malicious hotspot operators, state surveillance programs, and any passive eavesdropper with physical or wireless access to the medium. None of these requires a man-in-the-middle attack, a certificate compromise, or active protocol manipulation. Simple packet capture and the publicly documented deobfuscation step suffice.

On “auth_key_id changes regularly”

A statement attributed to Telegram in iStories’ coverage holds that the auth_key_id “changes regularly and does not reveal user information.” The empirical part of that claim is testable, and the report tests it. From the executive summary:

Our empirical testing demonstrated that auth_key_id rotation, while theoretically possible, occurs infrequently in practice — we observed no rotation across application restarts, network changes, or extended time periods in our tests. This persistence contradicts claims of frequent rotation and significantly amplifies the privacy implications of the exposure.

For rotation to defeat the tracking model, “regularly” would have to mean two things at once: rotation at a cadence shorter than an adversary’s correlation window, and rotation that is not itself observable from the network. The deployed protocol satisfies neither condition.

The long-term auth_key_id did not rotate at all across the conditions enumerated in the previous section. When PFS was enabled, the temporary auth_key_id persisted for its full 24-hour validity period, and the transition from one temporary key to the next was trivially linkable. The binding event between successive temporary keys appears in the same flow, from the same client, and typically from the same IP address. The report quotes Woźniak’s prior analysis on this point: “It is extremely unlikely for the IP address of the client and the temporary auth_key_id to both change at the exact same time.” The transition is therefore not a privacy boundary. It is a network-visible event that links the old identifier to the new.

If Telegram has empirical evidence to the contrary, that evidence has not been made public, and our testing did not observe its effects.

On what the report concludes about each claim

The report evaluates five claims drawn from OCCRP’s investigation, and it does not endorse them in identical terms.

Claims 1, 3, and 5: fully supported. The first claim is that the auth_key_id enables user tracking. The third is that Secret Chats’ end-to-end encryption does not prevent that tracking, because the identifier sits in the MTProto external header beneath the Secret Chat encryption layer. The fifth is that infrastructure with router-level visibility can read those identifiers. The report describes each of these as technically accurate without overstatement, and the empirical evidence in our analysis substantiates them in full.

Claim 2: substantially accurate but with elements of overstatement, and in places actively misleading. Phrases like “all possible information” overstate what passive network observation strictly provides. The assertion that observers can determine “who exchanges data packets with whom” overstates the visibility that client-to-server observation provides in a centralised architecture. Network observers see traffic flowing to and from Telegram’s servers, but they cannot directly reconstruct the server-side communication graph from that traffic alone. Beyond these overstatements, there is a more substantive problem. The metadata surveillance capabilities described in Claim 2 are not unique to Telegram. Signal, WhatsApp, iMessage, and every other major messaging platform expose comparable IP-layer metadata to network observers. Singling out Telegram on this point, without acknowledging that Signal and WhatsApp face identical metadata exposure, misrepresents the scope of the issue. The MTProto-specific problem is the auth_key_id exposure of Claim 1. The broader metadata picture of Claim 2 is a property of unencrypted internet traffic at large.

Claim 4: technically sound core, geopolitical attribution speculative. Infrastructure-level access combined with auth_key_id visibility can enable extensive device tracking. That much is sound. The problem is the inferential chain OCCRP uses to attribute that capability to Russian intelligence services specifically. Applied symmetrically, the same chain would implicate Western messaging platforms and their infrastructure providers just as readily. Signal runs on AWS, which holds a $600M CIA contract and subsequent NSA contracts. WhatsApp is owned by Meta, which discloses data in response to thousands of government requests annually. iMessage runs on Apple’s contracted data centres. Microsoft Teams runs on Azure. The report puts the asymmetry plainly:

The OCCRP investigation appears to apply a standard of suspicion to Russian-connected infrastructure that is not symmetrically applied to U.S.- or European-connected infrastructure, despite comparable (and often more direct) relationships between Western technology providers and Western intelligence services. This asymmetry suggests a politically motivated framing rather than a neutral security analysis.

The technical vulnerability is real. The specific adversary attribution is investigative work, not technical analysis.

None of these qualifications reduces the technical vulnerability. They sharpen the claim being made about it, and we hope they are preserved in future coverage.

What the tracking looks like in practice

Chapter 5 of the report walks through a hypothetical but technically faithful deanonymisation timeline for a journalist using Telegram to communicate with sources. The point of the case study is that the tracking does not require future technology or nation-state infrastructure. It uses standard ISP logging already deployed for troubleshooting and billing, mobile carrier deep packet inspection commercially available from vendors like Sandvine and Procera, captive portal authentication logs standard in enterprise and public WiFi, and database queries to correlate identifiers across datasets.

The chain runs in three steps. The first step is passive observation of an auth_key_id across several networks. The second step is the establishment of a single identity anchor. In the case study, a press-conference WiFi registration ties the auth_key_id to a name and outlet. The third step is retroactive search of all logged traffic for that identifier across home ISP, mobile carrier, airport WiFi, and even a VPN session. The VPN successfully masks the IP from Telegram’s perspective, but it does not protect the auth_key_id from observation by the VPN provider or by any infrastructure between the VPN exit and the Telegram server. The case study takes twenty days from initial observation to retroactive analysis, and it uses only logs the providers were already maintaining for unrelated reasons.

The report is careful to keep this on the right side of the line. Two legal and ethical disclaimers appear in the body of the report (in Chapters 1 and 5), and Appendix A summarises the legal framework governing interception in the EU, US, and Germany. The appendix concludes:

Where the report states that auth_key_id is technically observable, that should be read as a statement of technical possibility. Any operational collection or retention of such identifiers requires legal authority and appropriate procedural safeguards; otherwise it risks criminal and civil liability.

The vulnerability described in the report is a latent capability under the protocol design. It is for legal frameworks to constrain how that capability may lawfully be exercised.

On editorial independence

Two clarifications are worth offering.

The first concerns the engagement itself. We accepted it on the conditions quoted above, and we delivered on them. The report concluded against the commissioning party’s preferred outcome on the central technical questions. The auth_key_id exposure is real. The deployed protocol does not rotate at a cadence that defeats tracking. PFS does not address the tracking problem. The desktop client’s use of port 443 does not constitute transport encryption. The architectural responsibility for fixing this lies with Telegram, not with its infrastructure providers. This is the firm’s standing practice, and the engagement letter was structured the way it was precisely so that the practice could hold under pressure.

The second concerns the report’s qualifications of OCCRP’s framing. Those qualifications, on Claim 2 and on Claim 4, are not concessions to the commissioner. They are the same editorial standard applied in the other direction. The methodological footnote on Woźniak, quoted earlier, is the cleanest statement of that standard. Technical claims are evaluated on the evidence. Political characterisations are noted as falling outside the technical scope, regardless of which party offers them. We applied the same rule to OCCRP’s framing that we applied to GNM’s preferences.

On the publication route

The report became public because Global Network Solutions, Inc. attached it to a civil filing in Switzerland, where the matter is currently in litigation. We did not publish it. iStories obtained the document from the materials of that case.

We were not contacted by iStories prior to their publication. We note this without grievance, but for the record. The standard practice when attributing technical conclusions to a named expert firm is to confirm with that firm both that the document is genuine and that the proposed framing of its conclusions is accurate. The document is genuine. The framing is substantially accurate, but compressed in places where the report itself is more careful, particularly on Claims 2 and 4, where the report’s qualifications are the kind of detail a one-paragraph paraphrase tends to elide. We mention this because publications of iStories’ standing are normally diligent on the verification step. The situation it could have produced, in which a forged or altered document was attributed to us in a politically sensitive context, is the kind of failure that next-time diligence is designed to prevent.

What remains

The remedy is not novel and does not require theoretical advances. WhatsApp wraps its Noise transport in TLS. Signal uses TLS, and has historically used that TLS layer for further useful purposes such as censorship-circumvention domain fronting. iMessage and every other major messenger of comparable scale uses TLS or an equivalent transport-encrypted layer. The cost of TLS termination is well understood, and modern implementations are mature on every platform Telegram supports. The only remaining barrier to closing the auth_key_id exposure is an organisational decision on Telegram’s part to make transport-layer encryption mandatory for MTProto and to remove the unencrypted fallback paths.

Until that decision is taken, the privacy properties of Telegram against passive network observers are what the report describes. The report’s executive summary puts the conclusion more plainly than we will here: the present design represents “not merely a technical failing, but a fundamental abdication of Telegram’s responsibility to protect user privacy through appropriate cryptographic measures.” Users in high-risk categories, including journalists, activists, dissidents, and anyone whose communications may attract the interest of state or near-state actors, should incorporate that exposure into their threat models. The standard countermeasures, such as VPNs, Tor, regular network switching, and SIM swaps, do not address the underlying vulnerability, because the vulnerability is in the protocol rather than in the user’s network.

The full report is linked above. It contains the formal evaluation of each OCCRP claim, the illustrative deanonymisation case study, the appendix on legal context, and the engagement-letter clauses quoted in this post.