@node FAQ Filecrypt
@section Как зашифровать файл перед отправкой?
-Допустим вам необходимо безопасно кому-то отправить файл. Интернет
+Допустим, вам необходимо безопасно кому-то отправить файл. Интернет
каналы априори небезопасны и поэтому вам потребуется зашифровать файл и
аутентифицировать (подтвердить что он действительно отправлен вами и
дошёл без искажений).
-Во-первых вам заранее необходимо будет обменяться хоть какими-то данными
-по Ñ\81Ñ\82оÑ\80онним каналам Ñ\81вÑ\8fзи. Ð\95Ñ\81ли Ñ\8dÑ\82о обÑ\89ий паÑ\80олÑ\8c, иÑ\81полÑ\8cзÑ\83емÑ\8bй в
-качестве ключа, то им, если это асимметричная криптография на основе
+Во-первых, вам заранее необходимо будет обменяться хоть какими-то
+даннÑ\8bми по Ñ\81Ñ\82оÑ\80онним каналам Ñ\81вÑ\8fзи. Ð\95Ñ\81ли Ñ\8dÑ\82о обÑ\89ий паÑ\80олÑ\8c, иÑ\81полÑ\8cзÑ\83емÑ\8bй
+в каÑ\87еÑ\81Ñ\82ве клÑ\8eÑ\87а, Ñ\82о им, еÑ\81ли Ñ\8dÑ\82о аÑ\81иммеÑ\82Ñ\80иÑ\87наÑ\8f кÑ\80ипÑ\82огÑ\80аÑ\84иÑ\8f на оÑ\81нове
публичных ключей, то публичными ключами, если это заранее известные
ответы на вопросы известные только вам, то значит иметь их. Без этих
действий отправить безопасно файл вы не сможете.
@strong{OpenPGP}
-РекомендÑ\83емÑ\8bй вариант. Рекомендуемая реализация OpenPGP стандарта это
+Ð\9dаилÑ\83Ñ\87Ñ\88ий вариант. Рекомендуемая реализация OpenPGP стандарта это
де-факто широкоиспользуемая программа @url{https://gnupg.org/, GnuPG}.
Кроме шифрования файлов вы получаете ещё и возможность:
@itemize
@item подписывать файлы, ставя на них электронную цифровую подпись,
-коÑ\82оÑ\80Ñ\83Ñ\8e нелÑ\8cзÑ\8f подделаÑ\82Ñ\8c, Ñ\87Ñ\82о иÑ\81полÑ\8cзÑ\83Ñ\8eÑ\82 в деÑ\81Ñ\8fÑ\82ков дистрибутивах
+коÑ\82оÑ\80Ñ\83Ñ\8e нелÑ\8cзÑ\8f подделаÑ\82Ñ\8c, Ñ\87Ñ\82о иÑ\81полÑ\8cзÑ\83Ñ\8eÑ\82 в деÑ\81Ñ\8fÑ\82каÑ\85 дистрибутивах
различных операционных систем, гарантируя что программы попадают на ваш
-компьютер не в искажённом виде (их не подменили встроив вирус например);
+компьютер не в искажённом виде (их не подменили, например, встроив
+вирус);
@item шифровать и подписывать электронную почту.
@end itemize
@url{https://otr.cypherpunks.ca/, Off-the-record} (OTR). Он может
работать поверх любого транспортного протокола способного передавать
английский текст (ASCII). Его можно рекомендовать: он существует уже
-более десяти лет и хорошо проанализирован.
+более десяти лет, хорошо проанализирован и имеет хорошую безопасность.
Также можно рекомендовать его улучшенные версии:
@url{https://www.whispersystems.org/blog/advanced-ratcheting/, TextSecure}
протокол Диффи-Хельмана для создания сессионных ключей, нигде не
сохраняющихся на жёстких дисках, при каждом сеансе связи --
компрометация долгоживущих OTR ключей не сможет обеспечить дешифрование
-сообщений. То есть OTR обладает свойством "совершенной прямой
+сообщений. То есть, OTR обладает свойством "совершенной прямой
секретности" (perfect forward secrecy).
@item Подписи OpenPGP дают гарантию что они сделаны именно автором и не
могут быть подделаны. OTR имеет свойство "правдоподобного отрицания"
(plausible deniability): третья сторона, сторонний наблюдатель, не может
доказать ваше авторство над добавляемыми аутентификационными данными к
-пеÑ\80еÑ\81Ñ\8bлаемÑ\8bм Ñ\81ообÑ\89ениÑ\8fм. Ð\92Ñ\8b можеÑ\82е Ñ\82олÑ\8cко однократно проверить
+пеÑ\80еÑ\81Ñ\8bлаемÑ\8bм Ñ\81ообÑ\89ениÑ\8fм. ТолÑ\8cко вÑ\8b Ñ\81можеÑ\82е однократно проверить
аутентичность приходящих данных. Более того, режим шифрования сообщений
-выбран такой что он позволяет проводить модификацию данных и третья
+выбран такой, что он позволяет проводить модификацию данных и третья
сторона не может доказать что увиденные ею сообщения были получены без
искажений.
@item OpenPGP требует заранее установить доверие между собеседниками. Вы
не можете безопасно общаться друг с другом пока не убедитесь что
-публичный ключ противоположной стороны действительно принадлежит
-человеку которого вы предполагаете. OTR же предлагает использование
-протокола SMP -- аутентификации собеседников с нулевым неразглашением
-(zero-knowledge password proof): пользователи могут задать друг другу
-вопросы и сравнить известные только им ответы, без утечки какой-либо
-информации о самих ответах в сеть. То есть даже если между вами окажется
+публичный ключ противоположной стороны действительно принадлежит нужному
+человеку. OTR же предлагает использование протокола
+@url{https://en.wikipedia.org/wiki/Socialist_millionaire, SMP} --
+аутентификации собеседников с нулевым неразглашением (zero-knowledge
+password proof): пользователи могут задать друг другу вопросы и сравнить
+известные только им ответы, без утечки какой-либо информации о самих
+ответах в сеть. То есть, даже если между вами окажется
человек-по-середине (man-in-the-middle), то он не сможет узнать ответы и
использовать их для аутентификации позже. Вы можете использовать SMP
протокол при каждом сеансе связи для того чтобы убедиться в подлинности
нужного пользователя и без изменений). Как правило используют код
аутентичности сообщения (MAC) для аутентификации.
-Есть разные вариант порядка как провести шифрование и аутентификацию:
+Есть разные варианты порядка как провести шифрование и аутентификацию:
@table @asis
@item Encrypt-then-MAC
и
@url{http://www.cryptofails.com/post/70546720222/telegrams-cryptanalysis-contest, тут}.
-SHA1 используемый MTProto является deprecated алгоритмом, не безопасным
+SHA1 используемый MTProto является устаревшим алгоритмом, не безопасным
для современного использования. Telegram говорит что он выбран из-за
производительности. Возможно и так, но он не намного медленнее (на
современных процессорах) SHA2, который безопасен.
В любом случае если есть аутентификация сообщений, то error propagation
не имеет никакого смысла. Разумнее было бы выбрать например режим
счётчика
-@url{https://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Counter_.28CTR.29, CTR}
+@url{https://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Counter_.28CTR.29, CTR},
позволяющий распараллеливать шифрование и дешифрование.
-Ключ шифрования зависит от открытого текста. В целом это плохо это
+Ключ шифрования зависит от открытого текста. В целом это плохо. Это
возможные атаки, статистический анализ, но не означает что фатально.
Ничто не мешало бы сделать ключ независимым от открытого текста. Кроме
того, получается что для каждого сообщения необходимо проводить
Криптография, криптоанализ может показать что, например, вам надо
перехватить сообщение и сделать перебор каких-нибудь данных в количестве
2**64. Это криптографически несерьёзное число: с ним могут справится
-Ñ\81Ñ\83пеÑ\80компÑ\8cÑ\8eÑ\82еÑ\80Ñ\8b коÑ\82оÑ\80Ñ\8bе еÑ\81Ñ\82Ñ\8c Ñ\83 многиÑ\85 коÑ\80поÑ\80аÑ\86ий и гоÑ\81Ñ\83даÑ\80Ñ\81Ñ\82в, но иÑ\85 неÑ\82
+суперкомпьютеры которые есть у многих корпораций и государств, но нет
у простых людей. Аренда вычислительных мощностей для проведения 2**64
операций может стоить дороже чем выигрыш в конкурсе.
@end itemize
-Поэтому участвовать в конкурсах просто и не выгодно и не интересно, так
-как они не отражают весь спектр возможных атак.
+Поэтому участвовать в конкурсах и не выгодно и не интересно.
@node FAQ Telegram медленный
@subsection Существующие протоколы замедляют передачу данных
round-trip пакетов данных, уменьшить количество пакетов, так как очень
большие задержки, но хорошая пропускная способность.
-Если речь про транспортные протоколы: XMPP, HTTP и подобные -- то
-действительно они не очень эффективны и визуально будут сильно медленнее
-из-за задержек между round-trip.
+Если речь про транспортные протоколы: XMPP, HTTP и подобные -- то,
+действительно, они не очень эффективны и визуально будут сильно
+медленнее из-за задеÑ\80жек междÑ\83 round-trip.
-Ð\95Ñ\81ли Ñ\80еÑ\87Ñ\8c пÑ\80о именно пÑ\80о Ñ\83Ñ\80овенÑ\8c обеÑ\81пеÑ\87иваÑ\8eÑ\89ий Ñ\88иÑ\84Ñ\80ование, Ñ\82о в TLS
-тоже действительно много round-trip-ов при установлении соединения, при
-процессе рупопожатия. Этот процесс идёт только один раз за сеанс связи с
+Ð\95Ñ\81ли Ñ\80еÑ\87Ñ\8c именно пÑ\80о Ñ\83Ñ\80овенÑ\8c обеÑ\81пеÑ\87иваÑ\8eÑ\89ий Ñ\88иÑ\84Ñ\80ование, Ñ\82о в TLS Ñ\82оже
+много round-trip-ов при установлении соединения, при процессе
+рукопожатия. Этот процесс идёт только один раз за сеанс связи с
пользователем. Дальше, как и в преобладающем большинстве протоколов
шифрования: одно сообщение пользователя -- один сетевой пакет.
Если речь про производительность именно алгоритмов шифрования, то
-MTProto использует симметричные алгоритмы "как у всех": AES, SHA1, DH и
-RSA. AES и RSA не самые быстрые. Асимметричные алгоритмы DH и RSA
-существенно медленнее чем их аналоги основанные на эллиптических кривых.
-Так Ñ\87Ñ\82о пÑ\80оизводиÑ\82елÑ\8cноÑ\81Ñ\82Ñ\8c MTProto далеко не лÑ\83Ñ\87Ñ\88аÑ\8f, оÑ\81обенно Ñ\83Ñ\87иÑ\82Ñ\8bваÑ\8f
-смену ключей AES для каждого сообщения.
+MTProto использует алгоритмы "как у всех": AES, SHA1, DH и RSA. AES и
+SHA1 не самые быстрые. Асимметричные алгоритмы DH и RSA существенно
+медленнее чем их аналоги основанные на эллиптических кривых. Так что
+пÑ\80оизводиÑ\82елÑ\8cноÑ\81Ñ\82Ñ\8c MTProto далеко не лÑ\83Ñ\87Ñ\88аÑ\8f, оÑ\81обенно Ñ\83Ñ\87иÑ\82Ñ\8bваÑ\8f Ñ\81менÑ\83
+ключей AES для каждого сообщения.
@node FAQ Telegram математики
@subsection Но ведь его написали сильные математики!
Сильный математик не означает криптограф (тем более сильный). На данный
момент в их протоколе множество недочётов свойственных новичкам (либо
-сделанных специально так для облегчения жизни для тех кто хочет
-деÑ\88иÑ\84Ñ\80оваÑ\82Ñ\8c). Ð\94Ñ\83Ñ\80ов в пеÑ\80вÑ\83Ñ\8e оÑ\87еÑ\80едÑ\8c деловой Ñ\87еловек, а пÑ\80иваÑ\82ноÑ\81Ñ\82Ñ\8c
-полÑ\8cзоваÑ\82елей вÑ\80една длÑ\8f лÑ\8eбого бизнеÑ\81а.
+сделанных специально для облегчения жизни тем кто хочет дешифровать).
+Ð\94Ñ\83Ñ\80ов в пеÑ\80вÑ\83Ñ\8e оÑ\87еÑ\80едÑ\8c деловой Ñ\87еловек, а пÑ\80иваÑ\82ноÑ\81Ñ\82Ñ\8c полÑ\8cзоваÑ\82елей
+вредна для любого бизнеса.
что можно надёжно положиться.
@item
На практике мы используем не математику, а её реализацию в виде
-программного кода, в котором могут быть ошибки, в котором могут быть
-"закладки" и лазейки. Подавляющее большинство всех реализаций
-откровенно убоги и корпорации и государственные агенства регулярно
-находят способы их "взлома".
+программного кода, в котором могут быть ошибки, "закладки" и лазейки.
+Подавляющее большинство всех реализаций откровенно убоги и корпорации и
+государственные агенства регулярно находят способы их "взлома".
@item
Остерегайтесь закрытого и коммерческого программного обеспечения.
Десятилетия показали что в закрытом ПО всегда были, есть и будут
не работает.
@item
Если у вас есть действительно что-то серьёзное, то не используйте
-классические сетевые соединения. Не подключайте ноутбук важными данным к
-Интернету. Если необходимо передать данные, то скопируйте их,
+классические сетевые соединения. Не подключайте ноутбук с важными
+даннÑ\8bми к Ð\98нÑ\82еÑ\80неÑ\82Ñ\83. Ð\95Ñ\81ли необÑ\85одимо пеÑ\80едаÑ\82Ñ\8c даннÑ\8bе, Ñ\82о Ñ\81копиÑ\80Ñ\83йÑ\82е иÑ\85,
предварительно зашифровав, на USB-накопитель и отправьте через другой
компьютер.
@end itemize