--- /dev/null
+@node FAQ Messenger
+@section Какой messenger выбрать?
+
+Мы рассматриваем только вопрос криптографической безопасности. Удобство
+это всегда дело субъективное: @strong{не бывает} инструментов удобных
+одновременно и профессионалам и новичкам. Поэтому важно выбрать
+открытый и свободный @strong{протокол}: к нему уже может быть много
+различных клиентов (и серверов) которые смогут удовлетворить вопросы
+удобства самых разных пользователей.
+
+Самый широкоподдерживаемый различными клиентами протокол это
+@url{https://otr.cypherpunks.ca/, Off-the-record} (OTR). Он может
+работать поверх любого транспортного протокола способного передавать
+английский текст (ASCII). Его можно рекомендовать: он существует уже
+более десяти лет и хорошо проанализирован.
+
+Также можно рекомендовать его улучшенные версии:
+@url{https://www.whispersystems.org/blog/advanced-ratcheting/, TextSecure}
+и @url{https://github.com/trevp/axolotl/wiki, Axolotl}.
+
+Использовать OpenPGP систему для real-time общения можно, лучше чем
+ничего, но не рекомендуется:
+
+@itemize
+
+@item Компрометация OpenPGP ключей фатальна: потеряв их, сделав
+доступными злоумышленнику (например он установит keylogger и узнает
+парольную фразу от приватных ключей), все ваши отправленные сообщения
+можно будет дешифровать. OTR и производные от него протоколы используют
+протокол Диффи-Хельмана для создания сессионных ключей, нигде не
+сохраняющихся на жёстких дисках, при каждом сеансе связи --
+компрометация долгоживущих OTR ключей не сможет обеспечить дешифрование
+сообщений. То есть OTR обладает свойством "совершенной прямой
+секретности" (perfect forward secrecy).
+
+@item Подписи OpenPGP дают гарантию что они сделаны именно автором и не
+могут быть подделаны. OTR имеет свойство "правдоподобного отрицания"
+(plausible deniability): третья сторона, сторонний наблюдатель, не может
+доказать ваше авторство над добавляемыми аутентификационными данными к
+пересылаемым сообщениям. Вы можете только однократно проверить
+аутентичность приходящих данных. Более того, режим шифрования сообщений
+выбран такой что он позволяет проводить модификацию данных и третья
+сторона не может доказать что увиденные ею сообщения были получены без
+искажений.
+
+@item OpenPGP требует заранее установить доверие между собеседниками. Вы
+не можете безопасно общаться друг с другом пока не убедитесь что
+публичный ключ противоположной стороны действительно принадлежит
+человеку которого вы предполагаете. OTR же предлагает использование
+протокола SMP -- аутентификации собеседников с нулевым неразглашением
+(zero-knowledge password proof): пользователи могут задать друг другу
+вопросы и сравнить известные только им ответы, без утечки какой-либо
+информации о самих ответах в сеть. То есть даже если между вами окажется
+человек-по-середине (man-in-the-middle), то он не сможет узнать ответы и
+использовать их для аутентификации позже. Вы можете использовать SMP
+протокол при каждом сеансе связи для того чтобы убедиться в подлинности
+человека на противоположной стороне: ведь у человека силой могут
+скомпрометировать его ключ OTR или он мог просто его поменять или
+потерять.
+
+@end itemize
+
+OpenPGP имеет другую нишу использования, он хорошо справляется с иными
+задачами чем специализированные для real-time communication системы.
--- /dev/null
+@node FAQ Telegram
+@section Безопасен ли Telegram?
+
+@strong{Ни в коем случае}. Сосед вряд ли сможет прочитать ваши
+сообщения, но сами сервера Telegram или спецслужбы смогут без проблем.
+
+В данном разделе рассматривается только @emph{MTProto} протокол
+шифрования. MTProto и соответствующий конкурс по его взлому являются
+классическим примером
+@url{https://www.schneier.com/crypto-gram/archives/1999/0215.html#snakeoil, шарлатанской криптографии}.
+
+@menu
+* Отсутствует аутентификация пользователя: FAQ Telegram аутентификация.
+* DH использует сервер: FAQ Telegram DH сервер.
+* Априори известные небезопасные алгоритмы: 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}.
+Третий даёт ещё большее количество атак, но на момент создания SSH об
+этом мир криптографии ещё просто не знал. Не имеет смысла использовать
+ничего кроме первого варианта.
+
+MTProto использует фактически третий вариант. Если при первом варианте
+нужно будет вычислить например HMAC и если он даст отрицательный
+результат, то больше ничего не предпринимать, то в MTProto нужно
+вычислить И хэш И дешифровать сообщение чтобы понять что оно не
+аутентифицировано. То есть самая плохая производительность и
+безопасность.
+
+Подробнее можно прочитать
+@url{http://unhandledexpression.com/2013/12/17/telegram-stand-back-we-know-maths/,
+тут}
+и
+@url{http://www.cryptofails.com/post/70546720222/telegrams-cryptanalysis-contest, тут}.
+
+SHA1 используемый MTProto является deprecated алгоритмом, не безопасным
+для современного использования. 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{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 и RSA не самые быстрые. Асимметричные алгоритмы DH и RSA
+существенно медленнее чем их аналоги основанные на эллиптических кривых.
+Так что производительность MTProto далеко не лучшая, особенно учитывая
+смену ключей AES для каждого сообщения.