MTProto часто воспринимают как название алгоритма шифрования Telegram. На самом деле перед нами целая система. MTProto определяет, как клиент договаривается с сервером о ключах, как сериализует запросы, формирует сообщения, проверяет порядок пакетов, шифрует данные и отправляет их через TCP, HTTP или WebSocket. AES здесь лишь один из компонентов.
Главное различие я бы запомнил сразу. Обычный чат Telegram и секретный чат используют MTProto с разной моделью доверия. В облачном чате защищён канал между приложением и инфраструктурой Telegram. Сервер участвует в криптографическом обмене и способен обработать содержимое сообщения. В секретном чате появляется дополнительное сквозное шифрование между двумя конкретными устройствами. Поэтому фраза «Telegram использует MTProto, значит вся переписка зашифрована от сервера» технически неверна.
Материал предназначен для легального и ответственного изучения сетевых технологий и защиты данных. Соблюдайте законодательство своей страны, особенно России. Описанные механизмы нельзя применять для несанкционированного доступа, слежки, взлома, нарушения правил сервисов или незаконного обхода ограничений.
MTProto состоит не из одного протокола, а из нескольких слоёв
В официальной архитектуре MTProto Telegram делит систему на три почти независимых компонента. Верхний слой задаёт API и формат запросов. Криптографический слой отвечает за авторизацию, ключи и защиту сообщений. Транспортный слой перевозит уже сформированные пакеты через сеть.
Приложение Telegram
|
v
TL / RPC API
структуры запросов и ответов
|
v
MTProto session
msg_id, seq_no, salt
|
v
Криптографический слой
auth_key + msg_key
AES-256-IGE
|
v
MTProto transport
Abridged / Intermediate /
Padded Intermediate / Full
|
v
TCP / HTTP / HTTPS /
WebSocket / WSS
|
v
Сервер TelegramТакое разделение объясняет сразу несколько популярных заблуждений. Abridged и Full не являются разными версиями шифрования. Номер слоя API тоже не означает «MTProto 214» или другую версию криптографии. А MTProxy вообще находится ближе к сетевой доставке и обфускации трафика.
Актуальная криптографическая версия называется MTProto 2.0. Старая MTProto 1.0 считается устаревшей. Во второй версии Telegram перешёл на SHA-256 в критичных местах, включил случайное дополнение сообщения в расчёт ключа сообщения и связал msg_key с частью основного ключа авторизации.
Как Telegram получает ключ и шифрует одно сообщение
До отправки обычных облачных сообщений клиенту нужен auth_key. Это 2048-битный ключ, общий для конкретного клиента и сервера Telegram. Клиент не получает готовый ключ по сети, а вычисляет его в ходе обмена Диффи-Хеллмана.
Упрощённо начальная авторизация выглядит так.
- Клиент начинает обмен. Приложение отправляет случайный nonce и запрашивает параметры авторизации.
- Сервер отвечает. Клиент получает дополнительные случайные значения, составное число pq и отпечатки известных открытых RSA-ключей Telegram.
- Клиент проверяет сервер. Часть начального обмена защищается RSA с использованием встроенного в приложение открытого ключа Telegram.
- Стороны переходят к Диффи-Хеллману. Клиент проверяет параметры группы, вычисляет свою часть обмена и получает общий 2048-битный auth_key.
- Начинается защищённая сессия. Дальнейшие сообщения шифруются с ключами, которые выводятся из auth_key и параметров конкретного сообщения.
RSA здесь не шифрует каждое сообщение Telegram. Его роль связана с начальной установкой защищённого канала. Основной трафик использует симметричную криптографию, что намного дешевле по вычислениям.
Для идентификации auth_key Telegram вычисляет SHA-1 и берёт младшие 64 бита результата. Здесь иногда возникает паника из-за давно скомпрометированной коллизионной стойкости SHA-1. Но SHA-1 в MTProto 2.0 не защищает содержимое сообщения и не служит основным механизмом проверки его целостности. Алгоритм сохранился в функции идентификатора ключа.
Перед шифрованием Telegram не берёт строку «Привет» и не отправляет её прямо в AES. Формируется структура с большим количеством метаданных.
server_salt
session_id
message_id
sequence_number
message_length
message_data
random_paddingServer salt помогает противодействовать повторному воспроизведению сообщений. Session ID разделяет экземпляры сессий. Message ID связан со временем создания сообщения. Sequence number помогает контролировать последовательность. В MTProto 2.0 в конец добавляют от 12 до 1024 случайных байтов так, чтобы итоговый блок подходил для шифрования.
Дальше начинается наиболее характерная часть MTProto. Протокол не хранит один постоянный 256-битный ключ AES и не шифрует им всё подряд. Для каждого сообщения сначала вычисляется msg_key, а затем из msg_key и фрагментов auth_key выводятся рабочие aes_key и aes_iv.
Спецификация MTProto 2.0 описывает схему примерно так.
msg_key_large =
SHA256(
substr(auth_key, 88 + x, 32)
+ plaintext
)
msg_key =
substr(msg_key_large, 8, 16)
sha256_a =
SHA256(
msg_key
+ substr(auth_key, x, 36)
)
sha256_b =
SHA256(
substr(auth_key, 40 + x, 36)
+ msg_key
)
aes_key =
substr(sha256_a, 0, 8)
+ substr(sha256_b, 8, 16)
+ substr(sha256_a, 24, 8)
aes_iv =
substr(sha256_b, 0, 8)
+ substr(sha256_a, 8, 16)
+ substr(sha256_b, 24, 8)Для направления от клиента к серверу используется x = 0, в обратную сторону x = 8. Разные области auth_key дают разные параметры для двух направлений связи.
Полученный блок шифруется AES-256 в режиме IGE, Infinite Garble Extension. IGE заметно отличается от более привычных сегодня конструкций вроде AES-GCM. Режим не предоставляет аутентифицированное шифрование сам по себе, поэтому MTProto строит проверку целостности отдельно через msg_key, ключевой материал и проверяемые поля внутри расшифрованного сообщения.
Получателю приходит внешний заголовок с 64-битным auth_key_id, 128-битным msg_key и зашифрованная полезная нагрузка. Сервер находит нужный auth_key, выводит AES-ключ и вектор инициализации, расшифровывает пакет, заново вычисляет msg_key и проверяет служебные поля.
Поэтому выражение «Telegram использует AES-256» почти ничего не говорит о безопасности MTProto. Криптографическая система определяется не длиной AES-ключа, а всей конструкцией вокруг AES, генерацией ключей, проверкой сообщений, обработкой состояний и реализацией клиента и сервера.
Облачные и секретные чаты устроены принципиально по-разному
| Свойство | Облачный чат | Секретный чат |
|---|---|---|
| Защита между клиентом и сервером | Да | Да |
| Сквозное шифрование между собеседниками | Нет | Да |
| Telegram участвует в криптографическом канале содержимого | Да | Нет для дополнительного слоя E2EE |
| Облачная история | Да | Нет |
| Синхронизация переписки между устройствами | Да | Нет |
| Групповые текстовые чаты | Да | Нет |
В обычном чате ключ авторизации разделяют клиент и Telegram. Поэтому инфраструктура сервиса является конечной точкой защищённого канала. Перехватчик Wi-Fi или оператор связи не получает текст сообщения только потому, что видит сетевой трафик, но архитектура не исключает Telegram из модели доверия.
Секретный чат добавляет другой ключ. Два устройства проводят собственный обмен Диффи-Хеллмана и получают 256-байтовый общий секрет. Сообщение сначала защищается сквозным слоем, а затем зашифрованный результат передаётся через обычную инфраструктуру Telegram. Подробную процедуру Telegram публикует в описании Secret Chats.
Устройство A
|
| E2EE ciphertext
v
Telegram
|
| E2EE ciphertext
v
Устройство BСервер здесь нужен для доставки, но ключ секретного чата должен оставаться у двух участвующих устройств. Поэтому секретные чаты привязаны не просто к аккаунтам, а к конкретным авторизациям устройств. Созданный на телефоне секретный диалог нельзя автоматически открыть на ноутбуке только после входа в тот же аккаунт.
Для секретных чатов Telegram также предусматривает прямую секретность. Официальные клиенты меняют ключ после более чем 100 обработанных сообщений либо после недели его использования при наличии хотя бы одного сообщения. Старый ключ затем удаляется. Компрометация нового ключа не должна автоматически раскрывать предыдущую переписку.
MTProto предусматривает механизм прямой секретности и для соединения клиент-сервер через временные ключи авторизации. Временный ключ связывается с постоянным auth_key и может храниться только ограниченное время. Для фактического получения такого свойства клиент должен действительно использовать временные ключи согласно протоколу.
Практический вывод здесь намного важнее всей математики. Облачное шифрование хорошо защищает данные при передаче через чужую сеть, но не решает задачу «не доверять оператору сервиса». Секретный чат меняет именно модель доверия. Если нужна инструкция по пользовательской стороне режима, мы отдельно разбирали, как работает секретный чат Telegram.
Почему криптографы спорят о MTProto
Главная претензия к MTProto никогда не сводилась к фразе «AES плохой». AES как раз хорошо изучен. Споры вызывает собственная криптографическая конструкция Telegram. Вместо широко распространённой комбинации стандартного протокола установления соединения и современного аутентифицированного шифрования разработчики собрали отдельную схему из AES-IGE, SHA-256, собственного вывода ключей, заголовков и правил обработки состояния.
У собственного протокола есть инженерные причины. Telegram проектировал систему для мобильных сетей, нескольких параллельных соединений, больших файлов, нестабильной связи и быстрого восстановления сессий. Но нестандартная криптография увеличивает объём кода и количество свойств, которые приходится доказывать отдельно.
История MTProto хорошо показывает разницу между фразами «протокол сломан» и «исследователи нашли проблемы». У первой версии действительно были криптографические претензии, после которых Telegram изменил конструкцию. MTProto 2.0 позже прошёл несколько формальных исследований.
Особенно интересен опубликованный в Journal of Cryptology подробный анализ MTProto 2.0. Исследователи построили формальную модель защищённого канала и смогли доказать конфиденциальность и целостность для слегка скорректированной конструкции при определённых криптографических предположениях. Одновременно работа описала атаки на исходное поведение протокола и реализации.
Среди найденных проблем были перестановка сообщений, особенности повторного шифрования, временные побочные каналы в официальных клиентах и атака на серверную реализацию начального обмена ключами. Полная цепочка восстановления данных требовала сложных условий и не считалась практичной массовой атакой. Исследователи сообщили Telegram о проблемах в 2021 году. По их данным, исправления вошли в Android 7.8.1, iOS 7.8.3 и Telegram Desktop 2.8.8.
Поэтому писать сегодня «исследователи взломали MTProto» без уточнений неправильно. Описанные атаки относились к старому поведению и были исправлены. Но противоположный лозунг «безопасность MTProto математически доказана и обсуждать больше нечего» тоже слишком сильный. Формальный результат опирается на конкретную модель и дополнительные предположения о свойствах используемых конструкций.
Мне здесь ближе скучная инженерная позиция. MTProto 2.0 нельзя честно назвать примитивной самоделкой, которую давно сломали. Протокол документирован, подвергался серьёзному академическому анализу и менялся после найденных проблем. Но собственная конструкция объективно сложнее для анализа, чем привычный стек из хорошо изученного обмена ключами и стандартного AEAD.
Отдельно не стоит путать MTProto с MTProxy. Прокси лишь принимает защищённый трафик Telegram и пересылает его дальше. Владелец MTProxy не получает auth_key только благодаря своему положению между клиентом и Telegram, поэтому обычное содержимое MTProto-пакетов ему недоступно. Зато прокси способен видеть IP клиента, время соединений, объёмы трафика и сам факт подключения, а также может блокировать или задерживать пакеты. Подробную сетевую часть мы разбирали в материале про устройство MTProxy.
Обфускацию тоже не надо принимать за криптографическую суперсилу. Padded Intermediate, транспортная маскировка и MTProxy пытаются изменить сетевой отпечаток соединения. Такие механизмы не превращают облачный чат в секретный и не дают пользователю анонимность на уровне всей сети.
В результате я бы оценивал MTProto не по числу «256» рядом с AES, а по задаче. Для защиты трафика между приложением и инфраструктурой Telegram протокол создаёт сложный защищённый канал. Для конфиденциальности от самого сервиса нужен другой режим, Secret Chat. Для анонимности одного MTProto недостаточно. А безопасность устройства, вредоносное ПО, украденная активная сессия и доступ к разблокированному телефону вообще находятся за пределами криптографии транспортного протокола.
Что такое MTProto простыми словами?
MTProto представляет собой собственный набор протоколов Telegram для обмена данными между приложением и серверами. Система задаёт формат сообщений, авторизацию, управление сессиями, криптографию и способы передачи пакетов через сеть.
MTProto обеспечивает сквозное шифрование Telegram?
Не для всех переписок. Обычные личные чаты и группы используют облачную модель с шифрованием между клиентом и сервером. Сквозное шифрование текста применяется в секретных чатах между двумя устройствами.
Может ли Telegram технически получить содержимое обычного чата?
Архитектура облачных чатов не исключает Telegram из модели доверия. Сервер является стороной клиент-серверного защищённого канала. Секретные чаты устроены иначе и используют дополнительный ключ, который должен находиться только на устройствах участников.
Почему MTProto использует AES-IGE, а не AES-GCM?
Такова собственная архитектура Telegram. AES-IGE выполняет шифрование, а проверка целостности строится дополнительными механизмами MTProto. Современные протоколы чаще выбирают готовые режимы аутентифицированного шифрования, поэтому нестандартная конструкция Telegram регулярно привлекает внимание криптографов.
Правда ли, что MTProto использует небезопасный SHA-1?
MTProto 2.0 использует SHA-256 в критичных операциях формирования ключа сообщения. SHA-1 сохранился для получения короткого идентификатора ключа авторизации, а не как основной механизм защиты содержимого переписки.
Чем MTProto отличается от MTProxy?
MTProto задаёт протокол связи и криптографию Telegram. MTProxy представляет собой промежуточный сетевой узел для передачи Telegram-трафика. Подключение через MTProxy не включает новое сквозное шифрование и не меняет облачный чат на секретный.
Можно ли считать MTProto взломанным?
Такая формулировка слишком грубая. Исследователи находили ошибки и атакуемое поведение в старых версиях протокола и реализаций. Telegram вносил исправления. Публичные исследования одновременно показывают как реальные слабые места конструкции, так и возможность доказать свойства конфиденциальности и целостности в определённых моделях.
Защитит ли MTProto переписку, если злоумышленник получил телефон?
Не обязательно. Шифрование сетевого канала не спасает данные, которые уже доступны разблокированному приложению. При физическом компрометировании устройства критичнее блокировка экрана, защита локального хранилища, контроль активных сессий и отсутствие вредоносного ПО.
Смысл MTProto проще всей его математики. Протокол хорошо защищает движение данных по сети, управляет сессиями и позволяет Telegram работать поверх разных транспортов. Но уровень конфиденциальности определяет не название протокола, а положение ключей. В облачном чате сервер остаётся частью доверительной модели. В секретном чате ключ переносится на конечные устройства. Поэтому перед чувствительной перепиской полезнее спросить «кто владеет ключами», чем искать успокаивающую надпись AES-256.
