| Каталог документации / Раздел "Безопасность" | (Архив | Для печати) |
| ||
|
Версия: 1.6.3
Редакция от: 30 Июля 2003
Руководитель проекта: David D. Scribner, <faq 'at' gnupg.org>
Перевод на русский: Maxim Britov <[email protected]>, GnuPG KeyID 0x6F3DB1FB
CODEPAGE: UTF-8
В данном документе (далее - "FAQ") Вы найдете ответы на наиболее часто задаваемые вопросы по GnuPG. Последняя версия FAQ (английская) в формате HTML доступна здесь.
Содержание создано автоматически, поэтому может содержать ошибки и может случиться, что некоторые из отвеченных ниже вопросов могут в него не попасть. Принимаются любые предложения по усовершенствованию структуры настоящего документа.
Все дополнения и исправления отправляйте на англ. языке руководителю проекта. Будет правильнее, если Вы предложите и ответ на Ваш новый вопрос или укажете и вопрос, и ответ по которым Вы имеете свои предложения. Ваша помощь будет оценена по достоинству.
Не следует присылать сообщения типа "Это следует поместить в FAQ - Каков ответ?". Если вопрос не задавался ранее, видимо он не относится к часто задаваемым. В этом случае Вам следует поискать ответ в архиве соответствующей почтовой рассылки.
GnuPG расшифровывается как GNU Privacy Guard и является GNU инструментом для секретных коммуникаций и хранения данных. GnuPG может использоваться для шифрования данных и создания цифровых подписей. GnuPG представляет собой легкое, но мощное средство управления ключами и совместимо с предложенным OpenPGP Internet стандартом, как описано в RFC 2440. Также, по возможности, обеспечивается совместимость с PGP от NAI, Inc.
В основном, да. GnuPG и новейшие версии PGP следуют стандарту OpenPGP. Но существуют некоторые проблемы при взаимодействии. Подробности см. в вопросе 5.1.
Да! GnuPG является частью инструментов и приложений GNU созданных и распространяемых в соответствии с Free Software Foundation (FSF) General Public License (GPL). Поэтому GnuPG свободно для копирования, использования, изменения и распространения в соответствии с данной лицензией. Прочитайте, пожалуйста, файл озаглавленный COPYING, который прилагается к данной программе для получения более полной информации.
Поскольку GnuPG разрабатывается для нескольких оперционных систем (часто параллельно), то соглашения используемые в данном FAQ отражают окружение оболочки UNIX. Для пользователей Win32, ссылки на подсказку командной строки ("$") следует рассматривать, как приглашение (">"), имена каталогов разделенные прямым слешем ("/") следует разделять обратным слешем ("\"), и тильду ("~") рассматривать, как путь к домашнему каталогу пользователя (см. ответ на 4.18 для примера).
Некоторые командные строки в настоящем FAQ слишком длинны для правильного отображения некоторыми браузерами в Web версии данного документа и поэтому некоторые строки могут быть разбиты на две и более. Такие команды следует ввести целиком - одной строкой, иначе команда будет ошибочна и как минимум, не даст требуемого результата.
Помните, что данный FAQ содержит информацию, которая может оказаться не актуальной для Вашей текущей версии программы, т.к. постоянно производятся усовершенствование программы и исправления найденных ошибок (см. файл NEWS поставляемый вместе с исходными текстами). Один из пунктов которого сообщает, что в GnuPG начиная с версии 1.1.92 файл персональных параметров программы переименован из "options" в "gpg.conf". Информация в FAQ, ссылающаяся на файл параметров "options" полностью применима к новому файлу "gpg.conf" в большинстве случаев. Подробнее см. в вопросе 5.8.
Онлайновые источники:
Дополнительно можно поискать на MARC, например:
gnupg-users: <http://marc.theaimsgroup.com/?l=gnupg-users&r=1&w=2>
gnupg-devel: <http://marc.theaimsgroup.com/?l=gnupg-devel&r=1&w=2>
ПОЖАЛУЙСТА: Перед отправкой вопроса с список рассылки, прочтите данный FAQ и доступную докуменцию. Следует просмотреть также архив рассылки, т.к. вплне возможно, что Ваш вопрос уже обсуждался ранее. Это поможет людям сконцентрировать внимание на решении новых, еще не решенных вопросов.
./doc
в котором Вы можете найти некоторую дополнительную информацию (интересную в основном Хакерам, а не обычным пользователям).
Вы можете скачать GNU Privacy Guard с главного FTP сервера проекта <ftp://ftp.gnupg.org/gcrypt/> или с одного из зеркал:
<http://www.gnupg.org/download/mirrors.html>
Текущая стабильная версия GnuPG 1.2.2. Обновите Вашу программу до указанной версии, т.к. она включает дополнительные функции и исправления найденных ошибок, которые могли быть найдены в предыдущих версиях.
GnuPg должен работать на большинстве Unix, а также Windows (включая Windows NT/2000/XP) и Macintosh OS/X. Текущий список поддерживаемых систем можно посмотреть здесь:
<http://www.gnupg.org/download/supported_systems.html>
"Хорошие" случайные числа имеют решающее значение для секретного шифрования. Различные операционные системы предоставляют различные механизмы поставки более или менее качественных случайных числа. Linux и *BSD поставляют случайные числа созданные ядром посредством /dev/random - этот вариант предпочтителен для данных систем. Solaris с установленным SUNWski пакетом также предоставляет /dev/random. В данном случае следует использовать параметр конфигурирования:
--enable-static-rnd=linux
Также существует устройство ядра для поставки случайных чисел разработанное Andi Maier <http://www.cosy.sbg.ac.at/~andi/SUNrand/>, но это всё еще бета версия. Используйте ее на свой страх и риск!
На других системах, хорошим выбором будет Entropy Gathering Daemon (EGD). Это perl-демон, который наблюдает за системной активностью и хеширует ее в случайные числа. См. страницу загрузки <http://www.gnupg.org/download/> для получения EGD. Используйте параметр конфигурирования:
--enable-static-rnd=egd
Если указанные выше параметры не работают, можете использовать генератор случайных чисел "unix". Но он очень медленен и его следует избегать. Качество поставляемых случайных чисел не очень хорошее, поэтому им не следует пользоваться для важных данных.
RSA включен в поставку GnuPG начиная с версии 1.0.3.
Официальная поставка GnuPG не включает поддержку IDEA по причине патентных ограничений. Патент на IDEA истечет в 2007, поэтому не ждите официальной поддержки до этого момента.
Однако существует неофициальный модуль поддержки IDEA для GnuPG. Он доступен на <ftp://ftp.gnupg.dk/pub/contrib-dk/>. Ищите:
idea.c.gz (модуль на C ) idea.c.gz.sig (файл подписи)
ideadll.zip (модуль на C и win32 dll) ideadll.zip.sig (файл подписи)
Директивы компиляции в заголовках файлов. Вам будет необходимо добавить следующую строку в Ваш файл персональных настроек ~/.gnupg/gpg.conf:
load-extension idea
1024 бита для DSA подписей; даже и для простых ElGamal подписей. Этого достаточно, т.к. при большем рамере ключа слабейшим звеном оказывается уже размер хеша. Вы можете добавить ключи шифрования большего размера, но Вам следует просмотреть отпечаток этого ключа командой:
$ gpg --fingerprint <User ID>
Вам следует придерживаться стандартных алгоритмов (т.е. DSA для подписей и ElGamal для шифрования). Ключ ElGamal для подписи невыгоден по следующим причинам: большой размер подписей; сложно создать пригодный для подписи ключ, который сможет противостоять настоящим атакам, Вы не получите чего-то особенно секретного или надежного в сравнении с DSA, плюс существуют также проблемы совместимости с некоторыми версиями PGP. Он был предложен потому, что в то в свое время имелись проблемы с патентами на DSA.
Основная проблема в том, что необходимо собрать много случайных чисел и для этого мы (в Linux - с устройства /dev/random) должны собирать случайные числа. На самом деле трудно заполнить внутренний буфер Linux энтропией; я говорил с Ted Ts'o и он сказал, что лучший способ заполнить буфер это понажимать клавиши на Вашей клавиатуре. Хорошая секретность имеет свою цену. Я нажимаю на клавиши Shift, Ctrl, Alt and CapsLock потому, что эти клавиши не выводят что-либо на экран. И таким путем Вы получаете ключи быстрее (это то, что делает PGP2).
Также проблема может быть в том, что другая программа забирает данные из Вашего генератора случайных чисел (например из /dev/random).
Никогда не делайте этого! Вы никогда не должны создавать ключи и даже пользоваться GnuPG на удаленной системе потому, что Вы обычно не имеете физического контроля за Вашей таблицей секретных ключей (которая зачастую может быть неустойчива к атакам на подбор стандартных паролей по словарю). Я настойчиво рекомендую всем создавать ключи только на локальном компьютере (неподключенный лаптоп возможно наилучший выбор). А если Вы вынуждены делать это на Вашем подключенном к сети компьютере (я знаю, все мы так делаем) будьте уверены, что используете сильный пароль для всех Ваших аккаунтов и для секретного ключа, и что Вы можете доверять Вашему системному администратору.
Когда я проверял GnuPG на удаленной машине через ssh (это была не альфа);-) я имел некоторые проблемы. Создание ключа занимамо *очень* долгое время, так что я использовал специальный параметр --quick-random для создания несекретных ключей, которые пригодны разве что для некоторых экспериментов.
Если Вы выполните 'gpg --help', то Вы получите два разных списка. Первый - список команд, а второй - параметров. Всякий раз когда Вы запускаете GPG, Вы должны использовать хотя бы одну команду (с одним исключением, см. ниже). Вы можете использовать один или более параметров. Команде следует, в точности по описанию, находиться в конце списка аргуметов, после всех параметров. Если команда задает имя файла (в основном все они это делают), имя файла должно быть в самом конце. Базовый формат вызова gpg:
$ gpg [--option что-либо] [--option2] [--option3 что-либо] --command файл
Некоторым параметрам требуются аргументы. Например параметр --output (который можно сократить до -o) это параметр которому требуется имя файла. Аргументы параметра должны следовать непосредственно после требующего их параметра, иначе gpg не сможет узнать какой аргумент, какому параметру принадлежит. Как параметр --output так и имя файла должны предшествовать команде. Параметр --recipient (-r) задает имя или KeyID того, кому шифруется сообщение и которые должны находиться справа от параметра -r. Команда --encrypt (-e) должна находится после всех параметров и следовать за файлом, который Вы хотите шифровать. Поэтому в данном примере командная строка должна иметь следующий вид:
$ gpg -r Алиса -o секрет.txt -e тест.txt
Если Вы используете полные названия параметров, читать станет легче:
$ gpg --recipient Алиса --output секрет.txt --encrypt тест.txt
Если Вы шифруете файл с расширением ".txt" и Вы можете захотите получить результат в текстовом виде ASCII-формата (не двоичном), Вам следует воспользоваться параметром --armor (-a), который не имеет аргументов:
$ gpg --armor --recipient Алиса --output секрет.txt --encrypt тест.txt
Если предположить квадратные скобки вокруг параметров, это будет выглядеть так:
$ gpg [--armor] [--recipient Алиса] [--output секрет.txt] --encrypt тест.txt
Параметры могут следовать в произвольном порядке:
$ gpg --output секрет.txt --recipient Алиса --armor --encrypt тест.txt
Если имя Вашего файла начинается с дефиса (например файл "-a.txt"), GnuPG примет это за параметр и может сообщить об ошибке. В таких случаях следует использовать "./-a.txt" или остановть обработку команд и параметров двойным дефисом: "-- -a.txt".
Исключение составляет только одна команда: одновременное подписывание и шифрование. Для этого Вы следует скомбинировать обе команды, как показано ниже:
$ gpg [--параметры] --sign --encrypt тест.txt
Поскольку Вы можете выбрать User ID только из списка открытых ключей, то прямого способа сделать это нет. Однако сделать это на самом деле совсем не трудно. Создайте новый User ID с полностью идентичным именем и увидите, что получилось два идентичных User ID в связке секретных ключей. Теперь выберите данный User ID и удалите его. Оба User ID будут удалены из связки секретных ключей.
Поиск ключа, для выполнения операций с ним, всегда производится по связке открытых ключей, поэтому невозможно удалить секретный ключ не имея открытого ключа. Обычно не должно возникать ситуаций, когда открытый ключ потерян, а секретный ключ всё еще присутствует. Но такое случается, поэтому в GnuPG имеется способ сделать это: просто используйте длинный KeyID для указания удаляемого ключа, который можно получить применением параметра --with-colons (см. 5 поле в строке начинающейся с "sec").
Если потерян открытый ключ и нужно взамен его создать новый для продолжения использования секретного ключа, можно воспользоваться утилитой gpgsplit так, как описано в вопросе 4.21.
Ответ приведу с английским текстом, т.к. вопрос очень важен.
В GnuPG термин "доверие владельцу" используется вместо "доверие", чтобы показать, что это есть величина, которая относится к ключу и выражает степень Вашего доверия к владелецу данного ключа и к тому, как он относится к подписыванию других ключей. "Достоверность" (вычисленое доверие) есть величина, показывающая насколько высоким GnuPG считает доверие к ключу (т.е. насколько можно быть уверенным в том, что ключ действительно принадлежит тому, кто указан, как владелец данного ключа). Для большей информации о степенях доверия см. главу "Сеть доверия" в The GNU Privacy Handbook (существует в русском переводе).
With GnuPG, the term "ownertrust" is used instead of "trust" to help clarify that this is the value you have assigned to a key to express how much you trust the owner of this key to correctly sign (and thereby introduce) other keys. The "validity", or calculated trust, is a value which indicates how much GnuPG considers a key as being valid (that it really belongs to the one who claims to be the owner of the key). For more information on trust values see the chapter "The Web of Trust" in The GNU Privacy Handbook.
Воспользуйтесь "gpg --clearsign --not-dash-escaped ...". Есть проблема с --clearsign в том, что все строки начинающиеся с дефиса выделяются как "- "; но поскольку diff создает множество строк начинающихся с дефиса, то если они будут выделены таким образом, будет не очень хорошо для Вашего патча ;-). Для применения патча без удаления прозрачной подписи, можно использовать специальный параметр --not-dash-escaped для отключения выделния таких последовательностей. Не следует отсылать такие патчи по email потому, что пробелы и завершители строк также являются частью подписи, а почтовик может не сохранить их. Если Вы хотите послать файл почтой, то можно подписать его используя Ваш MUA (Mail User Agent, т.е Почтовый агент).
Используйте "--encrypt-to Ваш_KeyID". Можно использовать больше, чем одну копию данного параметра. Временно отменить действие данного параметра можно использованием параметра "--no-encrypt-to".
Используйте " --no-version --comment '' ". Учтите, что стандарт требует обязательного наличия пустой строки.
Вы увидите данное сообщение, когда необходимо преобразование введенных данных в UTF-8. Набор символов Вашей системы отличен от UTF-8 и GnuPG вынуждено преобразовать введенную информацию из используемого Вами набора символов в соответствующий набор символов UTF-8. По умолчанию используется стандартный набор символов "iso-8859-1". Вы можете указать используемый системой набор символов используя параметр " --charset ". Важно, чтобы заданная таблица символов соответствовала используемой в Вашей системе. В противном случае Вы должны пользоваться только символами имеющими 7-битное представление, т.к. все 8-битные символы будут преобразованы в UTF-8 и Вы можете столкнуться с серьезными проблемами, если неверно указали используемую таблицу символов.
Для русскоязычной аудитории: не рекомендуется использовать русский язык в User ID и коментариях. На момент перевода GnuPG поддерживает только UTF-8 и KOI8-R, которые могут использоваться на Unix системах, но не используются в Windows. В Windows категорически запрещается использовать русский язык в именах и комментариях User ID! Хотя некоторые программы-оболочки могут понимать (а может и нет) большее число кодировок.
$ gpg --batch --decrypt --list-only --status-fd 1 2>/dev/null | awk '/^\[GNUPG:\] ENC_TO / { print $3 }'
Версии GnuPG ниже 1.0.1 содержали ошибку, которая проявлялась только при использовании шифров 3DES и Twofish для симметричного шифрования (они никогда не использовались, как шифры по умолчанию). Ошибка исправлена, но для расшифровки таких файлов необходимо запустить gpg с параметром " --emulate-3des-s2k-bug "; расшифровать файл и зашифровать снова без данного параметра.
Замечение: Данный параметр удален в GnuPG версии 1.1.0 и более новых, поэтому Вам придется воспользоваться версией между 1.0.1 и 1.0.7 для расшифровки таких файлов.
Следует воспользоваться параметром --batch и не использовать паролей, т.к. обычно нет возможности хранить их безопаснее, чем в связке секретных ключей. Рекомендуем следующий способ создания ключей для автоматизации работы:
На безопасном компьютере:
На нужном компьютере:
Использование GnuPG для шифрования почтовой корреспонденции это одно из наиболее популярных его применений. Некоторые почтовые программы или почтовые агенты (MUA) умеют работать с GnuPG. На данный момент существует два способа шифрования с применением GnuPG: "старый метод" с применением ASCII-кодирования (т.е. прозрачные подписи и шифрование) и в соответствиии с RFC 2015 (ранее именуемое PGP/MIME, сейчас OpenPGP). Последнее полностью поддерживает MIME. Некоторые MUA поддерживают только один из этих методов. Поддержка может быть как встроена в MUA, так и реализоваться в виде подключаемых подулей "плагинов", а также может выполняться внешним, дополнительным программным обеспечением.
Нижепреведённый список неполон:
MUA OpenPGP ASCII Как? (N,P,T) ------------------------------------------------------------- Calypso В Д П (Unixmail) Elm В Д Д (mailpgp,morepgp) Elm ME+ В Д С Emacs/Gnus Д Д Д (Mailcrypt,gpg.el) Emacs/Mew Д Д С Emacs/VM В Д Д (Mailcrypt) Evolution Д Д С Exmh Д Д С GNUMail.app Д Д П (PGPBundle) GPGMail Д Д В KMail (<=1.4.x) В Д В KMail (1.5.x) Д(П) Д(В) П/В Mozilla Д Д П (Enigmail) Mulberry Д Д П Mutt Д Д С Sylpheed Д Д С Sylpheed-claws Д Д С TkRat Д Д С XEmacs/Gnus Д Д Д (Mailcrypt) XEmacs/Mew Д Д С XEmacs/VM В Д Д (Mailcrypt) XFmail Д Д С С-Сам, встроена поддержка , П-плагин , Д-Дополнительной программой
Ниже дан список несвободных MUA. Проект GNU не рекомендует применение этих программ, но они представлены для полноты информации.
MUA OpenPGP ASCII How? (N,P,T) ------------------------------------------------------------- Apple Mail Д Д П (GPGMail) Becky2 Д Д П (BkGnuPG) Eudora Д Д П (EuroraGPG) Eudora Pro Д Д П (EudoraGPG) Lotus Notes Н Д П Netscape 4.x Н Д П Netscape 7.x Д Д П (Enigmail) Novell Groupwise Н Д П Outlook Н Д П (G-Data) Outlook Express Н Д П (GPGOE) Pegasus Н Д П (QDPGP,PM-PGP) Pine Н Д Д (pgpenvelope,(gpg|pgp)4pine) Postme Н Д П (GPGPPL) The Bat! Д(>=1.62) Д С (Ritlabs)
Хороший обзор поддержки OpenPGP можно найти на:
<http://www.openpgp.fr.st/courrier_en.html> и
<http://www.bretschneidernet.de/tips/secmua.html>.
Пользователи программ MUA для Win32 для использования OpenPGP могут рассмотреть применение GPGrelay <http://gpgrelay.sourceforge.net>, это небольшой email-ориентированный сервер, который использует GnuPG для предоставления возможности почтовым клиентам отправлять и принимать сообщения соответствующие PGP-MIME (RFC 2015).
Про них часто спрашивают. Однако текущая точка зрения разработчиков GnuPG, то что это создаст некоторые проблемы безопасности и следовательно не стоит ожидать подобного в ближайшем будущем. Однако в некоторых областях возможно применение gpgme. Вы найдете его на <ftp://ftp.gnupg.org/gcrypt/alpha/gpgme>.
Большинство серверов ключей не принимают 'голый' сертификат отзыва. Вам придется сначала импортировать сертификат в GnuPG:
$ gpg --import МойСертификатОтзыва.asc
затем отошлите отозванный ключ на сервер ключей:
$ gpg --keyserver keyserver.kjsl.com --send-keys Мой_KeyID
(или воспользуйтесь для этого Web интерфейсом сервера ключей).
GnuPG хранит несколько файлов в специальном домашнем каталоге. Это файл персональных настроек, pubring.gpg, secring.gpg, trustdb.gpg, и другие. GnuPG всегда будет создавать и использовать эти файлы. Для Unix систем домашним обычно будет каталог " ~/.gnupg "; для Windows " C:\gnupg\ ".
Если Вы хотите переместить эти файлы в другое место, воспользуйтесь параметром:
--homedir /Мой/путь/
и тогда GnuPG создаст эти файлы в указанном каталоге. Файл таблицы открытых ключей будет в " /Мой/путь/pubring.gpg ". Таким образом можно хранить свои секреты на дискете. Не используйте для этого параметр " --keyring ", т.к. он задает дополнительные файлы связок ключей.
Перед проверкой подписи, сопровождающей пакет, необходимо сперва импортировать ключ поставщика подписи, организации или человека создавщего подпись в используемую таблицу связок ключей. Для продотвращения предупреждений от GnuPG ключу следует иметь степень достоверности (или подписать его локально).
Скачайте файл с отделенной подписью вместе с пакетом. Обычно эти файлы имеют тоже имя, что и подписанный пакет со следующими расширениями (.sig) для бинарных или (.asc) для ASCII-кодированных подписей.
После того, как ключ импортирован и пакет с сопровождающей его подписью получен, используйте:
$ gpg --verify ФайлПодпись ПодписанныйФайл
Если файл подписи имеет то же имя, что и файл пакета, то для проверки пакета достаточно указать только файл подписи, тогда GnuPG получит имя проверяемого файла путем удаления из имени расширения .sig или .asc. Например, для проверки пакета названного Пакет.tar.gz используйте:
$ gpg --verify Пакет.tar.gz.sig
Если Вы желаете создать таблицу связок ключей имеющую только небольшое подмножество ключей из Вашей основной таблицы связок, то просто укажите ключи, которые Вы хотите экспортировать:
$ gpg --armor --export Ключ1 Ключ2 Ключ3 Ключ4 > Ключи1-4.asc
Все OpenPGP секретные ключи имеют внутри себя копию открытого ключа и имеется возможность создать новый открытый ключ используя секретный.
Утилита для преобразования секретного ключа в открытый ключ (сейчас это параметр запуска утилиты gpgsplit) включена в дистрибутив GnuPG версии 1.2.1 и новейшие (а также может быть найдена в CVS). Пример использования:
$ gpgsplit --no-split --secret-to-public secret.gpg >publickey.gpg
Сперва следует экспортировать секретный ключ и преобразовывать только его. Хотя использование всей таблицы также будет работать. После завершения, файл publickey.gpg можно импортировать в GnuPG обычным способом.
Если Вы используете web-mail: Убедитесь, что в настройках web-mail адреса отключено использование HTML форматирования для отправляемых сообщений имеющих прозрачную подпись. Такое форматирование может дополнить сообщение пробелами, символами табуляции и в итоге дать неверную подпись. Отправленное чистотекстовым сообщение получатель сможет скопировать текстовый файл для проверки или возможно web-mail сервис может позволить приложить подписанное сообщение, как файл, если нет возможности отправки его чистотекстовым.
Для русскоязычной аудитории: существует также проблема таблиц символов. Сообщение на русском языке может подвергнуться перекодировке по пути следования (и не один раз). Например отправленное в cp1251 сообщение может прийти к получателю в koi8-r. Так же многие почтовые программы по разному совмещают проверку/подписывание сообщений с их перекодировыванием в другие кодировки. Например почтовая программа в Windows показывает сообщение в windows кодировке cp1251, а рекомендуемая кодировка для email koi8-r и если в настройках программы выбрана эта кодировка для отправки сообщений, то почтовый агент может подписать тескт в cp1251, а затем сконвертировать его в koi8-r, что приведет к неверной подписи, если программа у получателя не имеет такой же ошибки (или не знает о ней). Аналогично может происходить и при проверке сообщения созданного в koi8-r, но отображаемого в cp1251.
Это зависит от версии PGP.
$ gpg --rfc1991 --cipher-algo 3des ...
Пожалуйста не пользуйтесь каналами для передачи данных в gpg, а сделайте это используя файл; иначе PGP 2 не сможет понять это.
Вы не сможете зашифровать симметричным шифром файл для PGP 2.
--compress-algo 1 --cipher-algo cast5
Можно также воспользоваться "3des" вместо "cast5"; "blowfish" работает не со всеми версиями PGP 5. Также можно добавить параметр:
compress-algo 1
в файл персональных настроек " ~/.gnupg/gpg.conf ", что не помешает нормальной работе GnuPG. Это относится и к симметричному шифрованию.
PGP 2 использует RSA и IDEA алгоритмы шифрования. Срок патента на RSA истек и RSA поддерживается GnuPG с версии 1.0.3, а IDEA алгоритм остается патентованным до 2007. При определенных условиях можно пользоваться IDEA даже сейчас. В этом случае следует прочитать вопрос 3.3 о том, как получить поддержку IDEA в GnuPG и прочитать <http://www.gnupg.org/gph/en/pgp2x.html> для выполнения перехода.
(пусто)
PGP, Inc. отказалость от использования ключей ElGamal типа 20 даже для шифрования. Они поддерживают только тип 16 (котрый идентичен, по крайней мере для расшифрования). Для больше совместимости, GnuPG (с версии 0.3.3), также использует тип 16 для подключей ElGamal, которые создаются, если выбран рекомендованный по умолчанию алгоритм ключа. Можно добавить ключ ElGamal типа 16 в связку ключей.
PGP 5.x не понимает подписи v4, но OpenPGP требует v4 подписей, что GnuPG и делает по умолчанию. Используйте параметр "--force-v3-sigs" для создания v3 подписей.
Существует скрипт в каталоге tools, что бы помочь Вам. После импорта из PGP таблицы связок ключей можно выполнить следующию команду:
$ lspgpot pgpkeyring | gpg --import-ownertrust
где pgpkeyring это оригинальная таблица связок ключей, а не GnuPG таблица, которую Вы возможно создали на первом этапе.
Старые версии PGP могут не работать с некоторыми пакетами создаваемыми GnuPG. Эти пакеты создаются в полном соотвествии с OpenPGP; однако PGP не настоящее OpenPGP. Обойти это можно экспортировав секретные ключи следующей командой:
$ gpg --export-secret-keys --no-comment -a Ваш-KeyID
Другая возможная причина: по умолчанию GnuPG шифрует секретный ключ симметричным шифром Blowfish. Старые версии PGP поймут только симметричные шифры 3DES, CAST5 или IDEA. Используйте следующий способ, чтобы перешифровать секретный ключ gpg другим шифром:
$ gpg --s2k-cipher-algo=CAST5 --s2k-digest-algo=SHA1 --compress-algo=1 --edit-key <User ID>
Затем командой passwd можно сменить пароль (можно сменить его на тотже самый, но он зашифруется уже шифром CAST5).
Сейчас можно экспортировать ключ и PGP должно принять его.
Для PGP 6.x используются следующие параметры экспорта:
$ gpg --s2k-cipher-algo 3des --compress-algo 1 --rfc1991 --export-secret-keys <KeyID>
Нет. Файл " ~/.gnupg/options" переименован в " ~/.gnupg/gpg.conf" для всех версий новее 1.1.92. Если файл " ~/.gnupg/options " существует, то он будет найден при установке и всё еще будет использован, но данное переинменование потребуется для совместимости по именам файлов с будущими инструментами. Существующий файл настроек можно переименовать в gpg.conf для обновляющихся пользователей и получающих сообщение, что "файл настроек старого формата проигнорирован" (это происходит, когда программа обнаруживает оба файла и gpg.conf, и options).
Данный вопрос задают настолько часто, что здесь получилось целое HOWTO:
PGP сможет (для большинства типов ключей) использовать созданные в GnuPG секретные ключи. Проблемы возникают от того, что GnuPG поддерживает немного больше положений стандарта OpenPGP, чем PGP. Если секретный ключ использует одно из них, то PGP отвергнет их или позднее могут возникать какие-либо проблемы. Учтите, что PGP совсем не признает ElGamal ключи предназначенные для подписи, так что они неприменимы ни в одной версии.
Данные инструкции применимы для GnuPG 1.0.7 и последующих, а также для PGP 7.0.3 и последующих.
Начнем с редактирования ключа. Большинство параметров не обязательны, т.к. значения используемые по умолчанию правильны, но лучше воспризвести всё в точности потому, что некоторые иные значения параметров могут быть заданы в файле персональный настроек.
$ gpg --s2k-cipher-algo cast5 --s2k-digest-algo sha1 --s2k-mode 3 --simple-sk-checksum --edit KeyID
Отключаем некоторые особенности GnuPG. Устанавливаем предпочтения для шифров, хешей и сжатия в понимаемые PGP. (Да, Я понимаю, что список шифров получился своеобразный, но это то, что использует PGP без IDEA).
> setpref S9 S8 S7 S3 S2 S10 H2 H3 Z1 Z0
Теперь сохраняем список в ключе.
> updpref
И наконец, мы должны расшифровать секретный ключ и зашифровать заново шифром, который понравится PGP. Он указан в строке параметров при вызове команды --edit выше, поэтому сейчас необходимо только сменить пароль. Можно использовать и старый пароль, а можно воспользоваться возможностью сменить его наконец.
> passwd
Сохраняем изменения.
> save
Сейчас можно использовать обычный экспорт:
$ gpg --export KeyID > МойОткрытыйКлюч.pgp
$ gpg --export-secret-key KeyID > МойСекретныйКлюч.pgp
За эту информацию спасибо David Shaw!
GnuPG требует установки прав setuid(root) на многих системах. Это необходимо для блокирования страниц памяти. Блокирование страниц не позволяет операционной системе сохранять их на диск, что позволяет хранить Ваши данные в секрете. Если Вы не получаете это сообщение, то видимо операционая система позволяет блокировать страницы непревелигированным пользователям. GnuPG отказывается от привелигированного режима сразу после блокирования страниц.
Для установки прав setuid(root) исполняемому файлу gpg выполните:
$ chmod u+s /путь/к/gpg
или
$ chmod 4755 /путь/к/gpg
Некоторые люди предпочитают избегают применения setuid(root), если нет каких-либо причин для создания особой секретности. Посоветуйтесь с системным администратором, если нет возможности выполнить указанные действия самостоятельно.
На UnixWare 2.x и 7.x следует установить GnuPG с привилегиями 'plock' для получения аналогичного эффекта:
$ filepriv -f plock /путь/к/gpg
Если нет возможности или Вы не хотите устанавливать для GnuPG права setuid(root), можно воспользоваться параметром "--no-secmem-warning" или добавить:
no-secmem-warning
в файл персональных настроек ~/.gnupg/gpg.conf (это избавит от предупреждений).
На некоторых системах (например Windows) GnuPG не блокирует страницы памяти и старые версии GnuPG (<=1.0.4) предупреждали:
gpg: Please note that you don't have secure memory gpg: Учтите, что Вы не имеете безопасной памяти
Данное предупреждение нельзя было отключить вышеуказанным параметром потому, что причина его возникновения очень серьезна. Однако это слишком смущало пользователей, поэтому сообщение было убрано.
LFS корректно работает начиная с версии 1.0.4. Если configure не видит этого - попробуйте другой компилятор. egcs 1.1.2 работает прекрасно, другие gccs иногда нет. Некоторые проблемы компиляции GnuPG 1.0.3 и 1.0.4 на HP-UX и Solaris были вызваны плохой поддержкой LFS.
Это вызвано тем, что некоторая информация хранится непосредственно в trustdb, но все вычисления степеней доверия могут быть выполнены только после команды сохранения " save ". Это трудно поправимая ошибка архитектуры программы, которая будет пересмотрена в какой-нибудь из будущих версий.
Шифр RSA входит в пакет GnuPG начиная с версии 1.0.3. Если Вы всё еще используете параметр "load-extension rsa" в файле персональных параметров Вы увидите данное сообщение. Просто удалите данную команду загрузки модуля из файла персональных параметров.
Это известная ошибка, уже исправленная в последовавшей версии GnuPG.
Используйте параметр --emulate-md-encode-bug.
Обновите GnuPG до версии 1.0.2 или новее.
Это называется отделенный черточками текст, что является требованием OpenPGP. Это происходит всегда, когда строка начинается с черточки ("-") и необходмо для четкого отделения структур подписи (типа "-----BEGIN PGP SIGNATURE-----") от других строк начинающихся с более чем двух черточек.
Если Вы используете GnuPG для обработки подобных сообщений, то все дополнительные черточки удалятся. Хорошие почтовые клиенты (MUA) удаляют эти черточки при отображении сообщения.
Единственный способ иметь множественные подписи в файле это использование формата OpenPGP с пакетами One-Pass Signature (которые используются GnuPG по умолчанию) или формат прозрачных подписей.
Старые версии gpg любили ненормально завершаться и оставлять блокировочные файлы. Зайдите в ~/.gnupg удалеите все " .*.lock " файлы.
Начиная с версии 1.0.3, ключи в GnuPG создаются с предпочтением шифра TWOFISH (и шифра AES начиная с версии 1.0.4), и что тоже важно, они совместимы с новым методом шифрования MDC. В будущем это станет частью OpenPGP и поддерживается также PGP 7. Новый метод предотвращает атаки на системы шифрования почты.
Это означает, что версии GnuPG до 1.0.3 имеют проблемы с новыми ключами. По причине исправления ошибок и прорех в безопасности, Вам настоятельно рекомендуется использовать последнюю стабильную версию GnuPG. В качестве временной меры, для решения проблемы, Вы можете принудить GnuPG использовать старый шифр по умолчанию в качестве основного, добавив:
cipher-algo cast5
в Ваш файл персональных параметров.
Если предупреждение появляется сразу после создания нового ключа, то Вы являетесь свидетелем ошибки версии 1.0.4. Она использует новый шифр AES (Rijndael), который некорректно называет "нерекомендуемым". Игнорируйте данной предупреждение. Все последовавшие затем версии GnuPG не имеют данной проблемы.
Во многих реализациях libc, даты превышающие 2038-01-19 не могут быть правильно отображены. 64-bit ОС не имеют данной проблемы. Чтобы не выводить неверное значение даты GnuPG заменяет ее вопросиками. Если хотите получить корректное значение - используйте параметры --with-colons и --fixed-list-mode.
А Вы уверены, что Ваша проблема еще не обсуждалась в почтовых рассылках? Вы просмотрели список ошибок (ссылку Вы найдете в документации)? Если не уверены в том, что это ошибка, отправьте письмо в gnupg-devel рассылку. В противном случае воспользуйтесь системой отслеживания ошибок GUUG <http://bugs.guug.de/Reporting.html>.
GnuPG во-первых, и это главное, внедряет OpenPGP стандарт (RFC 2440), который использует инфраструктуру отличную от X.509.
Всё это криптосистемы с открытым ключом, но открытые ключи в них на самом деле обрабатываются различным образом.
В соотвествии с OpenPGP GnuPG сохраняет User ID строки (и другие вещи) используя UTF-8. В процессе перекодирования в формат Unicode, многие национальные символы кодируются как дву- или трех-байтовые последовательности. Например, å (0xE5 в ISO-8859-1) станет Ã¥ (0xC3, 0xA5). Это также может быть причиной того, почему серверы ключей не находях Ваш ключ.
Это будет исправлено после обновления GnuPG до autoconf-2.50. До тех пор: найдите строку CDPATH в скрипте configure вставьте после него:
unset CDPATH
Есть небольшая ошибка в версии 1.0.6, из-за которой которой некорректно обрабатываются пакеты доверий. Возможно понадобится данный патч, если нет возможности обновить GnuPG:
<http://www.gnupg.org/developer/gpg-woody-fix.txt>
Был изменен способ хранения подписей для сохранения совместимости с v3 подписями. Можете воспользоваться новым параметром --rebuild-keydb-caches, который был добавлен в данной версии и предназначен для миграции на новые версии и также увеличивает скорость многих операций со связками ключей.
Нет. В GnuPG версии 1.2.1 и более ранних имелась ошибка в способе определения достоверности ключей. В процессе разработки GnuPG 1.2.2, ошибка была обнаружена в коде вычисления достоверности. Ошибка приводила к тому, что для ключей и имеющиех больше одного User ID достоверность одного User ID распространялась на все присутствующие в ключе. Ошибка исправлена в GnuPG версии 1.2.2 и рекомендуется обновить GnuPG. Больше информации и патч для некоторых до-1.2.2 версий GnuPG см. здесь:
<http://lists.gnupg.org/pipermail/gnupg-announce/2003q2/000268.html>
Многие дистрибутивы GNU/Linux, основанные на RPM, устанавливают GnuPG как часть стандартной инсталляции в каталог /usr/bin. Позднее, когда Вы компилируете и устанавливаете GnuPG из исходников, а не из RPM, файлы обычно (по умолчанию) сохраняются в " /usr/local/bin ", пока не указан параметр " --prefix " с другим каталогом при запуске configure. А каталог " /usr/bin " скорее всего предшествует каталогу " /usr/local/bin " в переменной PATH.
Для решения данной проблемы удалите RPM версию командой " rpm -e gnupg " перед установкой программы из исходных текстов. Если Вы получаете ошибку связей при удалении старого пакета RPM (таких, как up2date в RedHat, который использует GnuPG), удалите пакет RPM командой " rpm -e gnupg --nodeps ". Все связи станут вновь актуальны после установки скомпилированной версии. Если по умолчанию используется каталог " /usr/local/bin ", некоторые пакеты (например SuSE's Yast Online Update) необходимо настроить на новое местоположение GnuPG в каталоге " /usr/local/bin " или создать символические ссылки в " /usr/bin ", которые будут указывать на соответствующие файлы в " /usr/local/bin ".
Для создания пары ключей секретный/открытый запустите:
$ gpg --gen-key
и выберите значения по умолчанию.
Данные зашифрованные открытым ключом могут быть расшифрованы только соответствующим ему секретным ключом. Секретный ключ защищается паролем, а открытый ключ - нет.
Чтобы отправить шифрованное сообщение кому-либо необхоимо зашифровать это сообщение открытым ключом получателя и тогда он сможет расшифровать сообщение своим и только своим секретным ключом и вводом пароля секретного ключа.
GnuPG также широко используется для создания подписей. Файлы зашифрованные секретным ключом могут быть расшифрованы открытым ключом. Чтобы подписать что-нибудь, вычисляется хеш подписываемых данных и затем хеш шифруется каким-либо образом секретым ключом. Если кто-либо имеет Ваш открытый ключ, он может проверить, что подпись создана именно Вами и что оно не было изменено.
Таблица связок ключей это файл на диске, который хранит ключи. Есть таблица связок открытых ключей, в которой хранятся Ваши открытые ключи и открытые ключи Ваших друзей. Также имеется таблица связок секретных ключей, в которой хранятся Ваши секретные ключи и Вы должны беречь их от посторонних. Никогда не предоставляйте доступ к данным файлам другим людям и используйте *сильные* пароли для защиты Ваших данных.
Вы можете зашифровать что-либо стандартным способом используя параметр " gpg -c ". Это позволит зашифровать данные паролем и не использовать открытый и секретный ключи. Если получатель шифрованного сообщения знает пароль - он сможет расшифровать его. Обычно это используется для шифрования себе. Следует пользоваться этим только для переписки с теми, кто знает или может легко обменяться с Вами паролями (например с Вашим приятелем или женой). Преимущество данного подхода в том, что можно время от времени менять пароль, чем снизить риск того, что многие старые сообщения будут прочтены теми, кто узнает Ваш пароль.
Можно добавить/скопировать ключи в/из таблицы связок ключей командами " gpg --import " и " gpg --export ". " gpg --export-secret-keys " экспортирует секретные ключи. Это обычно не нужно делать, но можно создать ключ на одном компьютере, а затем перенести на другой.
Ключи могут быть сертифицированы используя команду " gpg --edit-key ". Когда Вы подписываете ключ, Вы подтверждаете, что ключ принадлежит персоне, указанной в идентификаторе ключа. Вам следует полностью убедиться в том, что ключ действительно принадлежит данной персоне: Поэтому Вам следует проверить отпечатки ключа командой:
$ gpg --fingerprint KeyID
по телефону (если Вы хорошо знаете голос другого человека), на собрании по подписыванию ключей (обычно устраивается на компьютерных конференциях) или встрече местной группы пользователей GNU/Linux.
Так, что еще. Можете воспользоваться параметром " -o ИмяФайла " для переназначения вывода некоторой информации в файл (используйте "-" для принудительного вывода в stdout). " -r " позволяет указать получателя (чьим открытым ключом шифровать) в командной строке вместо ввода в интерактивном режиме.
Да, еще одно важное дополнение. По умолчанию зашифрованные данные имеют двоичный формат. Если неоходимо получить их как ASCII текст, который выглядит читабельным, то добавьте параметр " -a ". Но предпочтительно использовать MIME, который понимаемают почтовые клиенты (Mutt, Pine и мн. другие).
Существует небольшая проблема безопасности в OpenPGP (и соответственно в GnuPG); чтобы избежать ее Вам следует всегда подписывать и шифровать сообщения вместо простого шифрования.
Это ключи ElGamal, которые сгенерированы GnuPG в v3 (RFC 1991) пакетах. Черновой OpenPGP позднее изменил идентификатор ElGamal ключей, которые используются и для подписи и для шифрования, с 16 на 20. GnuPG сейчас использует 20 при создании новых ElGamal ключей, но всё еще признает 16 (которые согласно OpenPGP теперь "только для шифрования"), если такой ключ в v3 пакете. GnuPG единственная программа, которая использовала эти v3 ElGamal ключи - поэтому такое допущение вполне безопасно.
Он работает более или менее похоже на то, как это сделано в PGP. Отличие в том, что степень доверия высисляется в тот момент, когда она необходима. Это одна из причин необходимости файла trustdb, который содержит список подписей достоверных ключей. Если Вы не запустили программу в пакетном режиме, то Вам предложат назначить значение параметра доверия (доверия владельцу ключа) для ключа.
Вы можете просмотреть достоверность (вычисленное значение) используя команду.
$ gpg --list-keys --with-colons
Если первое поле "pub" или "uid", то второе поле показывает Ваше доверие:
o = Неизвестно (ключ нов для программы)
e = Срок действия ключа истек
q = Не определено (нет присвоенного значения)
n = Полностью нет доверия данному ключу
m = Ограниченное доверие ключу
f = Полное доверие
u = Абсолютное доверие ключу; обычно используется,
только для ключей, для которых Вы имеете также и секретный ключ.
r = Ключ был отозван
d = Ключ отключен
Значение в "pub" записи предпочтительнее всех "uid" записей. Вы можете получить список присвоенных степеней доверия (степень Вашего доверия корректности подписывания ключей другими людьми) командой:
$ gpg --list-ownertrust
Первое поле это отпечаток главного ключа, а второе поле - присвоенная степень:
- = Нет степени доверия вледьцу, не присвоена еще или не вычислена.
n = Не доверять подписям данного человека на других ключах.
m = Ограниченное доверие подписям данного человека.
f = Считать, что человек действительно знает, как правильно
подписывать ключи.
u = Не нужно доверий потому, что у нас имеется секретный ключ.
Храните данные значения в секрете потому, что они означают Ваше отношение к другим людям. PGP хранит данную информацию в своей таблице связок ключей, поэтому публиковать свою таблицу связок ключей, вместо экспорта конкретных связок ключей - плохая идея. GnuPG хранит значения доверий файле trustdb.gpg, поэтому можно свободно дать кому-либо свой файл таблицы связок колючей (но можете использовать также и параметр --export).
Это внутреннее представление User ID в trustdb. "C26EE891" это KeyID, "298" это локальный ID (LID) (номер записи trustdb) и "09FB" это последние два байта хеша ripe-md-160 из User ID для данного ключа.
Во время проверки достоверности ключа GnuPG иногда печатает некоторую информацию, которая предваряет информацию о проверяемых данных.
"key 12345678.3456"
Это о том, что Key ID имеет 12345678 и его внутренний номер 3456, который является номером записи в так называемой записи каталога trustdb.
"uid 12345678.3456/ACDE"
Это о том, что это User ID для того же ключа. Для идентификации User ID в связке - печатаются два последних байта (ACDE) его ripe-md-160 хеша.
"sig 12345678.3456/ACDE/9A8B7C6D"
Это о том, что это подпись ключом с Key ID 9A8B7C6D указанных выше ключа и User ID, если это подпись, подписывающая сам ключ, то User ID часть будет пуста (..//..).
Нет. Можно, например, добавить или удалить "Comment:" строки. Они аналогичны строкам заголовка письма. Однако, срока "Hash:" требуется для OpenPGP подписей для указания использованного алгоритма цифровой подписи.
Список предпочитаемых алгоритмов это список шифров, хешей и алгоритмов сжатия сохраняемый в самоподписи ключа во время создания ключа. Когда Вы шифруете документ, GnuPG использует данный список (который является частью открытого ключа) для того, чтобы определить какие алогоритмы использовать. В основном это предназначеначено для того, чтобы сообщить другим лючям, какие алгоритмы получатель сможет принять и порядок предпочтения им данных алгоритмов.
В версии 1.0.7 и новейших, Вы можете использовать редактирование ключа и установить новый список предпочтений используя команду "setpref"; формат данной команды аналогичен выводу команды "pref". Предпочтения не изменятся немедленно, но они будут использованы при создании нового User ID. Если Вы хотите обновить предпочтения существующих User ID, выберите эти User ID (или ни одного для обновления всех сразу) и дайте команду "updpref". Учтите, что отметка времени на самоподписи увеличивается на одну секунду, когда выполняется данная команда.
Премного благодарны Nils Ellmenreich за ведение настоящего FAQ столь длительный срок, Werner Koch за первоначальный FAQ, всем участникам почтовых рассылок gnupg-users и gnupg-devel присылавших вопросы и ответы. Они предоставили наибольшее количество ответов.
Также спасибо Casper Dik за скрипт для создания данного FAQ (он использует его для великолепного FAQ по Solaris2).
От переводчика:
Огромное спасибо разработчикам GnuPG.
Премного благодарен Павлу Шайдо за его переводы GNU Privacy Handbook
и руководства (man), за ценные советы по переводу интерфейса, настоящего
FAQ и пр. документов по GnuPG.
Спасибо также Gyre, Андрею Кавко, всем участникам почтовых рассылок
gnupg-ru и pgp-n-gpg.
Copyright (C) 2000, 2001, 2002, 2003 Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111, USA
Copyright (C) 2003 Translation from English into Russian by Maxim Britov
Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |