openPGP в России / Часто задаваемые вопросы / Шифрование, подпись, уничтожение данных

==Шифрование, подпись, уничтожение данных==

====={{a name="q1"}}//"Status: Good / Bad / Unknown / Invalid"// при сверке подписи – что это?=====
При сличении цифровой подписи с письма или файла, PGP уведомляет вас о её состоянии одним из четырёх сообщений:

#||
||//Good//|Информация была получена вами ровно в том виде, в каком была подписана и отправлена автором.||
||//Bad//|Подписанная информация была каким-то образом изменена (искажена). Причиной тому могло послужить не только злонамеренное вмешательство, но и более тривиальные вещи, например, плохое качество связи, повлекшее искажение информации в процессе передачи, случайное редактирование сообщения автором уже после подписания, изменение, внесённое почтовой программой отправителя или вашей. В любом случае, к подобного рода сообщениям следует относиться с большой осторожностью; желательно также в кратчайшие сроки выяснить причину происшедшего.||
||//Unknown//|Это говорит о том, что на Вашей связке ключей отсутствует тот, которым информация была подписана, и, следовательно, программа не может сверить подпись. В таких случаях PGP пытается самостоятельно связаться с сервером-депозитарием, чтобы найти соответствующий открытый ключ (если не пытается, откройте //Options > вкладка Servers > раздел Synchronize with server upon > поставьте галку на Verification//).||
||//Invalid//|Так PGP уведомит вас о том, что ключ автора сообщения есть на вашей связке, но не признан подлинным. За дополнительными сведениями относительно модели доверия PGP обращайтесь к материалам [[/Библиотека/Основы/ВведениеВКрипто "Введение в криптографию"]] и [[/Библиотека/Основы/СетьДоверия "Web of Trust"]], а также к [[Ключи#q5 этому вопросу]] FAQ.||
||#

====={{a name="q2"}}Я зашифровал и отправил сообщение, но мой корреспондент ответил, что не может его расшифровать.=====
Скорее всего причина в том, что вы забыли указать открытый ключ получателя, зашифровав сообщение только своим. Это типичная ошибка. Чтобы сообщение было расшифровано получателем, оно должно быть обязательно зашифровано __его открытым ключом__ (также зашифруйте и своим, чтобы иметь возможность прочитать отправленное сообщение в будущем).

====={{a name="q3"}}Я хочу отправить зашифрованное сообщение сразу нескольким адресатам. Нужно ли мне зашифровывать его для каждого по отдельности?=====
Не обязательно, можно зашифровать сразу для всех, указав ключи всех получателей в диалоговом окне //Key Selection Dialog//, а затем отправить полученный шифртекст каждому из адресатов.

====={{a name="q4"}}В окне выбора ключей получателей (Key Selection Dialog) почему-то гораздо больше ключей, чем есть на моей связке.=====
В окне //Key Selection Dialog// перечислены не отдельные открытые ключи, находящиеся на вашей связке, а все сертификаты (имена и адреса, привязанные к конкретному ключу) с этих ключей. Это сделано для более лёгкой идентификации получателя: можете выбрать любую из записей сертификата с его именем и контактным адресом -- сообщение будет зашифровано соответствующим ключом (или ключами).

====={{a name="q5"}}Зашифрование сообщения для нескольких корреспондентов не допускает анонимной передачи: при расшифровании сообщения каждый из получателей может видеть, какими ключами оно было зашифровано. Есть альтернативы?=====
Совершенно верно, каждый получатель сообщения знает, кому ещё оно было отправлено (точнее, чьими открытыми ключами его зашифровал отправитель), что не позволяет использовать такой метод в анонимных списках рассылки и тому подобных случаях.

__Альтернатива первая__: если получателей немного, можно зашифровать сообщение для каждого индивидуально. Разумеется, это малопродуктивно и неприменимо в больших масштабах.

