The short answer
- 1The authorization key never travels; both sides compute it with Diffie-Hellman.
- 2The server's public key built into the app proves you reached the real server.
- 3Skipping the checks on the received prime and values breaks all the encryption.
In this article
What the authorization key is
Every message a Telegram app exchanges with the server is encrypted with an authorization key (auth key). It is created together with the server the first time the app connects to a data center, and is rarely changed afterwards. The key itself never travels over the network: both sides compute the same value independently through a Diffie-Hellman key exchange (2048-bit).
TDLib and the official apps do all of this for you. This article explains what happens so you understand it. If you implement it yourself, follow the official steps and checks exactly; see client security guidelines.
The exchange in five steps
| Step | What happens | Why |
|---|---|---|
| 1. Hello | The app sends a random value (nonce). The server returns its own random value, a number puzzle to solve and the fingerprint of its RSA public key | Ties this exchange together so it cannot be mixed with another |
| 2. Server check | The app solves the puzzle (splitting a large number into two primes) and sends the answer with a new random value, encrypted with the server's public key | Only the real server, holding the private key matching the public key built into the app, can read it. The puzzle is a light proof of work |
| 3. Ingredients | The server sends, encrypted, the numbers for the exchange: a large prime, a generator and the server's public value | The shared ingredients for the key |
| 4. Check, then send your value | The app must check the received numbers are safe, then sends its own public value | Accepting weak numbers lets someone else compute the key |
| 5. Same key, confirmed | Both sides compute the same authorization key, and the server confirms with ok, retry or fail | The key itself never crosses the network |
At the end, the values used in the exchange also determine the first server salt. The salt is mixed into the encryption of later messages, and the server periodically sends new values.
Skip the step 4 checks and everything fails
One per data center, plus temporary keys
An authorization key is created separately for each data center; see data centers and _MIGRATE errors. On top of the long-lived permanent key, you can create temporary keys and bind them to it, so that even if the permanent key leaks later, past conversations cannot be decrypted (perfect forward secrecy). The official apps work this way.
A session file holding the authorization key is the account itself. Never let it leave the device; see MTProto at a glance.
FAQ
How is the Telegram authorization key created?
The app and server run a Diffie-Hellman exchange and each computes the same key; the key itself is never sent.
How does the app know it reached the real server?
It encrypts data with Telegram's RSA public key built into the app, which only the real server can decrypt.
What are temporary keys for?
Bound to the permanent key, they give perfect forward secrecy so a later leak cannot decrypt past traffic.
Sources
At a glance
- 1Steps
Hello, server check, ingredients, check and reply, confirm.
- 2Must check
Safe prime, generator and value ranges.
- 3Keys
One per data center; temporary keys give forward secrecy.
Updated
