openPGP в России / Часто задаваемые вопросы / Криптография

==Криптография==

====={{a name="q1"}}Как устроена асимметричная криптография? Может ли взломщик по моему открытому ключу вычислить закрытый?=====
Цель асимметричной криптографии состоит в том, чтобы в приемлемые сроки эта задача оставалась невыполнимой. Как такое удаётся, спросите вы? Представьте, что у вас есть дорогие механические часы. Вы можете разобрать их на десятки и сотни крошечных деталей, пружинок и шестерёнок – это не потребует навыков часовщика, возможно только пара инструментов. Но без подробной инструкции по сборке у вас не будет ни малейшего шанса вернуть их в рабочий вид. Профессионалу это удастся и без инструкции. Но что, если эти часы состоят не из сотен, а из сотен миллионов деталей?

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

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

====={{a name="q2"}}Я хочу переслать своему корреспондунту открытый ключ, но опасаюсь, что в пути его могут подменить.=====
Самый надёжный способ – прибегнуть к помощи посредника. Если вы с корреспондентом располагаете __подлинной__ копией ключа некоего доверенного третьего лица, то можете обратиться к нему с просьбой подписать ваш открытый ключ. После этого можно не опасаясь отсылать его корреспонденту: подпись посредника будет гарантией, что ключ им проверен и принадлежит именно Вам, а также, что он не был подменён в процессе передачи. Такой способ основан на механизмах модели доверия PGP [[/Библиотека/Основы/СетьДоверия Web of Trust]].

Если воспользоваться им по какой-то причине затруднительно или невозможно, используйте другой – так называемый //протокол взаимоблокировки//. Последовательность действий в ходе его исполнения с помощью средств PGP такова (выполняйте точно по инструкции и строго по порядку!):

1. Вы отсылаете копию вашего открытого ключа корреспонденту.
  2. Корреспондент отсылает копию своего открытого ключа вам.
  3. Вы создаёте простой текстовый .txt-файл, дайте ему произвольное название, никак не связанное с процедурой. Поместите в него копию своего открытого ключа в ascii-формате: в менеджере PGPkeys нажмите правой кнопкой на свой ключ //> Copy//, затем вставьте его в файл. После материала ключа добавьте 10-20 случайных символов. Зашифруйте содержимое файла без подписания открытым ключом корреспондента, сохраните файл. Подпишите весь файл со съёмной подписью: откройте Проводник, найдите файл, нажмите на него правой кнопкой //> PGP > Sign//, поставьте галочки на //Detached Signature// и //Input Is Text// (если такая опция есть). Отправьте корреспонденту только файл цифровой подписи (~имя.txt.sig)!
  4. Ваш корреспондент выполняет действия, аналогичные вашим, описанным в пункте 3, но со своим ключом.
  5. Вы ждёте, пока получите от корреспондента его .sig-файл, затем отправляете ему оригинальный .txt-файл с вашим зашифрованным ключом.
  6. Корреспондент отправляет вам оригинальный .txt-файл со своим зашифрованным ключом.
  7. Ваш корреспондент складывает оба полученных от вас файла (.txt и .sig) в один каталог и сверяет подпись, запустив .sig-файл, затем, если подпись верна, своим закрытым ключом расшифровывает содержимое файла, получая ваш открытый ключ.
  8. Вы складываете оба полученных от него файла (.txt и .sig) в один каталог и сверяете подпись, запустив .sig-файл, затем, если подпись верна, своим закрытым ключом расшифровываете содержимое файла, получая его открытый ключ.
  9. Вы и ваш корреспондент сверяете строки случайных символов, включённые в передаваемые .txt-файлы.

Если сверка подписей показала, что все они были поставлены ключами, переданными на этапах 1-2, и эти же ключи находились зашифрованными в файлах, а строки случайных символов совпадают с теми, которые отправлялись первоначально, значит обмен завершён успешно. Суть протокола заключается в том, что если злоумышленник на этапах 1-2 перехватит ваши ключи и произведёт подмену, он всё равно не сможет узнать, какая информация передаётся на этапах 3-4 кроме того, что это цифровые подписи. Когда на этапах 5-6 будут переданы сами подписанные файлы, злоумышленник не сможет их подделать: любые изменения в их содержании будут обнаружены на этапах 7-8, равно, как будет обнаружена подмена ключей, произведённая злоумышленником на этапах 1-2.

