The short answer
- 1The safest choice is a proven implementation: TDLib.
- 2During key creation, check the prime, the value ranges and the random values.
- 3On every message check key, length, session, ID and time; any failure means drop and disconnect.
In this article
The conclusion first: don't build it yourself
Telegram publishes client security guidelines for developers who want to implement MTProto themselves. Most people who read them reach the same conclusion: using a proven implementation, TDLib, is the safest choice. See building TDLib.
Below are the names and purposes of the checks you must make if you do implement it yourself. The actual conditions, including exact ranges, are in the official guidelines; follow them as written.
Checks when creating the key
| Check | What it means |
|---|---|
| Is the received prime safe? | The prime the server sent for the key exchange really is a safe prime, of the right size |
| Range of the generator and public values | They are not too small or right at the edge of the range; weak values reveal the key |
| Response hash | After decrypting a response, the hash attached to it matches the content |
| Random values match | The random values exchanged in this session are the same as at the start, so no other exchange slipped in |
| Quality of your secret value | Your own secret exponent comes from a secure random number generator, not straight from randomness the server supplied |
What these steps do is explained in creating an authorization key.
Checks on every message you receive
| Check | What it means |
|---|---|
| Message key | The value recomputed from the decrypted content equals the message key attached to it; this detects forgery and tampering |
| Length and padding | The length written inside is not larger than the real data, and the padding length is within the allowed range |
| Session ID | It is the session your app created |
| Message ID | It has the right even or odd parity for its direction, and repeats no ID already received |
| Time | The time encoded in the message ID is not too far from now, which blocks replays of old messages |
If any check fails, drop it and disconnect
Before you implement it yourself
- Is there truly a reason TDLib will not work? Language and platform issues are mostly solved by
tdjson. - Have you read the official guidelines and protocol documents from start to finish, and written a test for every check above?
- If you support secret chats, do you follow the rekeying and sequence number rules? See secret chat encryption.
- Does your app meet the privacy and security obligations in the terms? See the API terms of service.
FAQ
Should I implement MTProto myself?
Usually not. The guidelines show how many checks are required; TDLib already implements them.
What must I check during the key exchange?
That the prime is safe, the generator and public values are in range, hashes match and nonces are unchanged.
What if a message fails a security check?
Discard it, close the connection and reconnect.
Sources
At a glance
- 1Key checks
Safe prime, ranges, hashes, nonces, your own randomness.
- 2Message checks
msg_key, length, session, parity and replay, time.
- 3On failure
Discard, disconnect, retry; never log details.
Updated
