From c29932a60cc7dd209588811a1dc83aa0bd37cea4 Mon Sep 17 00:00:00 2001 From: Sergey Matveev Date: Sun, 1 Nov 2015 19:41:28 +0300 Subject: [PATCH] =?utf8?q?=D0=AF=D0=B7=D1=8B=D0=BA=D0=BE=D0=B2=D1=8B=D0=B5?= =?utf8?q?=20=D0=BA=D0=BE=D1=81=D1=8F=D0=BA=D0=B8?= MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit --- faq/filecrypt.texi | 15 ++++++++------- faq/messenger.texi | 21 +++++++++++---------- faq/telegram.texi | 41 ++++++++++++++++++++--------------------- intro.texi | 11 +++++------ 4 files changed, 44 insertions(+), 44 deletions(-) diff --git a/faq/filecrypt.texi b/faq/filecrypt.texi index 93b7998..e28db44 100644 --- a/faq/filecrypt.texi +++ b/faq/filecrypt.texi @@ -1,14 +1,14 @@ @node FAQ Filecrypt @section Как зашифровать файл перед отправкой? -Допустим вам необходимо безопасно кому-то отправить файл. Интернет +Допустим, вам необходимо безопасно кому-то отправить файл. Интернет каналы априори небезопасны и поэтому вам потребуется зашифровать файл и аутентифицировать (подтвердить что он действительно отправлен вами и дошёл без искажений). -Во-первых вам заранее необходимо будет обменяться хоть какими-то данными -по сторонним каналам связи. Если это общий пароль, используемый в -качестве ключа, то им, если это асимметричная криптография на основе +Во-первых, вам заранее необходимо будет обменяться хоть какими-то +данными по сторонним каналам связи. Если это общий пароль, используемый +в качестве ключа, то им, если это асимметричная криптография на основе публичных ключей, то публичными ключами, если это заранее известные ответы на вопросы известные только вам, то значит иметь их. Без этих действий отправить безопасно файл вы не сможете. @@ -46,14 +46,15 @@ @strong{OpenPGP} -Рекомендуемый вариант. Рекомендуемая реализация OpenPGP стандарта это +Наилучший вариант. Рекомендуемая реализация OpenPGP стандарта это де-факто широкоиспользуемая программа @url{https://gnupg.org/, GnuPG}. Кроме шифрования файлов вы получаете ещё и возможность: @itemize @item подписывать файлы, ставя на них электронную цифровую подпись, -которую нельзя подделать, что используют в десятков дистрибутивах +которую нельзя подделать, что используют в десятках дистрибутивах различных операционных систем, гарантируя что программы попадают на ваш -компьютер не в искажённом виде (их не подменили встроив вирус например); +компьютер не в искажённом виде (их не подменили, например, встроив +вирус); @item шифровать и подписывать электронную почту. @end itemize diff --git a/faq/messenger.texi b/faq/messenger.texi index 92ad859..c19eb12 100644 --- a/faq/messenger.texi +++ b/faq/messenger.texi @@ -12,7 +12,7 @@ @url{https://otr.cypherpunks.ca/, Off-the-record} (OTR). Он может работать поверх любого транспортного протокола способного передавать английский текст (ASCII). Его можно рекомендовать: он существует уже -более десяти лет и хорошо проанализирован. +более десяти лет, хорошо проанализирован и имеет хорошую безопасность. Также можно рекомендовать его улучшенные версии: @url{https://www.whispersystems.org/blog/advanced-ratcheting/, TextSecure} @@ -30,27 +30,28 @@ протокол Диффи-Хельмана для создания сессионных ключей, нигде не сохраняющихся на жёстких дисках, при каждом сеансе связи -- компрометация долгоживущих OTR ключей не сможет обеспечить дешифрование -сообщений. То есть OTR обладает свойством "совершенной прямой +сообщений. То есть, OTR обладает свойством "совершенной прямой секретности" (perfect forward secrecy). @item Подписи OpenPGP дают гарантию что они сделаны именно автором и не могут быть подделаны. OTR имеет свойство "правдоподобного отрицания" (plausible deniability): третья сторона, сторонний наблюдатель, не может доказать ваше авторство над добавляемыми аутентификационными данными к -пересылаемым сообщениям. Вы можете только однократно проверить +пересылаемым сообщениям. Только вы сможете однократно проверить аутентичность приходящих данных. Более того, режим шифрования сообщений -выбран такой что он позволяет проводить модификацию данных и третья +выбран такой, что он позволяет проводить модификацию данных и третья сторона не может доказать что увиденные ею сообщения были получены без искажений. @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 протокол при каждом сеансе связи для того чтобы убедиться в подлинности diff --git a/faq/telegram.texi b/faq/telegram.texi index 3f22084..e861932 100644 --- a/faq/telegram.texi +++ b/faq/telegram.texi @@ -49,7 +49,7 @@ нужного пользователя и без изменений). Как правило используют код аутентичности сообщения (MAC) для аутентификации. -Есть разные вариант порядка как провести шифрование и аутентификацию: +Есть разные варианты порядка как провести шифрование и аутентификацию: @table @asis @item Encrypt-then-MAC @@ -80,7 +80,7 @@ MTProto использует фактически третий вариант. и @url{http://www.cryptofails.com/post/70546720222/telegrams-cryptanalysis-contest, тут}. -SHA1 используемый MTProto является deprecated алгоритмом, не безопасным +SHA1 используемый MTProto является устаревшим алгоритмом, не безопасным для современного использования. Telegram говорит что он выбран из-за производительности. Возможно и так, но он не намного медленнее (на современных процессорах) SHA2, который безопасен. @@ -94,10 +94,10 @@ SHA1 используемый MTProto является deprecated алгорит В любом случае если есть аутентификация сообщений, то 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}, позволяющий распараллеливать шифрование и дешифрование. -Ключ шифрования зависит от открытого текста. В целом это плохо это +Ключ шифрования зависит от открытого текста. В целом это плохо. Это возможные атаки, статистический анализ, но не означает что фатально. Ничто не мешало бы сделать ключ независимым от открытого текста. Кроме того, получается что для каждого сообщения необходимо проводить @@ -129,14 +129,13 @@ attack). То есть это можно сравнить с: попробуйт Криптография, криптоанализ может показать что, например, вам надо перехватить сообщение и сделать перебор каких-нибудь данных в количестве 2**64. Это криптографически несерьёзное число: с ним могут справится -суперкомпьютеры которые есть у многих корпораций и государств, но их нет +суперкомпьютеры которые есть у многих корпораций и государств, но нет у простых людей. Аренда вычислительных мощностей для проведения 2**64 операций может стоить дороже чем выигрыш в конкурсе. @end itemize -Поэтому участвовать в конкурсах просто и не выгодно и не интересно, так -как они не отражают весь спектр возможных атак. +Поэтому участвовать в конкурсах и не выгодно и не интересно. @node FAQ Telegram медленный @subsection Существующие протоколы замедляют передачу данных @@ -145,28 +144,28 @@ attack). То есть это можно сравнить с: попробуйт round-trip пакетов данных, уменьшить количество пакетов, так как очень большие задержки, но хорошая пропускная способность. -Если речь про транспортные протоколы: XMPP, HTTP и подобные -- то -действительно они не очень эффективны и визуально будут сильно медленнее -из-за задержек между round-trip. +Если речь про транспортные протоколы: XMPP, HTTP и подобные -- то, +действительно, они не очень эффективны и визуально будут сильно +медленнее из-за задержек между round-trip. -Если речь про именно про уровень обеспечивающий шифрование, то в TLS -тоже действительно много round-trip-ов при установлении соединения, при -процессе рупопожатия. Этот процесс идёт только один раз за сеанс связи с +Если речь именно про уровень обеспечивающий шифрование, то в TLS тоже +много round-trip-ов при установлении соединения, при процессе +рукопожатия. Этот процесс идёт только один раз за сеанс связи с пользователем. Дальше, как и в преобладающем большинстве протоколов шифрования: одно сообщение пользователя -- один сетевой пакет. Если речь про производительность именно алгоритмов шифрования, то -MTProto использует симметричные алгоритмы "как у всех": AES, SHA1, DH и -RSA. AES и RSA не самые быстрые. Асимметричные алгоритмы DH и RSA -существенно медленнее чем их аналоги основанные на эллиптических кривых. -Так что производительность MTProto далеко не лучшая, особенно учитывая -смену ключей AES для каждого сообщения. +MTProto использует алгоритмы "как у всех": AES, SHA1, DH и RSA. AES и +SHA1 не самые быстрые. Асимметричные алгоритмы DH и RSA существенно +медленнее чем их аналоги основанные на эллиптических кривых. Так что +производительность MTProto далеко не лучшая, особенно учитывая смену +ключей AES для каждого сообщения. @node FAQ Telegram математики @subsection Но ведь его написали сильные математики! Сильный математик не означает криптограф (тем более сильный). На данный момент в их протоколе множество недочётов свойственных новичкам (либо -сделанных специально так для облегчения жизни для тех кто хочет -дешифровать). Дуров в первую очередь деловой человек, а приватность -пользователей вредна для любого бизнеса. +сделанных специально для облегчения жизни тем кто хочет дешифровать). +Дуров в первую очередь деловой человек, а приватность пользователей +вредна для любого бизнеса. diff --git a/intro.texi b/intro.texi index 8b9ef87..f7ff4ed 100644 --- a/intro.texi +++ b/intro.texi @@ -5,10 +5,9 @@ что можно надёжно положиться. @item На практике мы используем не математику, а её реализацию в виде -программного кода, в котором могут быть ошибки, в котором могут быть -"закладки" и лазейки. Подавляющее большинство всех реализаций -откровенно убоги и корпорации и государственные агенства регулярно -находят способы их "взлома". +программного кода, в котором могут быть ошибки, "закладки" и лазейки. +Подавляющее большинство всех реализаций откровенно убоги и корпорации и +государственные агенства регулярно находят способы их "взлома". @item Остерегайтесь закрытого и коммерческого программного обеспечения. Десятилетия показали что в закрытом ПО всегда были, есть и будут @@ -30,8 +29,8 @@ не работает. @item Если у вас есть действительно что-то серьёзное, то не используйте -классические сетевые соединения. Не подключайте ноутбук важными данным к -Интернету. Если необходимо передать данные, то скопируйте их, +классические сетевые соединения. Не подключайте ноутбук с важными +данными к Интернету. Если необходимо передать данные, то скопируйте их, предварительно зашифровав, на USB-накопитель и отправьте через другой компьютер. @end itemize -- 2.44.0