Для наибольшей эффективности исполнять протокол стоит не по электронной почте, а через ту или иную программу передачи мгновенных сообщений, к примеру, ICQ. Такой метод согласования открытых ключей позволяет снизить риск их подмены, но не исключает его целиком. Метод довольно надёжен, но ни в коем случае не используйте его как средство проверки подлинности чужого ключа с целью его подписания.

====={{a name="q3"}}Какой асимметричный ключ – DH/DSS или RSA – более стоек?=====
Оба названных алгоритма основаны на гипотетически неразрешимых математических проблемах: проблеме дискретного логарифмирования в конечном поле и проблеме разложения на множители (факторизации) больших чисел соответственно. Асимптоты DH и RSA похожи, но, в целом, ключи RSA менее стойки.

В чисто вычислительном плане расчёт дискретного логарифма по модулю //p// оказывается несколько сложнее разложения //p// того же разряда на множители, так что RSA получается немного слабее. Действительно, на взлом 512-битового модуля RSA под эгидой "RSA Crypto Challenge" 2 августа 1999 года потребовалось около ~8.000 MIPS-лет, что оказалось примерно сопоставимым со взломом 365-битового модуля DH. Распределённые вычисления добились больших успехов во взломе модулей RSA, нежели DH. Брюс Шнайер: //«Для сопоставимого уровня стойкости пользователи RSA должны выбирать ключи большего размера, чем пользователи ключей DH, основанных на ""GF(p)""»//. (""GF(""//p//) – криптографически стойкий тип поля Галуа, используемый в PGP.)

