@node FAQ Telegram
@section Безопасен ли Telegram?

@strong{Ни в коем случае}. Сосед вряд ли сможет прочитать ваши
сообщения, но сами сервера Telegram или спецслужбы смогут без проблем.

В данном разделе рассматривается только @emph{MTProto} протокол
шифрования. MTProto и соответствующий конкурс по его взлому являются
классическим примером
@url{https://www.schneier.com/crypto-gram/archives/1999/0215.html#snakeoil, шарлатанской криптографии}.

Более подробная информация, небольшой анализ на английском есть
@url{http://unhandledexpression.com/2013/12/17/telegram-stand-back-we-know-maths/, тут} и
@url{http://www.cryptofails.com/post/70546720222/telegrams-cryptanalysis-contest, тут}.

@menu
* Отсутствует аутентификация пользователя: FAQ Telegram аутентификация.
* DH использует сервер: FAQ Telegram DH сервер.
* Априори известные небезопасные алгоритмы: FAQ Telegram алгоритмы.
* Но конкурс по взлому же никто не выиграл!: FAQ Telegram конкурс.
* Существующие протоколы замедляют передачу данных: FAQ Telegram медленный.
* Но ведь его написали сильные математики!: FAQ Telegram математики.
@end menu

@node FAQ Telegram аутентификация
@subsection Отсутствует аутентификация пользователя

Это самый серьёзный и фатальный (после чего его бессмысленно
использовать) недостаток. При установлении соединения между
пользователями они никак не аутентифицируют друг друга. То есть
пользователь не знает действительно ли он разговаривает с нужным ему
собеседником или с сервером который просто переотправляет собеседнику
сообщения. То есть это то что называется атакой человек-по-середине.

@node FAQ Telegram DH сервер
@subsection DH использует сервер

Первый выложенный исходный код протокола имел код при котором в
протоколе Диффи-Хельмана принимал участие и сервер: от него принимались
данные которые надо было подмешивать в DH сообщения. Потенциально он мог
полностью ослабить общий установленный ключ, опять же сведя безопасность
на нет и для внешнего наблюдателя (не только для серверов Telegram).

Это похоже исправили и убрали, мотивируя тем что это была защита от
устройств где плохой генератор случайных чисел. Возможно действительно
было сделано не со зла.

@node FAQ Telegram алгоритмы
@subsection Априори известные небезопасные алгоритмы

Любое сообщение должно быть зашифровано и аутентифицировано (то есть
добавлена информация гарантирующая что сообщение пришло именно от
нужного пользователя и без изменений). Как правило используют код
аутентичности сообщения (MAC) для аутентификации.

Есть разные варианты порядка как провести шифрование и аутентификацию:

@table @asis
@item Encrypt-then-MAC
Зашифровать, затем добавить MAC от шифротекста (так делают в IPsec)
@item MAC-then-Encrypt
Добавить MAC от открытого текста, затем зашифровать (так делают в TLS)
@item Encrypt-and-MAC
Зашифровать, затем добавить MAC от открытого текста (так делали в SSH)
@end table

Первый вариант @strong{всегда} правильный и не имеет недостатков. Второй
вариант при некоторых режимах работы даёт возможность очень серьёзных
атак типа @url{https://en.wikipedia.org/wiki/Transport_Layer_Security#BEAST_attack, BEAST}
и в целом @url{http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.106.5488&rep=rep1&type=pdf, не может считать безопасным}.
Третий даёт ещё большее количество атак, но на момент создания SSH об
этом мир криптографии ещё просто не знал. Не имеет смысла использовать
ничего кроме первого варианта.

MTProto использует фактически третий вариант. Если при первом варианте
нужно будет вычислить например HMAC и если он даст отрицательный
результат, то больше ничего не предпринимать, то в MTProto нужно
вычислить И хэш И дешифровать сообщение чтобы понять что оно не
аутентифицировано. То есть самая плохая производительность и
безопасность.

SHA1 используемый MTProto является устаревшим алгоритмом, не безопасным
для современного использования. Telegram говорит что он выбран из-за
производительности. Возможно и так, но он не намного медленнее (на
современных процессорах) SHA2, который безопасен.

Более того, MTProto использует
@url{https://www.mgp25.com/AESIGE/, IGE режим шифрования}
более никому не известный. Абсолютно непонятно зачем. Если им надо было
достичь того что ошибка дешифрования распространялась бы и дальше, то
почему не использовать
@url{https://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Cipher_Feedback_.28CFB.29, CFB}?
В любом случае если есть аутентификация сообщений, то error propagation
не имеет никакого смысла. Разумнее было бы выбрать например режим
счётчика
@url{https://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Counter_.28CTR.29, CTR},
позволяющий распараллеливать шифрование и дешифрование.

Ключ шифрования зависит от открытого текста. В целом это плохо. Это
возможные атаки, статистический анализ, но не означает что фатально.
Ничто не мешало бы сделать ключ независимым от открытого текста. Кроме
того, получается что для каждого сообщения необходимо проводить
процедуру инициализации AES ключа -- это дорогая (медленная) операция.
Везде стараются не менять ключ блочного шифра как можно дольше ради
производительности.

@node FAQ Telegram конкурс
@subsection Но конкурс по взлому же никто не выиграл!

И вряд ли выиграет, так как практически всегда подобные конкурсы
@url{http://www.thoughtcrime.org/blog/telegram-crypto-challenge/, должны настораживать}
и не несут
@url{https://www.schneier.com/crypto-gram/archives/1998/1215.html#contests, никакого смысла}.

@itemize

@item Конкурсы нечестны. Они часто выставляют условия не
соответствующие реальному миру, реальным атакам. Telegram предлагает
перехватить шифротексты и их дешифровать, но не даёт возможности
проводить общение с сервером или пользователям, не даёт проводить анализ
шифротекста зная открытый текст (known plaintext attack), не даёт
отправлять и смотреть реакцию на специально подготовленный открытый
текст (chosen plaintext attack) или шифротекст (chosen ciphertext
attack). То есть это можно сравнить с: попробуйте взломать мою квартиру,
но условимся что вы безрукий инвалид без инструментов.

@item Конкурсы не компенсируют затраты за взлом. Telegram не предлагает
показать как можно совершить атаку, а предлагает её выполнить до конца.
Криптография, криптоанализ может показать что, например, вам надо
перехватить сообщение и сделать перебор каких-нибудь данных в количестве
2**64. Это криптографически несерьёзное число: с ним могут справится
суперкомпьютеры которые есть у многих корпораций и государств, но нет
у простых людей. Аренда вычислительных мощностей для проведения 2**64
операций может стоить дороже чем выигрыш в конкурсе.

@end itemize

Поэтому участвовать в конкурсах и не выгодно и не интересно.

@node FAQ Telegram медленный
@subsection Существующие протоколы замедляют передачу данных

В мобильных сетях связи самое главное это уменьшить количество
round-trip пакетов данных, уменьшить количество пакетов, так как очень
большие задержки, но хорошая пропускная способность.

Если речь про транспортные протоколы: XMPP, HTTP и подобные -- то,
действительно, они не очень эффективны и визуально будут сильно
медленнее из-за задержек между round-trip.

Если речь именно про уровень обеспечивающий шифрование, то в TLS тоже
много round-trip-ов при установлении соединения, при процессе
рукопожатия. Этот процесс идёт только один раз за сеанс связи с
пользователем. Дальше, как и в преобладающем большинстве протоколов
шифрования: одно сообщение пользователя -- один сетевой пакет.

Если речь про производительность именно алгоритмов шифрования, то
MTProto использует алгоритмы "как у всех": AES, SHA1, DH и RSA. AES и
SHA1 не самые быстрые. Асимметричные алгоритмы DH и RSA существенно
медленнее чем их аналоги основанные на эллиптических кривых. Так что
производительность MTProto далеко не лучшая, особенно учитывая смену
ключей AES для каждого сообщения.

@node FAQ Telegram математики
@subsection Но ведь его написали сильные математики!

Сильный математик не означает криптограф (тем более сильный). На данный
момент в их протоколе множество недочётов свойственных новичкам (либо
сделанных специально для облегчения жизни тем кто хочет дешифровать).
Дуров в первую очередь деловой человек, а приватность пользователей
вредна для любого бизнеса.