faq/telegram.texi

   1 @node FAQ Telegram
   2 @section Безопасен ли Telegram?
   3
   4 @strong{Ни в коем случае}. Сосед вряд ли сможет прочитать ваши
   5 сообщения, но сами сервера Telegram или спецслужбы смогут без проблем.
   6
   7 В данном разделе рассматривается только @emph{MTProto} протокол
   8 шифрования. MTProto и соответствующий конкурс по его взлому являются
   9 классическим примером
  10 @url{https://www.schneier.com/crypto-gram/archives/1999/0215.html#snakeoil, шарлатанской криптографии}.
  11
  12 @menu
  13 * Отсутствует аутентификация пользователя: FAQ Telegram аутентификация.
  14 * DH использует сервер: FAQ Telegram DH сервер.
  15 * Априори известные небезопасные алгоритмы: FAQ Telegram алгоритмы.
  16 * Но конкурс по взлому же никто не выиграл!: FAQ Telegram конкурс.
  17 * Существующие протоколы замедляют передачу данных: FAQ Telegram медленный.
  18 * Но ведь его написали сильные математики!: FAQ Telegram математики.
  19 @end menu
  20
  21 @node FAQ Telegram аутентификация
  22 @subsection Отсутствует аутентификация пользователя
  23
  24 Это самый серьёзный и фатальный (после чего его бессмысленно
  25 использовать) недостаток. При установлении соединения между
  26 пользователями они никак не аутентифицируют друг друга. То есть
  27 пользователь не знает действительно ли он разговаривает с нужным ему
  28 собеседником или с сервером который просто переотправляет собеседнику
  29 сообщения. То есть это то что называется атакой человек-по-середине.
  30
  31 @node FAQ Telegram DH сервер
  32 @subsection DH использует сервер
  33
  34 Первый выложенный исходный код протокола имел код при котором в
  35 протоколе Диффи-Хельмана принимал участие и сервер: от него принимались
  36 данные которые надо было подмешивать в DH сообщения. Потенциально он мог
  37 полностью ослабить общий установленный ключ, опять же сведя безопасность
  38 на нет и для внешнего наблюдателя (не только для серверов Telegram).
  39
  40 Это похоже исправили и убрали, мотивируя тем что это была защита от
  41 устройств где плохой генератор случайных чисел. Возможно действительно
  42 было сделано не со зла.
  43
  44 @node FAQ Telegram алгоритмы
  45 @subsection Априори известные небезопасные алгоритмы
  46
  47 Любое сообщение должно быть зашифровано и аутентифицировано (то есть
  48 добавлена информация гарантирующая что сообщение пришло именно от
  49 нужного пользователя и без изменений). Как правило используют код
  50 аутентичности сообщения (MAC) для аутентификации.
  51
  52 Есть разные вариант порядка как провести шифрование и аутентификацию:
  53
  54 @table @asis
  55 @item Encrypt-then-MAC
  56 Зашифровать, затем добавить MAC от шифротекста (так делают в IPsec)
  57 @item MAC-then-Encrypt
  58 Добавить MAC от открытого текста, затем зашифровать (так делают в TLS)
  59 @item Encrypt-and-MAC
  60 Зашифровать, затем добавить MAC от открытого текста (так делали в SSH)
  61 @end table
  62
  63 Первый вариант @strong{всегда} правильный и не имеет недостатков. Второй
  64 вариант при некоторых режимах работы даёт возможность очень серьёзных
  65 атак типа @url{https://en.wikipedia.org/wiki/Transport_Layer_Security#BEAST_attack, BEAST}.
  66 Третий даёт ещё большее количество атак, но на момент создания SSH об
  67 этом мир криптографии ещё просто не знал. Не имеет смысла использовать
  68 ничего кроме первого варианта.
  69
  70 MTProto использует фактически третий вариант. Если при первом варианте
  71 нужно будет вычислить например HMAC и если он даст отрицательный
  72 результат, то больше ничего не предпринимать, то в MTProto нужно
  73 вычислить И хэш И дешифровать сообщение чтобы понять что оно не
  74 аутентифицировано. То есть самая плохая производительность и
  75 безопасность.
  76
  77 Подробнее можно прочитать
  78 @url{http://unhandledexpression.com/2013/12/17/telegram-stand-back-we-know-maths/,
  79 тут}
  80 и
  81 @url{http://www.cryptofails.com/post/70546720222/telegrams-cryptanalysis-contest, тут}.
  82
  83 SHA1 используемый MTProto является deprecated алгоритмом, не безопасным
  84 для современного использования. Telegram говорит что он выбран из-за
  85 производительности. Возможно и так, но он не намного медленнее (на
  86 современных процессорах) SHA2, который безопасен.
  87
  88 Более того, MTProto использует
  89 @url{https://www.mgp25.com/AESIGE/, IGE режим шифрования}
  90 более никому не известный. Абсолютно непонятно зачем. Если им надо было
  91 достичь того что ошибка дешифрования распространялась бы и дальше, то
  92 почему не использовать
  93 @url{https://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Cipher_Feedback_.28CFB.29, CFB}?
  94 В любом случае если есть аутентификация сообщений, то error propagation
  95 не имеет никакого смысла. Разумнее было бы выбрать например режим
  96 счётчика
  97 @url{https://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Counter_.28CTR.29, CTR}
  98 позволяющий распараллеливать шифрование и дешифрование.
  99
 100 Ключ шифрования зависит от открытого текста. В целом это плохо это
 101 возможные атаки, статистический анализ, но не означает что фатально.
 102 Ничто не мешало бы сделать ключ независимым от открытого текста. Кроме
 103 того, получается что для каждого сообщения необходимо проводить
 104 процедуру инициализации AES ключа -- это дорогая (медленная) операция.
 105 Везде стараются не менять ключ блочного шифра как можно дольше ради
 106 производительности.
 107
 108 @node FAQ Telegram конкурс
 109 @subsection Но конкурс по взлому же никто не выиграл!
 110
 111 И вряд ли выиграет, так как практически всегда подобные конкурсы не
 112 несут
 113 @url{https://www.schneier.com/crypto-gram/archives/1998/1215.html#contests, никакого смысла}.
 114
 115 @itemize
 116
 117 @item Конкурсы нечестны. Они часто выставляют условия не
 118 соответствующие реальному миру, реальным атакам. Telegram предлагает
 119 перехватить шифротексты и их дешифровать, но не даёт возможности
 120 проводить общение с сервером или пользователям, не даёт проводить анализ
 121 шифротекста зная открытый текст (known plaintext attack), не даёт
 122 отправлять и смотреть реакцию на специально подготовленный открытый
 123 текст (chosen plaintext attack) или шифротекст (chosen ciphertext
 124 attack). То есть это можно сравнить с: попробуйте взломать мою квартиру,
 125 но условимся что вы безрукий инвалид без инструментов.
 126
 127 @item Конкурсы не компенсируют затраты за взлом. Telegram не предлагает
 128 показать как можно совершить атаку, а предлагает её выполнить до конца.
 129 Криптография, криптоанализ может показать что, например, вам надо
 130 перехватить сообщение и сделать перебор каких-нибудь данных в количестве
 131 2**64. Это криптографически несерьёзное число: с ним могут справится
 132 суперкомпьютеры которые есть у многих корпораций и государств, но их нет
 133 у простых людей. Аренда вычислительных мощностей для проведения 2**64
 134 операций может стоить дороже чем выигрыш в конкурсе.
 135
 136 @end itemize
 137
 138 Поэтому участвовать в конкурсах просто и не выгодно и не интересно, так
 139 как они не отражают весь спектр возможных атак.
 140
 141 @node FAQ Telegram медленный
 142 @subsection Существующие протоколы замедляют передачу данных
 143
 144 В мобильных сетях связи самое главное это уменьшить количество
 145 round-trip пакетов данных, уменьшить количество пакетов, так как очень
 146 большие задержки, но хорошая пропускная способность.
 147
 148 Если речь про транспортные протоколы: XMPP, HTTP и подобные -- то
 149 действительно они не очень эффективны и визуально будут сильно медленнее
 150 из-за задержек между round-trip.
 151
 152 Если речь про именно про уровень обеспечивающий шифрование, то в TLS
 153 тоже действительно много round-trip-ов при установлении соединения, при
 154 процессе рупопожатия. Этот процесс идёт только один раз за сеанс связи с
 155 пользователем. Дальше, как и в преобладающем большинстве протоколов
 156 шифрования: одно сообщение пользователя -- один сетевой пакет.
 157
 158 Если речь про производительность именно алгоритмов шифрования, то
 159 MTProto использует симметричные алгоритмы "как у всех": AES, SHA1, DH и
 160 RSA. AES и RSA не самые быстрые. Асимметричные алгоритмы DH и RSA
 161 существенно медленнее чем их аналоги основанные на эллиптических кривых.
 162 Так что производительность MTProto далеко не лучшая, особенно учитывая
 163 смену ключей AES для каждого сообщения.
 164
 165 @node FAQ Telegram математики
 166 @subsection Но ведь его написали сильные математики!
 167
 168 Сильный математик не означает криптограф (тем более сильный). На данный
 169 момент в их протоколе множество недочётов свойственных новичкам (либо
 170 сделанных специально так для облегчения жизни для тех кто хочет
 171 дешифровать). Дуров в первую очередь деловой человек, а приватность
 172 пользователей вредна для любого бизнеса.