Однако многие криптологи не склонны рассматривать вычислительные различия RSA и DH с практической точки зрения – они незначительны. Интереснее связь лежащих в их основе математических проблем. Тождественность стойкости алгоритмов этим проблемам не доказана (и не опровергнута, хотя в последние годы появились веские свидетельства в пользу того, что стойкость RSA не равна сложности факторизации //p//, и, напротив, что стойкость некоторых видов DH равна сложности дискретного логарифмирования), однако и более простой способ их взлома пока не найден. И хотя обе проблемы тесно связаны (развитие – позитивное или негативное – в одной области равным образом повлияет и на другую), ряд алгоритмов дискретного логарифмирования может быть сведён к разложению на множители, но не наоборот. Таким образом, //"проблема дискретного логарифмирования по меньшей мере столь же трудна, сколь и факторизация, и наверняка такой и останется"// (А.М. Одлыжко), что, опять же, говорит в пользу DH.

В то же время не в пользу ключей типа DH/DSS в PGP говорит тот факт, что главный ключ DSA, используемый для подписания данных и "связывания" различных элементов сертификата ключа, всегда равен 1024 битам независимо от длины подключа шифрования DH – к этому обязывает следование нормам стандарта Digital Signature Standard. Таким образом, неожиданный революционный прорыв в теории чисел или в алгоритмах дискретного логарифмирования может привести к взлому и компрометации этих ключей ранее, чем остальных. В то же время, 1024-битовые ключи в большинстве областей применения признаны достаточно надежными на ближайшие несколько лет.

События 2004 года в области криптоанализа хэш-функций также говорят против DH/DSS. Кроме ограничения ключа DSA 1024 битами, стандарт DSS предписывает использование хэш-функции SHA-1, в долгосрочной стойкости которой заставляют усомниться последние работы криптологов.

Здесь уместно отметить, что в настоящее время разработчиками PGP и ~GnuPG ведётся работа по реализации обновлённого стандарта DSS, допускающего применение 3072-битовых ключей и хэш-функций семейства SHA-2.

Помимо отмеченных недостатков, алгоритм DSA обладает ещё двумя особенностями. Так, в отличие от RSA, где выработка цифровой подписи достаточно прямолинейна (возведение в степень по модулю), для цифровой подписи DSS требуется случаное число //k//, вследствие чего даже при подписании идентичных документов подпись всегда будет разной. С другой стороны, если //k// будет "не совсем" случайным, то в алгоритме образуется так называемый //"скрытый канал"// (subliminal channel), с помощью которого недобросовестный разработчик программы может способствовать, например, незаметной утечке битов закрытого ключа пользователя. Это особенно актуальный вопрос для реализаций DSS, не поставляемых в исходных текстах, как было с PGP 7.x, где невозможно проверить наличие скрытого канала. Некоторые пользователи, обеспокоенные данным фактом и предположительным сотрудничеством NAI и АНБ, отказались в то время переходить на седьмые версии программы.

====={{a name="q4"}}Насколько крупным должен быть асимметричный ключ?=====
Не рассматривая скорость операций, которая на современных компьютерах малоразличима даже между 1024- и 4096-битовыми ключами, стоит сосредоточиться на аспекте безопасности.

Как известно, размер ключа и его надёжность находятся в экспоненциальной зависимости: добавление каждого бита к длине ключа увеличивает его стойкость примерно вдвое. Также известно, что PGP шифрует открытый текст случайным симметричным ключом, который затем зашифровывает асимметричным ключом. Таким образом, взлом конкретного симметричного ключа раскроет содержание лишь одного сообщения, но взлом асимметричного ключа приведёт к компрометации всех зашифрованных им сообщений.

Рассматривая требуемую стойкость ключа Вы должны оценить
  a. ценность шифруемой информации,
  b. её актуальность во временн__о__й перспективе, иными словами, насколько быстро (или не быстро) она потеряет свою значимость и, следовательно, как долго должна храниться в тайне, и
  c. возможные угрозы безопасности.
Для защиты от негосударственных угроз Брюс Шнайер в "Прикладной криптографии" (1996 год) приводил такие рекомендации:
#|
*|Год|Длина ключа|*
||2005|1536 бит||
||2010|1536 бит||
||2015|2048 бит||
|#

Б.Шнайер:
<["Раз 512-битовые ключи небезопасны сегодня, столь же небезопасны они были и месяц тому назад. Пользователи RSA (равно, и DH, – прим. пер.) должны были перейти на 1024-битовые ключи несколько лет назад, и уже сегодня должны планировать переход на 2048. Грустно наблюдать, как люди не слушают криптографов, когда те называют что-то небезопасным, вместо этого ожидая, пока кто-то продемонстрирует, насколько оно небезопасно."]>
В более новых работах (//Practical Cryptography//) Шнайер и Фергюссон рекомендуют для долгосрочной безопасности 4096-битовые и даже более крупные ключи. Лучше перестраховаться и иметь определённый простор для манёвра в виде "лишних" битов ключа, чем оказаться застигнутым врасплох неким прорывом в теории чисел, в алгоритмах факторизации и дискретного логарифмирования (самые быстрые из которых уже субэкспоненциальны) или резким скачком вычислительных мощностей.

Наиболее дальновидным и рациональным будет использование 3072-битовых и б__о__льших асимметричных ключей для уравновешивания 128-битовых симметричных. Кроме того, "биты дёшевы"...

====={{a name="q5"}}Как отражается на криптографической стойкости многократное зашифрование сообщений?=====
В этом вопросе следует выделить два подвопроса, а именно, аспекты "параллельного" и "последовательного" зашифрования сообщения.

Первый подвопрос: как влияет на стойкость зашифрование сообщения для нескольких адресатов? Известно, что надёжность любой системы безопасности определяется самым слабым её элементом (как и крепость цепи – самым слабым звеном). Если вы зашифровываете идентичное сообщение несколькими ключами разной длины, общая стойкость шифртекста будет равна стойкости самого короткого ключа.

Скажем, вы отправляете письмо двум реципиентам, один из которых использует открытый ключ длиной 2048 битов, а другой – 512 бит. Криптоаналитику не будет нужды заниматься взломом 2-килобитного ключа, если он может за несколько суток произвести на распределённой системе факторизацию 512-битового ключа и расшифровать отправленное сообщение. То же самое касается защиты контейнера PGPdisk'а: если к нему имеют допуск несколько человек с открытыми ключами различной длины, надёжность хранящейся в контейнере информации будет обеспечена не более, чем надёжностью самого слабого из ключей. Аналогичный подход может позволить криптоаналитику читать зашифрованные сообщения, если какой-либо из симметричных шифров или алгоритмов с открытым ключом, используемых в PGP, когда-нибудь окажется взломан. Следите за новостями из области криптографии, прикладной математики и теории чисел.

Второй подвопрос: как влияет на стойкость многократное последовательное зашифрование одного сообщения несколькими ключами ("вложение" одного шифртекста в другой)? По-видимому, стойкость повышается с каждым дополнительным уровнем "вложенности", поскольку взломщику, чтобы добраться до открытого текста, потребуется последовательно вскрыть все шифртексты, или вычислить все ключи расшифрования, или подобрать все ключевые фразы.

У этой ситуации есть два важных нюанса. Во-первых: взломщик теоретически может провести криптоанализ верхних уровней шифртекста по известному открытому тексту, а именно, по служебным заголовкам PGP, таким как BEGIN PGP MESSAGE, Version и другим (разумеется, он не сможет таким образом вскрыть последний шифртекст, содержащий само зашифрованное сообщение). Во-вторых, многократное зашифрование PGP может образовывать группу. Это значит, что криптостойкость сообщения, последовательно зашифрованного //~ключом1// и //~ключом2//, может быть эквивалентна единичному зашифрованию некоторым //~ключом3//. Однако данный факт пока не был никем однозначно доказан или опровергнут. В то же время, сжатие PGP исходного сообщения перед зашифрованием и использование программой случайных симметричных ключей для каждой операции шифрования должно невилировать оба отмеченных нюанса. Кроме того, они не относятся к "вложенным" контейнерам PGPdisk'а вследствие самой их структуры.

Таким образом, многократно зашифрованное сообщение по самым скромным оценкам должно быть столь же стойко, сколь и самый нижний уровень шифртекста, но, наверняка, каждое последующее зашифрование повышает надёжность предыдущего при условии, что для каждого зашифрования используются различные ключи / ключевые фразы.

====={{a name="q6"}}Что вы можете сказать о PGP в свете предложенного в 2002 г. метода атаки на стандарт ~OpenPGP на основе подобранного шифртекста?=====
В 2002 году на конференции Information Security Conference криптологи Брюс Шнайер, Кахил Джеллад и Джонатан Катц предложили методику проведения криптоаналитической атаки на основе подобранного шифртекста и //дешифрующего оракула//. Уязвимость к атаке на основе подобранного шифртекста присуща множеству реализаций асимметричных криптосистем, используемых для защиты электронной почты. Уникальность нового метода состоит в том, что один из контрагентов непреднамеренно пособствует взломщику в дешифровании информации, а сам метод потенциально применим к реализациям стандарта ~OpenPGP: PGP и ~GnuPG.

С детальным описанием атаки можете ознакомиться [[/Библиотека/Статьи здесь]]. В общих чертах она выглядит следующим образом:

1. Взломщик, прослушивая канал связи, перехватывает зашифрованное письмо. Он определённым образом модифицирует ~OpenPGP-пакет, добавляя произвольный открытый текст внутрь тэга шифртекста, а затем отсылает модифицированное сообщение адресату.
  2. Адресат получает и расшифровывает письмо: сначала своим закрытым ключом расшифровывает симметричный сеансовый ключ, затем PGP (или иная реализация ~OpenPGP) этим симметричным ключом расшифровывает шифртекст послания. Однако, поскольку открытый текст был добавлен взломщиком внутрь тэга шифртекста, PGP криптографирует и этот открытый текст, **зашифровывая** его сеансовым ключом. В итоге адресат видит "мусор" в тексте полученного сообщения и возвращает всё сообщение отправителю, дабы выяснить, что это такое.
  3. Взломщик вновь перехватывает письмо. Теперь он располагает и своим открытым текстом, добавленным на этапе 1, и его симметрично зашифрованным вариантом. Произведя некоторые элементарные вычисления (простой XOR) над полученными данными он восстанавливает сеансовый ключ и дешифрует исходное сообщение, перехваченное на этапе 1.

Описанный сценарий исходит из ряда допущений, полное совпадение которых (обязательное по условию) весьма маловероятно. Так, подобная атака не будет иметь положительного результата в любом из следующих случаев:

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

Более того, шансы на удачное проведение описанной атаки на пользователей ~PGP/GnuPG становятся ещё меньше по ряду специфических причин:

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

Всё же атака Шнайера-Джеллада-Катца представляет потенциальную угрозу. PGP сжимает сообщения лишь в том случае, если они не сжаты изначально; если зашифровать готовый zip-архив, PGP не вычислит собственную контрольную сумму данных и не добавит её в пакет. В иной реализации ~OpenPGP сжатие может вовсе не применяться (что допускается стандартом ~OpenPGP), либо пользователь может его отключить. Катц написал [[http://www.cs.umd.edu/%7Ejkatz/pgpAttack.tar.gz небольшую программу]] на java, реализующую такую атаку против PGP 2.6.x и ~GnuPG 1.0.6; поскольку стандарт ~OpenPGP является интероперативным, она в той или иной мере применима и к другим версиям криптосистем.

В соответствии с рекомендациями криптологов, в 2003 году стандарт ~OpenPGP был отредактирован, дабы исключить данную уязвимость. Начиная с PGP 8.0.2, где впервые реализована новая редакция стандарта, каждое шифруемое сообщение обрабатывается хэш-функцией SHA-1, полученная контрольная сумма – так называемый //код выявления изменений//, MDC, – добавляется в конец открытого текста, и только затем всё сообщение зашифровывается сеансовым ключом. При расшифровании PGP повторно вычисляет хэш-значение открытого текста и сравнивает его с зашифрованным; если они не совпадают, немедленно выдаёт соответствующее предупреждение. (Более детально весь механизм описан в параграфах 5.13 и 5.14 [[/библиотека/спецификации спецификаций OpenPGP]]) Таким образом, в настоящее время описанная уязвимость в PGP устранена.

====={{a name="q7"}}Могут ли спецслужбы и разведывательные агентства получить открытый текст моих зашифрованных данных?=====
Разумеется. Но только при одном условии: если ваша информация представляет для них значительный интерес. Не думайте, что кто-нибудь станет заниматься прямым криптоанализом шифртекста – в современных условиях это неоправданно дорогостоящая атака с негарантированным результатом. Гораздо проще обойти непроницаемую криптографическую защиту PGP и определённым образом получить ключевую фразу и закрытый ключ пользователя: перехватив ли их с помощью трояна, скрытно установленного в помещении миниатюрного видеозаписывающего устройства, путём удалённой регистрации излучаемых компьютером электромагнитных волн или же при помощи шантажа, социальной инженерии либо прямого физического воздействия на самого пользователя. Перечисленное не исчерпывает список возможных векторов и методов атак, но эти – экономически наиболее эффективны.

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

====={{a name="q8"}}Защищён ли протокол ~OpenPGP от атак по методу "тайной пересылки"?=====
Атака по методу тайной пересылки состоит в том, что легальный получатель зашифрованного и подписанного сообщения может, расшифровав сообщение, зашифровать его ключом третьего лица и переслать ему. В итоге этот второй получатель будет уверен, что письмо предназначено именно ему и действительно прислано оригинальным отправителем (поскольку несёт его цифровую подпись). В некоторых случаях это может иметь для оригинального отправителя негативные последствия.

~OpenPGP, как и большинство практических реализаций криптосистем с открытым ключом (~S/MIME, PEM и др.) не имеет защиты от этих атак. Проще всего защититься от подобной атаки, персонализируя отправляемые сообщения, например, включая в их текст полное имя, email-адрес или иную точную идентификацию получателя. Сообщение должно быть подписано и зашифровано. В этом случае первый получатель не сумеет переслать письмо, не нарушив его цифровую подпись.

====={{a name="q9"}}Насколько серьёзна атака на протокол ~OpenPGP, предложенная в феврале 2005 г. Сержем Мистером и Робертом Цуккерато?=====
Данная атака носит ограниченно-прикладной характер, и неприменима ни к одной существующей реализации стандарта ~OpenPGP. Хотя она представляет исключительный академический интерес, всё же даже менее практична, чем атака [[#q6 Шнайера-Джеллада-Катца]]. Пользователям PGP и ~GnuPG опасаться нечего.

Мистер и Цуккерато использовали методы адаптивно подобранного шифртекста и дешифрующего оракула. В случае успеха оппонент сможет восстанавливать первые два байта из любого блока шифртекста при 2^^15^^ (в среднем) запросов к оракулу на каждый (два часа в лабораторных условиях на стандартном Pentium M 1.8 ГГц). Это несравнимо меньше, чем при успешной атаке Шнайера-Джеллада-Катца, где одного подобранного шифртекста, переданного оракулу, достаточно (при определённых условиях), чтобы дешифровать весь открытый текст единичного сообщения.

Итак, суть в следующем. Стандарт ~OpenPGP предписывает, чтобы каждый симметрично зашифрованный пакет данных предварялся 64- или 128-битовым вектором инициализации. Когда открытый текст шифруется, в самом начале пакета непосредственно перед "полезной нагрузкой" вставляется так называемый //QC-тэг// (//quick check//, быстрая проверка), состоящий из двух последних байт ВИ. Он служит тому, чтобы при расшифровании можно было сразу узнать, используется ли правильный симметричный ключ или неверный и, в случае чего, не прогонять расшифрование по всему сообщению: если расшифрованный QC-тэг совпадает с последними байтами ВИ, программа продолжает расшифрование всего сообщения, иначе выдаёт ошибку. Это особенно полезно, если зашифрованные данные составляют несколько мегабайт или гигабайт – программе не нужно расшифровывать пакет целиком, чтобы в итоге определить, что операция проводится не тем ключом, и сообщить об этом пользователю. Вот за эту-то функцию и зацепились криптологи.

В предложенной ими схеме (см. [[file:/Библиотека/Статьи/openpgporaclecfb.pdf "An Attack on CFB Mode Encryption As Used By OpenPGP"]]) взломщику содействует дешифрующий оракул – лицо или программа, обладающая верным ключом расшифрования и которая может сообщить взломщику, прошло ли расшифрование нормально или с ошибкой.

Взломщик имеет в своём распоряжении сообщение, симметрично зашифрованное парольной фразой (это важно: сообщение, зашифрованное открытым ключом, не поддаётся такой атаке). Он вносит определённые изменения в пакет шифртекста и отправляет модифицированное сообщение оракулу, чтобы узнать, прошла ли "быстрая проверка". Если оракул возращает взломщику //"Ошибка"//, взломщик снова вносит корректировку и повторяет процесс, пока, наконец, оракул не сообщит, что сообщение расшифровано, т.е., технически, подогнанные взломщиком байты QC-тэга совпали с последними байтами ВИ (оракул в результате расшифрования получит мусор, но это не важно). Теперь взломщик знает последние два байта ВИ. Он "сдвигает" ВИ на эти два байта и повторяет весь процесс, пока не получит полный вектор инициализации.

(В действительности, оракулу не обязательно возвращать //"Правильно"// или //"Ошибка"//. Даже если при расшифровании мусора он всё равно сообщит взломщику //"Ошибка"//, последний сможет провести тайминг-атаку, замерив время, затраченное на обработку сообщения.)

Это подготовительный этап, на который у исследователей уходило, в среднем, 4 часа. Исходя из полученных данных и при помощи специальных вычислений и дополнительных запросов к оракулу, можно за каждые 2 часа (в среднем) дешифровать по два первых байта (16 бит) из каждого блока шифртекста (64 или 128 бит).

Как можно видеть, такая атака применима только против автоматизированных систем, выдающих избыточную информацию при взаимодействии с пользователем. Живой человек не станет отвечать //"Правильно"// или //"Ошибка"// и пытаться расшифровать около 30 тысяч присланных "битых" сообщений. Более того, на сегодня нет ни одной реализации ~OpenPGP, подходящей под необходимые допущения.

В то же время, в крупнейшие реализации – PGP и ~GnuPG – внесены соответствующие корректировки, запрещающие обработку QC-тэга в симметрично зашифрованных сообщениях. Впоследствии стандарт ~OpenPGP будет улучшен, а QC-тэг заменён более эффективной и безопасной схемой проверки ключа.

====={{a name="q10"}}Я хочу использовать криптографические средства для защиты своих данных (программ, текстов, авторской музыки) от несанкционированного __копирования__. Как этого добиться?=====
Никак, потому что это запрещено законами физики. Свободное распространение -- это естественное свойство информации, изменить которое при всем желании нельзя. Защита от несанкционированного копирования контента может создать только временные затруднения в копировании, ведь техническая реализация, даже идеальная (каких ещё не бывало), предполагает (это, опять же, непреодолимое требование), что пользователь контента будет располагать и самим контентом, и алгоритмом защиты, и ключом, которым эти данные защищены. Если человек обладает информацией, то он может ее распространять, примите это за аксиому.

====={{a name="q11"}}Разве не очевидно, что любой секрет (ключ, пароль) можно "вынуть" из человека с помощью утюга и паяльника?=====
Криптография решает конкретную проблему: защиту информации путём превращения больших секретов (открытого текста) в малые (ключи). Как человек будет обеспечивать сохранность своих малых секретов -- вопрос совершенно самостоятельный и в криптографии и на этом сайте обычно считающийся офф-топиком. Однако, решения также существуют: можно нанять охрану, обратиться к детективам, чтобы выяснить мотивы и методы своих врагов и т.д. Если информация стоит того, и ((/библиотека/словарь/бандитскийкриптоанализ "бандитский криптоанализ")) противника не смущает, об этих вещах следует позаботиться заранее.

Ваше имя:
	Запомнить псевдоним (сохранить в cookie)
	OpenPGP-подписанный текст в кодировке Помощь
	Сохранить параметры OpenPGP в cookie

Для корректной работы разрешите в своем браузере показ изображений.

Пожалуйста, напишите, кого/что вы видите
на изображенной слева картинке. Если
там несколько персонажей/предметов,
перечислите их в именительном падеже
через пробел (одинаковых приводите во
множественном числе).

(осталось попыток на решение теста: 3)

Поддержка BBCode включена