The short answer
- 1MTProto is the protocol between apps and servers: API, encryption and transport layers.
- 2Key exchange, encryption, ordering, resending and time sync are the library's job.
- 3Your job is guarding session files and your api_id.
In this article
What MTProto is
MTProto is the protocol Telegram apps and Telegram's servers use to talk to each other. The official apps, TDLib, and the Telegram servers behind the Bot API all speak it. The current version is MTProto 2.0.
If what you want to know is whether Telegram's encryption is safe as a user, read Telegram encryption explained in plain words first. This article is about what a developer does personally and what they can hand off.
The three layers of MTProto
| Layer | What it does |
|---|---|
| Top: API calls | Turns requests and responses such as "send a message" into a fixed binary format. The methods developers actually work with live here |
| Middle: authorization and encryption | Encrypts each message with an authorization key made for that device, and blocks forgery and reordering |
| Bottom: transport | Carries the encrypted packets, over TCP, WebSocket (including over HTTPS), or HTTP/HTTPS |
What a library does for you
If you implement MTProto yourself, you have to build all of the following. With a library such as TDLib, you do not have to think about any of it.
- Creating the authorization key: the first time the app runs, it makes a device-specific key with the server through a Diffie-Hellman exchange (2048-bit), and rarely changes it after that; see creating an authorization key.
- Encrypting and checking messages: a key unique to each message is derived from the message content and the authorization key; the receiver repeats the calculation to detect tampering.
- Sessions and ordering: sessions survive dropped connections, message IDs are tied to time, and sequence numbers within a session filter out duplicates and reordering.
- Acknowledgements and resending: messages the other side has not confirmed receiving are sent again.
- Time synchronisation: if the device clock is far off, message IDs are rejected, so the client corrects itself with an offset the server sends.
Your job is to protect the keys
With a library, what remains your responsibility is protecting the authorization key and session files stored on the device, and your api_id and api_hash. A session file is the logged-in account itself: anyone who gets it can use that account without a password. See getting an api_id safely.
Cloud chats and secret chats
| Chat | Encrypted between | What it means |
|---|---|---|
| Ordinary (cloud) chats | Your device and Telegram's servers | Stored on the server, so you can continue on several devices |
| Secret chats | Your device and the other person's device (end to end) | The server cannot decrypt the content; it is visible only on the devices where the chat was made |
Secret chats add one more layer of end-to-end encryption on top of MTProto. Where the keys live is in how secret chat encryption is structured, and how to use them is in how to start a secret chat.
If you plan to implement it yourself
To choose between TDLib and the Bot API, see the four Telegram APIs; to read the method list, see reading the TL schema and layers.
FAQ
What is MTProto?
The protocol Telegram apps, TDLib and Telegram's servers use to communicate; the current version is MTProto 2.0.
Do I need to implement MTProto to build a Telegram client?
No. The official documentation recommends using an existing implementation such as TDLib.
Why is a session file sensitive?
It is the logged-in account; whoever has it can use the account without a password.
Sources
At a glance
- 1Layers
API calls, authorization and encryption, transport.
- 2Libraries
TDLib handles keys, ordering, acks and time sync.
- 3You
Protect session files; don't roll your own crypto.
Updated