__Альтернатива вторая__: если получателей много, и рассылка осуществляется регулярно, можно придумать некий пароль, отправить его всем получателям, зашифровав индивидуально их ключами (см. //"альтернатива первая"//), и впоследствии использовать этот пароль для шифрования сообщений симметричным алгоритмом (//conventional encryption//). В этом случае получатели не смогут определить, кому ещё отправлялось сообщение. Минусы такой методики очевидны: при исключении кого-либо из списка рассылки Вам придётся менять этот согласованный пароль, поскольку иначе исключённый по-прежнему сможет перехватывать и читать конфиденциальную рассылку; кроме того, пароль может быть с лёгкостью скомпрометирован (возможно, у кого-то из получателей окажется слишком длинный язык: согласитесь, своим закрытым ключом он бы рисковать не стал), и тогда рассылку сможет читать кто угодно.

__Альтернатива третья__: прибегнуть к параметрам ~GnuPG, позволяющим скрыть список получателей сообщения: ##--throw-keyids##, ##--hidden-recipient [id]## или ##--hidden-encrypt-to [id]##. Детали их применения можно найти в документации новых (1.4.x, 1.3.x) версий ~GnuPG.

====={{a name="q6"}}Использую PGP в ~Windows2000/NT. При подписании какого-либо текста русские буквы в нём превращается в непонятную абракадабру вроде Заофс.=====
NT-совместимые операционные системы имеют особенность сохранять параметры раскладки клавиатуры и кодировки индивидуально для каждого приложения. Таким образом, в некоторых ситуациях PGP берёт текст в буфер обмена, ОС перекодирует кириллические символы из второй половины ASCII-таблицы в соответствие западно-европейским буквенным символам, которые и подписывает PGP, выдавая в итоге странный результат.

Проблему можно обойти так: после ввода ключевой фразы для подписания текста не нажимайте //OK//, переключите раскладку клавиатуры в русский режим (на индикаторе раскладки в системном трее в правом нижнем углу экрана должно значиться "Ru") и только после этого нажимайте //OK//.

====={{a name="q7"}}При расшифровании файла с русскими буквами в имени, они превращаются в прочерк _.=====
Это общая проблема всех версий PGP до 8.0, не несущая угрозы безопасности. Просто не используйте нелатинских буквенных символов в именах шифруемых файлов.

====={{a name="q8"}}Не могу удалить файл "мимо корзины" (Shift+Delete) – файл исчезает, но после обновления содержимого каталога снова появляется.=====
Вполне возможно, что это связано с установленной у вас программой PGP: похожим образом [[Технические#q4 проявляется баг]] в функции PGP //Wipe on delete//. По некоторым свидетельствам он возникает в Windows NT-совместимых системах (NT, 2000, XP) с установленными продуктами Symantec, например, Norton ~AntiVirus или Norton Internet Security, но может быть и не связан с последними. Решение проблемы с "воскресающими файлами" -- выключить в настройках PGP опцию //Automatically wipe on delete// (вкладка //General//). Если это не приводит к позитивному результату, причина вашей ситуации, вероятно, кроется в чём-то другом.

====={{a name="q9"}}При сверке цифровой подписи программа показывает строку //Verified// с указанием текущего времени. Зачем это нужно?=====
Чтобы вас было труднее одурачить и заставить поверить, что письмо злоумышленника на самом деле было подписано тем, кому вы доверяете. Эта мошенническая атака не имеет ничего общего с криптоанализом, но в некоторых обстоятельствах может оказаться весьма действенной и эффективной.

Выполняется она так. Злоумышленник составляет письмо, имитируя его первыми строчками блок заголовков сверенной подписи, т.е.
  ##~*** Status: Good Signature##
  ##~*** Signer: Ваш друг Вася (~0xDEADBEEF)##
и т.д. В заголовке ##~*** PGP SIGNATURE VERIFICATION ~***## он заменяет одну из английских букв русской со схожим начертанием (например, английскую "пи" на русскую "эр"), чтобы ваша программа не заметила подвоха. Ниже он пишет текст своего сообщения и замыкает его финальным хидером ##~*** END PGP ~DECRYPTED/VERIFIED MESSAGE ~***##. Остаётся зашифровать (только зашифровать) всё сообщение вашим открытым ключом и, по желанию, ключом вашего доверенного корреспондента, от имени которого злоумышленник обращается к вам.

Теперь, расшифровав полученное сообщение, вы увидите текст, выглядящий так, словно действительно был подписан вашим постоянным корреспондентом. А раз текст криптографически подписан, подумаете вы, то его содержанию можно доверять. Однако не спешите со скорополительными выводами и обратите внимание на строку ##~*** Verified:## (дата/время сличения подписи). Сравните дату, указанную в ней, с текущим показанием системных часов. Маловероятно, что злоумышленник мог предугадать с точностью до секунд, когда именно вы откроете послание, а значит указанная дата будет иметь серьёзное расхождение с действительностью.

Вывод: будьте бдительны, обращайте внимание на строку ##~*** Verified:## при расшифровании сообщений и ни в коем случае не доверяйте тем, в которых этот показатель не совпадает с временем, указанным на ваших часах!

====={{a name="q10"}}Забыл пароль к своему ключу. Как мне теперь расшифровать свои файлы?=====
Без правильной парольной фразы это невозможно. Если бы PGP имел лазейки или обходные пути, им бы не пользовались десятки и сотни тысяч людей. Единственный совет -- постарайтесь вспомнить пароль или хотя бы его часть. Если вы помните большую его часть, воспользуйтесь подборщиком паролей [[/Софт/PGP/Утилиты pgppass]]. Так или иначе, это крайнаяя мера, и если вы использовали сложную комплексную ключевую фразу, процесс перебора даже по известным элементам может занять огромное количество времени.

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

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

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

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

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

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