diff options
Diffstat (limited to 'doc/ru')
| -rw-r--r-- | doc/ru/dt124_ru.txt | 1545 | ||||
| -rw-r--r-- | doc/ru/faq163_ru2.raw | 1403 |
2 files changed, 2948 insertions, 0 deletions
diff --git a/doc/ru/dt124_ru.txt b/doc/ru/dt124_ru.txt new file mode 100644 index 000000000..d12f4b3cc --- /dev/null +++ b/doc/ru/dt124_ru.txt @@ -0,0 +1,1545 @@ +(c)GnuPG Developments Team +(c)2003 Translation from English into Russian UTF-8 by Maxim Britov <[email protected]> +Thanks a lot to Pavel Shaido, Andrew Kavko. + +Russian team: <[email protected]> + +GnuPG version: 1.2.4-cvs +Last revision by: MaxBritov +Last revision date: 18 Sep 2003 15:00 +Used codepage: UTF-8 +------------------------------------- + +Format of colon listings +Специальный формат вывода с разделителем ":" +для использования Вашими программами +============================================ +Первоначальный пример: + +$ gpg --fixed-list-mode --with-colons --list-keys \ + --with-fingerprint --with-fingerprint [email protected] + +pub:f:1024:17:6C7EE1B8621CC013:899817715:1055898235::m:::scESC: +fpr:::::::::ECAF7590EB3443B5C7CF3ACB6C7EE1B8621CC013: +uid:f::::::::Werner Koch <[email protected]>: +uid:f::::::::Werner Koch <[email protected]>: +sub:f:1536:16:06AD222CADF6A6E1:919537416:1036177416:::::e: +fpr:::::::::CF8BCC4B18DE08FCD8A1615906AD222CADF6A6E1: +sub:r:1536:20:5CE086B5B5A18FF4:899817788:1025961788:::::esc: +fpr:::::::::AB059359A3B81F410FCFF97F5CE086B5B5A18FF4: + +The double --with-fingerprint prints the fingerprint for the subkeys +too, --fixed-list-mode is themodern listing way printing dates in +seconds since Epoch and does not merge the first userID with the pub +record. +Двукратное использование опции --with-fingerprint выводит также +и отпечатки подключей, --fixed-list-mode задает вывод дат в секундах +от начала Epoch(?) и не объединяет первый User ID с записью pub. + + 1. Поле: Type of record + pub = public key + pub = открытый ключ + crt = X.509 certificate + crt = X.509 сертификат + crs = X.509 certificate and private key available + crs = X.509 сертификат и секретный ключ доступен + sub = subkey (secondary key) + sub = подключ (вторичный ключ) + sec = secret key + sec = секретный ключ + ssb = secret subkey (secondary key) + ssb = секретный подключ (вторичный ключ) + uid = user id (only field 10 is used) + uid = User Id (используется только поле 10) + uat = user attribute (same as user id except for field 10) + uat = пользовательские атрибуты (также как User Id кроме поля 10) + sig = signature + sig = подпись + rev = revocation signature + rev = отзывающая подпись + fpr = fingerprint: (fingerprint is in field 10) + fpr = отпечаток (отпечаток в поле 10) + pkd = public key data (special field format, see below) + pkd = данные открытого ключа (поле имет спец. формат, см. далее) + grp = reserved for gpgsm + grp = зарезервировано для gpgsm + rvk = revocation key + rvk = ключ отзыва + tru = trust database information + tru = информация из таблицы доверий + + 2. Поле: A letter describing the calculated trust. This is a single + letter, but be prepared that additional information may follow + in some future versions. (not used for secret keys) + Буква описывающая вычисленное доверие. Это однобуквенное значение, + но будьте готовы, что в будущих версиях может появиться + и дополнительная информация (не используется для секретных ключей). + o = Unknown (this key is new to the system) + o = Неизвестно (данный ключ нов для программы) + i = The key is invalid (e.g. due to a missing self-signature) + i = Неправильный ключ (напр. отсутствует самоподпись) + d = The key has been disabled + (deprecated - use the 'D' in field 12 instead) + d = Ключ отключен. + (устарело - взамен используется 'D' в поле 12) + r = The key has been revoked + r = Ключ отозван + e = The key has expired + e = Ключ просрочен + - = Unknown trust (i.e. no value assigned) + - = Степень доверия неизвестна (т.е. не назначена) + q = Undefined trust + '-' and 'q' may safely be treated as the same + value for most purposes + q = Неопределенная степень доверия + '-' и 'q' в большинстве случаем могут безопасно + трактоваться как одинаковые + n = Don't trust this key at all + n = Полное недоверие ключу + m = There is marginal trust in this key + m = Ограниченное (marginal) доверие ключу + f = The key is fully trusted + f = Полностью доверенный ключ + u = The key is ultimately trusted. This often means + that the secret key is available, but any key may + be marked as ultimately trusted. + u = Абсолютное доверие ключу. Обычно это означает, что + имеется в наличии и секретный ключ, но абсолютно + доверяемым может быть назначен любой ключ. + 3. Поле: длина ключа в битах. + 4. Поле: Алгоритм: 1 = RSA + 2 = RSA (только шифрование) + 3 = RSA (только подпись) + 16 = ElGamal (только шифрование) + 17 = DSA (иногда называемый DH, только подпись) + 20 = ElGamal (подпись и шифрование) + (другие ID см. в include/cipher.h) + 5. Поле: Какой-либо KeyID + 6. Поле: Дата создание (в UTC) + 7. Поле: Дата окончания срока годности ключа или пустая, если неограничен. + 8. Поле: Used for serial number in crt records (used to be the Local-ID) + Используется для серийного номера в crt записях (хранит Local ID) + 9. Поле: Доверие владельцу (только для главных ключей) + Это однобуквенное значение, но будьте готовы, что в следующих + версиях может появиться дополнительная информация. +10. Поле: User-ID. Значение кодируется наподобие C-строк для хранения + управляющих символов (двоеточие кодируется "\x3a"). + Не используется с --fixed-list-mode в gpg. + A UAT record puts the attribute subpacket count here, a + space, and then the total attribute subpacket size. + In gpgsm the issuer name comes here + An FPR record stores the fingerprint here. + The fingerprint of an revocation key is stored here. + UAT показывает здесь количестиво подпакетов атрибутов, пробел, + и затем общий размер подпакета атрибутов. + В gpgsm здесь имя издателя. + FRP показывает здесь отпечаток ключа. + Отпечаток ключа отзыва показывается здесь. +11. Поле: Класс подписи. Это 2 две шестнадцатеричных цифры с + последующей буквой 'x' для экспортируемой подписи или + буквой 'l' для локальной подписи. + Байт класса ключа отзыва также дается здесь, + причем 'x' и 'l' имеют тоже значение. + Класс (см. g10/keydb.h): + 1f = IS_KEY_SIG + 10 = IS_UID_SIG + 18 = IS_SUBKEY_SIG + 20 = IS_KEY_REV + 30 = IS_UID_REV + 28 = IS_SUBKEY_REV +12. Поле: Совместимость ключей: + e = шифрование + s = подпись (подпись данных) + c = сертификация (подпись ключей) + Ключ может иметь любую их комбинацию в любом порядке. + В дополнение к данным буквам, главный ключ имеет заглавные + версии букв для указания возможностей ключа в целом, + а также заглавную букву 'D' - ключ отключен. +13. Поле: Used in FPR records for S/MIME keys to store the fingerprint of + the issuer certificate. This is useful to build the + certificate path based on certificates stored in the local + keyDB; it is only filled if the issue certificate is + available. The advantage of using this value is that it is + guaranteed to have been been build by the same lookup + algorithm as gpgsm uses. + For "uid" recods this lists the preferences n the sameway the + -edit menu does. + Используется в FRP записях для S/MIME ключей для хранения + отпечатка сертификата издателя. Это полезно для построения + пути сертификата на основе сертификатов хранимых в keyDB; + это заполнено, если сертификат издателя доступен. + Полезность этого в том, что гарантируется использование + того же алгоритма поиска, как в gpgsm. +14. Поле: Flag field used in the --edit menu output: + Поле флага используемого в выводе --edit меню: + + +All dates are displayed in the format yyyy-mm-dd unless you use the +option --fixed-list-mode in which case they are displayed as seconds +since Epoch. More fields may be added later, so parsers should be +prepared for this. When parsing a number the parser should stop at the +first non-number character so that additional information can later be +added. +Все даты показываются в формате yyy-mm-dd до тех пор, пока не +используется опция --fixed-list-mode при испоьзовании которой, +даты отображаются в секундах с начала Epoch. В будущем могут +появиться новые поля, так что программы разбирающие данный +формат должны быть готовы к этому. При разборе количества полей +следует остановиться на первом не цифровом символе так, чтобы +позднее могла добавиться дополнительная информация. + +Если поле 1 имеет тэг "pkd", листинг выглядит подобно этому: +pkd:0:1024:B665B1435F4C2 .... FF26ABB: + ! ! !-- значение + ! !------ число битов в значении + !--------- индекс (напр. DSA имеет от 0 до 3: p,q,g,y) + + +The "tru" trust database records have the fields: +Запись таблицы доверий "tru" имеет следующие поля: + + 1: Reason for staleness of trust. If this field is empty, then the + trustdb is not stale. This field may have multiple flags in it: + Причина устаревания таблицы. Если поле пусто, таблица не устарела. + Данное поле может иметь несколько флагов: + + o: Trustdb устарела + t: Trustdb была создана при иной модели доверий, чем текущая. + + 2: Модель доверия. Это всегда ноль (т.е. "Classic") + в данной версии GnuPG. + 3: Дата создания trustdb в секундах с 1/1/1970. + 4: Срок годности trustdb в секундах с 1/1/1970. + + + +Формат вывода параметра "--status-fd" +===================================== +Every line is prefixed with "[GNUPG:] ", followed by a keyword with +the type of the status line and a some arguments depending on the +type (maybe none); an application should always be prepared to see +more arguments in future versions. +Каждая строка начинается с "[GNUPG:] ", далее следует ключевое слово +с типом строки статуса и некоторыми (необязательно) аргументами, +основанными на типе; приложениям следует всегда быть готовыми +получить больше аргументов в будущих версиях. + + GOODSIG <long keyid> <username> + The signature with the keyid is good. For each signature only + one of the three codes GOODSIG, BADSIG or ERRSIG will be + emitted and they may be used as a marker for a new signature. + The username is the primary one encoded in UTF-8 and %XX + escaped. + Подпись с <long keyid> достоверна. Для каждой подписи будет + только один из трех кодов GOODSIG, BADSIG или ERRSIG и они могут + использоваться как маркер для новой подписи. + <username> есть главный User ID в кодировке UTF-8 и %XX. + + EXPSIG <long keyid> <username> + The signature with the keyid is good, but the signature is + expired. The username is the primary one encoded in UTF-8 and + %XX escaped. + Подпись с <long keyid> достоверна, но просрочена. + <username> есть главный User ID в кодировке UTF-8 и %XX. + + EXPKEYSIG <long keyid> <username> + The signature with the keyid is good, but the signature was + made by an expired key. The username is the primary one + encoded in UTF-8 and %XX escaped. + Подпись с <long keyid> достоверна, но создана просроченным ключом. + <username> есть главный User ID в кодировке UTF-8 и %XX. + + REVKEYSIG <long keyid> <username> + The signature with the keyid is good, but the signature was + made by a revoked key. The username is the primary one + encoded in UTF-8 and %XX escaped. + Подпись с <long keyid> достоверна, но создана отозванным ключом. + <username> есть главный User ID в кодировке UTF-8 и %XX. + + BADSIG <long keyid> <username> + The signature with the keyid has not been verified okay. + The username is the primary one encoded in UTF-8 and %XX + escaped. + Подпись с <long keyid> недостоверна после проверки. + <username> есть главный User ID в кодировке UTF-8 и %XX. + + ERRSIG <long keyid> <pubkey_algo> <hash_algo> \ + <sig_class> <timestamp> <rc> + It was not possible to check the signature. This may be + caused by a missing public key or an unsupported algorithm. + A RC of 4 indicates unknown algorithm, a 9 indicates a missing + public key. The other fields give more information about + this signature. sig_class is a 2 byte hex-value. + Нет возможности проверить подпись. Это может быть вызвано + отсутствием открытого ключа или неизвестным алгоритмом. + <rc>: 4 - неизвестный алгоритм, 9 - отстутствует открытый + ключ. Другие поля дают больше информации о данной подписи. + <sig_class> двухбайтное шестнадцатеричное значение. + + + VALIDSIG <fingerprint in hex> <sig_creation_date> <sig-timestamp> + <expire-timestamp> <sig-version> <reserved> <pubkey-algo> + <hash-algo> <sig-class> <primary-key-fpr> + + The signature with the keyid is good. This is the same as + GOODSIG but has the fingerprint as the argument. Both status + lines are emitted for a good signature. All arguments here + are on one long line. sig-timestamp is the signature creation + time in seconds after the epoch. expire-timestamp is the + signature expiration time in seconds after the epoch (zero + means "does not expire"). sig-version, pubkey-algo, hash-algo, + and sig-class (a 2-byte hex value) are all straight from the + signature packet. PRIMARY-KEY-FPR is the fingerprint of the + primary key or identical to the first argument. This is + useful to get back to the primary key without running gpg + again for this purpose. + Подпись с <keyid> достоверна. Это то же, что и GOODSIG, но + имеет отпечаток ключа в качестве аргумента. Обе строки статуса + будут присутствовать при достоверной подписи. Все аргументы + передаются одной длинной строкой. <sig-timestamp> время создания + подиси с 01/01/1970. <expire-timestamp> время окончания срока + действия подписи в секундах (0 - без ограничения срока). + <sig-version>, <pubkey-algo>, <hash-algo> и <sig-class> (двухбайтное + шестнадцатеричное значение) берутся из пакета подписи. + <primary_key_frp> отпечаток гланого ключа или идентичен первому + аргументу. Это полезно для получения гланого ключа без запуска + gpg для этой цели. + + SIG_ID <radix64_string> <sig_creation_date> <sig-timestamp> + This is emitted only for signatures of class 0 or 1 which + have been verified okay. The string is a signature id + and may be used in applications to detect replay attacks + of signed messages. Note that only DLP algorithms give + unique ids - others may yield duplicated ones when they + have been created in the same second. + Выдается только для подписей класса 00 или 01, достоверных + после проверки. <radix64_string> идентификатор подписи + и может использоваться приложением для обнаружения + атак с повторной отправкой подписанных сообщений. Заметим, что только + DLP алгоритмы дают уникальные идентификаторы, в то время как + другие могут давать одинаковые, если создают их в ту же секунду. + + ENC_TO <long keyid> <keytype> <keylength> + The message is encrypted to this keyid. + keytype is the numerical value of the public key algorithm, + keylength is the length of the key or 0 if it is not known + (which is currently always the case). + Сообщение зашифровано для данного <long_keyid>. + <keytype> цифровое обозначение алгоритма шифрования с + открытым ключом. <keylength> длина ключа, или 0 если неизвестно + (что сейчас всегда). + + NODATA <what> + No data has been found. Codes for what are: + 1 - No armored data. + 2 - Expected a packet but did not found one. + 3 - Invalid packet found, this may indicate a non OpenPGP message. + You may see more than one of these status lines. + Данные не найдены. Код: + 1 - Нет защищенных данных. + 2 - Ожидался пакет, но не обнаружен. + 3 - Неправильный пакет найден, это может быть не OpenPGP + сообщение. + Вы можете получить несколько таких строк. + + UNEXPECTED <what> + Unexpected data has been encountered + 0 - not further specified 1 + Получены неожиданные данные + 0 - нет иных уточнений + + TRUST_UNDEFINED <error token> + TRUST_NEVER <error token> + TRUST_MARGINAL + TRUST_FULLY + TRUST_ULTIMATE + For good signatures one of these status lines are emitted + to indicate how trustworthy the signature is. The error token + values are currently only emiited by gpgsm. + Для достоверных подписей одна из этих строк статуса означает + степень доверия подписавшему. <error_token> в настоящий + момент выдается только gpgsm. + + SIGEXPIRED + This is deprecated in favor of KEYEXPIRED. + Устарело. Заменено на KEYEXPIRED. + + KEYEXPIRED <expire-timestamp> + The key has expired. expire-timestamp is the expiration time + in seconds after the epoch. + Ключ просрочен. <expire_timestamp> время окончания срокадействия + в секундах с 01/01/1970. + + KEYREVOKED + The used key has been revoked by its owner. No arguments yet. + Использованный ключ отозван владельцем. Пока нет имеет аргументов. + + BADARMOR + The ASCII armor is corrupted. No arguments yet. + ASCII упаковка повреждена. Пока нет аргументов. + + RSA_OR_IDEA + The IDEA algorithms has been used in the data. A + program might want to fallback to another program to handle + the data if GnuPG failed. This status message used to be emitted + also for RSA but this has been dropped after the RSA patent expired. + However we can't change the name of the message. + Алгоритм IDEA использован в данных. Вашей программе может + потребоваться обратиться к другой программе для, если GnuPG не + работает, для получения данных. Для RSA данное сообщение больше не + применяется после окончания срока патента на алгоритм RSA. + Однако мы не можем изменить имя сообщения. + + SHM_INFO + SHM_GET + SHM_GET_BOOL + SHM_GET_HIDDEN + + GET_BOOL + GET_LINE + GET_HIDDEN + GOT_IT + + NEED_PASSPHRASE <long main keyid> <long keyid> <keytype> <keylength> + Issued whenever a passphrase is needed. + keytype is the numerical value of the public key algorithm + or 0 if this is not applicable, keylength is the length + of the key or 0 if it is not known (this is currently always the case). + Выдается когда необходим ввод пароля. + <keytype> цифровое значение алгоритма шифрования с открытым ключом или + 0 если это не применимо. <keylenght> длина ключа или 0 если неизвестно + (всегда на данный момент). + + NEED_PASSPHRASE_SYM <cipher_algo> <s2k_mode> <s2k_hash> + Issued whenever a passphrase for symmetric encryption is needed. + Выдвется, если необходим пароль для симметричного шифрования. + + MISSING_PASSPHRASE + No passphrase was supplied. An application which encounters this + message may want to stop parsing immediately because the next message + will probably be a BAD_PASSPHRASE. However, if the application + is a wrapper around the key edit menu functionality it might not + make sense to stop parsing but simply ignoring the following + BAD_PASSPHRASE. + Не предоставлен пароль. Приложение может захотеть прекратить + дальнейший разбор немедленно, т.к. следующим сообщением должно быть + BAD_PASSPHRASE. Однако, если приложение обрабатывает вывод работы + с меню редактирования ключа может не иметь смысла прекращать разбор, + а просто игнорировать последующий BAD_PASSPHRASE. + + BAD_PASSPHRASE <long keyid> + The supplied passphrase was wrong or not given. In the latter case + you may have seen a MISSING_PASSPHRASE. + Пароль неверен или не задан. В последнем случай сначала будет выдано + сообшение MISSING_PASSPHRASE. + + GOOD_PASSPHRASE + The supplied passphrase was good and the secret key material + is therefore usable. + Переданный пароль принят и секретный ключ готов к применению. + + DECRYPTION_FAILED + The symmetric decryption failed - one reason could be a wrong + passphrase for a symmetrical encrypted message. + Сбой расшифровка симметричным алгоритмом. Единствено возможная + причина - неверный пароль. + + DECRYPTION_OKAY + The decryption process succeeded. This means, that either the + correct secret key has been used or the correct passphrase + for a conventional encrypted message was given. The program + itself may return an errorcode because it may not be possible to + verify a signature for some reasons. + Расшифровано успешно. Это означает, что был использован правильный + секретный ключ или правильный пароль дан. Программа может вернуть + ошибку потому, что невозможно проверить подпись по некоторым причинам. + + NO_PUBKEY <long keyid> + NO_SECKEY <long keyid> + The key is not available + Ключ недоступен. + + IMPORTED <long keyid> <username> + The keyid and name of the signature just imported + <long keyid> и <username> подписи только-что импортированы. + + IMPORT_OK <reason> [<fingerprint>] + The key with the primary key's FINGERPRINT has been imported. + Reason flags: + 0 := Not actually changed + 1 := Entirely new key. + 2 := New user IDs + 4 := New signatures + 8 := New subkeys + 16 := Contains private key. + The flags may be ORed. + Ключ с главным ключом <fingerprint> импортирован. + <reason>: + 0 := Не произведено изменений. + 1 := Внесен новый ключ. + 2 := Новый User ID. + 4 := Новая подпись. + 8 := Новый подключ. + 16 := Получен секретный ключ. + Флаги можно объединять логическим ИЛИ. + + IMPORT_PROBLEM <reason> [<fingerprint>] + Issued for each import failure. Reason codes are: + 0 := "No specific reason given". + 1 := "Invalid Certificate". + 2 := "Issuer Certificate missing". + 3 := "Certificate Chain too long". + 4 := "Error storing certificate". + Выдается для каждой ошибки импорта. + <reason>: + 0 := Нет особых признаков. + 1 := Неверный Сертификат. + 2 := Отсутствует владелец Сертификата. + 3 := Цепочка Сертификатов слишком длинна. + 4 := Ошибка сохранения Сертификата. + + IMPORT_RES <count> <no_user_id> <imported> <imported_rsa> <unchanged> + <n_uids> <n_subk> <n_sigs> <n_revoc> <sec_read> <sec_imported> <sec_dups> <not_imported> + Final statistics on import process (this is one long line) + Окончательная статистика процесса импорта (одной длинной строкой) + + FILE_START <what> <filename> + Start processing a file <filename>. <what> indicates the performed + operation: + 1 - verify + 2 - encrypt + 3 - decrypt + Начало обработки файла <filename>. <what> выполняемая операция: + 1 - проверка. + 2 - шифрование. + 3 - расшифрование. + + FILE_DONE + Marks the end of a file processing which has been started + by FILE_START. + Означает окончание обработки файла, которая обозначалась FILE_START. + + BEGIN_DECRYPTION + END_DECRYPTION + Mark the start and end of the actual decryption process. These + are also emitted when in --list-only mode. + Означает начало и конец текущего процесса расшифрования. Это также + выдается в --list-only режиме. + + BEGIN_ENCRYPTION <mdc_method> <sym_algo> + END_ENCRYPTION + Mark the start and end of the actual encryption process. + Означает начало и конец текущего процесса шифрования. + + DELETE_PROBLEM reason_code + Deleting a key failed. Reason codes are: + 1 - No such key + 2 - Must delete secret key first + 3 - Ambigious specification + Сбой удаления. <reason_code>: + 1 - нет такого ключа. + 2 - Сперва надо удалить секретный ключ. + 3 - двусмысленное задание. + + PROGRESS what char cur total + Used by the primegen and Public key functions to indicate progress. + "char" is the character displayed with no --status-fd enabled, with + the linefeed replaced by an 'X'. "cur" is the current amount + done and "total" is amount to be done; a "total" of 0 indicates that + the total amount is not known. 100/100 may be used to detect the + end of operation. + Используется при создании главного ключа и функций с открытым ключом + для обозначения процесса. "char" символ отображаемый при не заданной + --status-fs, с переводом строки замененным на 'X'. "cur" текущая + степень выполнения и "total" всего выполнить; 0 в "total" означает, + что общее число не известно. 100/100 может использоваться для + определения конца операции. + + SIG_CREATED <type> <pubkey algo> <hash algo> <class> <timestamp> <key fpr> + A signature has been created using these parameters. + type: 'D' = detached + 'C' = cleartext + 'S' = standard + (only the first character should be checked) + class: 2 hex digits with the signature class + Подпись создана с использованием данных параметров. + <type>: 'D' = отделенная. + 'C' = прозрачная подпись. + 'S' = стандартная. + (только первый символ следует проверять) + <class>: две шестнадцатеричные цифры класса подписи. + + KEY_CREATED <type> <fingerprint> + A key has been created + type: 'B' = primary and subkey + 'P' = primary + 'S' = subkey + The fingerprint is one of the primary key for type B and P and + the one of the subkey for S. + Ключ был создан: + <type>: 'B' = главный ключ и подключ. + 'P' = главный ключ. + 'S' = подключ. + <fingerprint> отпечаток главного ключа для типов B и P либо отпечаток + подключа для типа S. + + SESSION_KEY <algo>:<hexdigits> + The session key used to decrypt the message. This message will + only be emmited when the special option --show-session-key + is used. The format is suitable to be passed to the option + --override-session-key + Сесионный ключ использованный для расшифрования сообщения. Это + сообщение выдается только при задании опции --show-session-key. + Формат пригодный для использования в --override-session-key. + + NOTATION_NAME <name> + NOTATION_DATA <string> + name and string are %XX escaped; the data may be splitted + among several notation_data lines. + <name> и <string> %XX кодировка; данные могут быть разделены + на несколько NOTATION_DATA строк. + + USERID_HINT <long main keyid> <string> + Give a hint about the user ID for a certain keyID. + Дается как подсказка о User ID для KeyID. + + POLICY_URL <string> + string is %XX escaped + строка в %XX кодировке. + + BEGIN_STREAM + END_STREAM + Issued by pipemode. + Выдается при использовании каналов (pipemode). + + INV_RECP <reason> <requested_recipient> + Issued for each unusable recipient. The reasons codes + currently in use are: + 0 := "No specific reason given". + 1 := "Not Found" + 2 := "Ambigious specification" + 3 := "Wrong key usage" + 4 := "Key revoked" + 5 := "Key expired" + 6 := "No CRL known" + 7 := "CRL too old" + 8 := "Policy mismatch" + 9 := "Not a secret key" + 10 := "Key not trusted" + + Note that this status is also used for gpgsm's SIGNER command + where it relates to signer's of course. + Выдается на каждого недопустимого получателя. + <reason>: + 0 := Нет особых признаков; + 1 := Не найден; + 2 := Двусмысленное задание; + 3 := Неправильно использованный ключ; + 4 := Ключ отозван; + 5 := Ключ просрочен; + 6 := Неизвестный CRL; + 7 := CRL слишком старый; + 8 := Несоответствует правилам (Policy mismatch); + 9 := Нет секретного ключа; + 10 := Ключ не доверенный. + Учтите, что данный статус также используется в gpgsm командой SIGNER, + где ссылается на подписавшего (to signer's of course). + + NO_RECP <reserved> + Issued when no recipients are usable. + Выдается когда не задан получатель. + + ALREADY_SIGNED <long-keyid> + Warning: This is experimental and might be removed at any time. + Внимание: Это экспериментальное и может быть удалено. + + TRUNCATED <maxno> + The output was truncated to MAXNO items. This status code is issued + for certain external requests + Вывод обреза до <maxno> пунктов. Выдается для некоторых внешних + запросов. + + ERROR <error location> <error code> + This is a generic error status message, it might be followed + by error location specific data. <error token> and + <error_location> should not contain a space. + Это общий формат ошибки и может следствием ошибки расположения + некторых данных. <error_token> и <error_location> не должны содержать + пробелов. + + ATTRIBUTE <fpr> <octets> <type> <index> <count> + <timestamp> <expiredate> <flags> + This is one long line issued for each attribute subpacket when + an attribute packet is seen during key listing. <fpr> is the + fingerprint of the key. <octets> is the length of the + attribute subpacket. <type> is the attribute type + (1==image). <index>/<count> indicates that this is the Nth + indexed subpacket of count total subpackets in this attribute + packet. <timestamp> and <expiredate> are from the + self-signature on the attribute packet. If the attribute + packet does not have a valid self-signature, then the + timestamp is 0. <flags> are a bitwise OR of: + 0x01 = this attribute packet is a primary uid + 0x02 = this attribute packet is revoked + 0x04 = this attribute packet is expired + Это одна длинная строка выдаваемая для каждого атрибута подпакета, + когда атрибут пакета просматривается в процессе просмотра ключей. + <fpr> отпечаток ключа. <octets> длина атрибута подпакета. + <type> атрибут типа (1==image). <index>/<count> показывают, что это + N-ный подпакет из общего количества подпакетов в данном пакете + атрибутов. <timestamp> и <expiredate> берутся из самоподписи на + пакете атрибута. Если пакет атрибута не имеет правильной самоподписи, + тогда <timestamp>=0. + <flags> объединенные логическим ИЛИ: + 0x01 = данный пакет атрибута - главный User ID; + 0x02 = данный пакет атрибута - отозван; + 0x03 = данный пакет атрибута - просрочен. + + +Формат вывода параметра "--attribute-fd" +======================================== + +When --attribute-fd is set, during key listings (--list-keys, +--list-secret-keys) GnuPG dumps each attribute packet to the file +descriptor specified. --attribute-fd is intended for use with +--status-fd as part of the required information is carried on the +ATTRIBUTE status tag (see above). +Когда установлен --attribute-fd, в процессе вывода списка ключей +(--list-keys, --list-secret-keys) GnuPG выводит для каждого пакета атрибут +в файл заданный дескриптором. --attribute-fd предназначен для +использования с --status-fd как часть необходимой информации +дополняемой тегом ATTRIBUTE (см. выше). + +The contents of the attribute data is specified by 2440bis, but for +convenience, here is the Photo ID format, as it is currently the only +attribute defined: +Содержимое данных атрибута соответствует 2440bis, но для удобства, +здесь показан Фото ID формат, т.к. это единственный определенный +в настоящее время атрибут: + + Byte 0-1: The length of the image header. Due to a historical + accident (i.e. oops!) back in the NAI PGP days, this is + a little-endian number. Currently 16 (0x10 0x00). + Длина заголовка изображения. По историческим причинам + (со времен NAI PGP) это число с обратным порядком байтов. + В настоящее время 16 (т.е. 0x10 0x00). + + Byte 2: The image header version. Currently 0x01. + Версия заголовка изображения. Сейчас 0x01. + + Byte 3: Encoding format. 0x01 == JPEG. + Формат. 0x01 == JPEG. + + Byte 4-15: Reserved, and currently unused. + Зарезервировано. Пока не используется. + + All other data after this header is raw image (JPEG) data. + Все последующие данные являются данными изображения в формате JPEG. + + +Создание ключей +=============== + Key generation shows progress by printing different characters to + stderr: + Процедура генерации ключей выдает последовательность из следующих символов + в поток stderr: + "." Last 10 Miller-Rabin tests failed + Последние 10 тестов Миллера-Рабина не пройдены + "+" Miller-Rabin test succeeded + Успешный тест Миллера-Рабина + "!" Reloading the pool with fresh prime numbers + Перезагрузка пула свежими простыми числами + "^" Checking a new value for the generator + Проверка нового значения для генератора + "<" Size of one factor decreased + Размер одного множителя уменьшен + ">" Size of one factor increased + Размер одного множителя увеличен + + The prime number for ElGamal is generated this way: + Простое число для ключа ElGamal создается следующим образом: + + 1) Make a prime number q of 160, 200, 240 bits (depending on the keysize) + Создается простое число q из 160, 200, 240 бит (основываясь на размере +ключа) + 2) Select the length of the other prime factors to be at least the size + of q and calculate the number of prime factors needed + Выбирается длина других простых множителей, как минимум равных размеру q + и вычисляется число необходимых простых множителей + 3) Make a pool of prime numbers, each of the length determined in step 2 + Создается пул простых чисел, каждое длиной определенной в п.2 + 4) Get a new permutation out of the pool or continue with step 3 + if we have tested all permutations. + Получаем новый перестановкой пула или продолжаем с п.3 + если провериди уже все перестановки. + 5) Calculate a candidate prime p = 2 * q * p[1] * ... * p[n] + 1 + Вычисляется кандидат простого числа p=2 * q * p[1] * ... * p[n] + 1 + 6) Check that this prime has the correct length (this may change q if + it seems not to be possible to make a prime of the desired length) + Проверяется, что данное простое число имеет правильную длину (это может + изменить q, если невозможно получить простое число необходимой длины) + 7) Check whether this is a prime using trial divisions and the + Miller-Rabin test. + Проверяется, что найденное число является простым числом попыткой + проверочных делений и с помощью теста Миллера-Рабина + 8) Continue with step 4 if we did not find a prime in step 7. + Возврат к п.4, если число в п.7 не является простым. + 9) Find a generator for that prime. + Поиск числа-генератора для данного простого числа. + + This algorithm is based on Lim and Lee's suggestion from the + Crypto '97 proceedings p. 260. + Данный алгоритм основан на предложениях Lim и Lee. + (Доклады Crupto '97 стр. 260) + +Unattended key generation +Автоматическое создание ключа +============================= +This feature allows unattended generation of keys controlled by a +parameter file. To use this feature, you use --gen-key together with +--batch and feed the parameters either from stdin or from a file given +on the commandline. +Данная возможность позволяет Вам создавать ключи в автоматическом режиме +контролируемом файлом параметров. Для использовния данной возможности +следует использовать --gen-key вместе с --batch и передать параметры +через stdin или из файла заданного в командной строке. + +The format of this file is as follows: +Формат файла следующий: + o Text only, line length is limited to about 1000 chars. + Только текст, длина строки ограничена около 1000 символов. + o You must use UTF-8 encoding to specify non-ascii characters. + Вы должны использовать UTF-8 для не ASCII символов. + o Empty lines are ignored. + Пустые строки игнорируются + o Leading and trailing spaces are ignored. + Лидирующие и концевые пробелы игнорируются + o A hash sign as the first non white space character indicates a comment line. + Знак решетки, как первый непустой симовол в строке, начинает комментарий + o Control statements are indicated by a leading percent sign, the + arguments are separated by white space from the keyword. + Управляющие операторы предваряются символом процента, аргументы + отделяются пробелом от ключевых слов. + o Parameters are specified by a keyword, followed by a colon. Arguments + are separated by white space. + Параметры задаются ключевым словом с двоеточием. Аргументы + отделяются пробелом. + o The first parameter must be "Key-Type", control statements + may be placed anywhere. + Первый параметр должен быть "Key-Type", управлящие операторы могут + распологаться в любом месте + o Key generation takes place when either the end of the parameter file + is reached, the next "Key-Type" parameter is encountered or at the + control statement "%commit" + Генерация ключа начинается с места, где или заканчивается файл + параметров, или при обнаружении следующего "Key-Type", + или управляющий оператор "%commit" + o Control statements: + Управляющие операторы + %echo <text> + Print <text>. + Вывести <text>. + %dry-run + Suppress actual key generation (useful for syntax checking). + Производит только имитацию процесса (полезно для проверки синтаксиса). + %commit + Perform the key generation. An implicit commit is done + at the next "Key-Type" parameter. + Произвести генерацию ключа. Выполнится также при встрече + следующего параметра "Key-Type". + %pubring <filename> + %secring <filename> + Do not write the key to the default or commandline given + keyring but to <filename>. This must be given before the first + commit to take place, duplicate specification of the same filename + is ignored, the last filename before a commit is used. + The filename is used until a new filename is used (at commit points) + and all keys are written to that file. If a new filename is given, + this file is created (and overwrites an existing one). + Both control statements must be given. + Не сохранять ключ в таблицу ключей по умолчанию или заданную + командной строкой, а сохранять в <filename>. Должно быть + задано до места начала генерации ключа (см.выше). Используется + только последнее втреченное значение для каждого генерируемого ключа. + Если файл новый, он создается (перезаписывается). + Должный быть заданы оба этих управляющих оператора. + o The order of the parameters does not matter except for "Key-Type" + which must be the first parameter. The parameters are only for the + generated keyblock and parameters from previous key generations are not + used. Some syntactically checks may be performed. + Порядок параметров не имеет значения, за исключением "Key-Type", + который должен быть первым. Параметры действуют только на генерируемый + блок ключей и параметры из предыдущей генерации не используются. + Может производиться частичная проверка синтаксиса. + The currently defined parameters are: + На данный момент определены следующие параметры: + Key-Type: <algo-number>|<algo-string> + Starts a new parameter block by giving the type of the + primary key. The algorithm must be capable of signing. + This is a required parameter. + Начинает новый блок параметров, задавая тип главного ключа. + Алгоритм должен поддерживать подпись. + Это необходимый параметр. + Key-Length: <length-in-bits> + Length of the key in bits. Default is 1024. + Длина ключа в битах. По умолчанию 1024. + Key-Usage: <usage-list> + Space or comma delimited list of key usage, allowed values are + "encrypt" and "sign". This is used to generate the key flags. + Please make sure that the algorithm is capable of this usage. + Список применений ключа разделенный пробелом или двоеточием. + Допустимые значения "encrypt" и "sign". Используются для + создания флагов ключа. Не забудьте, что алгоритм должен + поддерживать такое применение. + Subkey-Type: <algo-number>|<algo-string> + This generates a secondary key. Currently only one subkey + can be handled. + Создание вторичного подключа. Пока только один подключ + может быть создан. + Subkey-Length: <length-in-bits> + Length of the subkey in bits. Default is 1024. + Длина подключа в битах. По умолчанию 1024. + Subkey-Usage: <usage-list> + Similar to Key-Usage. + Аналогично "Key-Usage". + Passphrase: <string> + If you want to specify a passphrase for the secret key, + enter it here. Default is not to use any passphrase. + Если Вы задать пароль для секретного ключа, введите его здесь. + По умолчанию пароль не используется. + Name-Real: <string> + Name-Comment: <string> + Name-Email: <string> + The 3 parts of a key. Remember to use UTF-8 here. + If you don't give any of them, no user ID is created. + Три части ключа. Используйте UTF-8! + Если задан ни один из них, то User ID не создается. + Expire-Date: <iso-date>|(<number>[d|w|m|y]) + Set the expiration date for the key (and the subkey). It + may either be entered in ISO date format (2000-08-15) or as + number of days, weeks, month or years. Without a letter days + are assumed. + Установить срок действия ключа (и подключа). Может быть задано + или датой в ISO формате (ГГГГ-ММ-ДД), или как число дней, недель, + месяцев или лет. Без буквы считается, что указано дней. + Preferences: <string> + Set the cipher, hash, and compression preference values for + this key. This expects the same type of string as "setpref" + in the --edit menu. + Установить предпочтения шифрования, хэша и сжатия для + данного ключа. Теже значения, что и в "setpref" в --edit. + Revoker: <algo>:<fpr> [sensitive] + Add a designated revoker to the generated key. Algo is the + public key algorithm of the designated revoker (i.e. RSA=1, + DSA=17, etc.) Fpr is the fingerprint of the designated + revoker. The optional "sensitive" flag marks the designated + revoker as sensitive information. Only v4 keys may be + designated revokers. + Добавить к создаваемому ключу - ключ назначенный отзывающим. + <algo> - алгоритм шифрования с открытым ключом из ключа + назначенного отзывающим (например RSA=1, DSA=17 и т.д.). + <fpr> - отпечаток ключа назначаемого отзывающим. + Необязательное <sensitive> помечает отзывающий ключ, + как несущий важную (неэкспортируемую) информацию. + Только ключи v4 могут быть назначены отзывающими. + +Пример: +$ cat >foo <<EOF + %echo Создаем стандартный ключ + Key-Type: DSA + Key-Length: 1024 + Subkey-Type: ELG-E + Subkey-Length: 1024 + Name-Real: Joe Tester + Name-Comment: с дурацким паролем + Name-Email: [email protected] + Expire-Date: 0 + Passphrase: abc + %pubring foo.pub + %secring foo.sec + # Здесь начинаем создание и поэтому мы сможем затем выдать "выполнено" :-) + %commit + %echo выполнено +EOF +$ gpg --batch --gen-key foo + [...] +$ gpg --no-default-keyring --secret-keyring ./foo.sec \ + --keyring ./foo.pub --list-secret-keys +/home/wk/work/gnupg-stable/scratch/foo.sec +------------------------------------------ +sec 1024D/915A878D 2000-03-09 Joe Tester (с дурацким паролем) <[email protected]> +ssb 1024g/8F70E2C0 2000-03-09 + + + +Layout of the TrustDB +Устройство таблицы доверий TrustDB +================================== +The TrustDB is built from fixed length records, where the first byte +describes the record type. All numeric values are stored in network +byte order. The length of each record is 40 bytes. The first record of +the DB is always of type 1 and this is the only record of this type. +Таблица TrustDB состоит из записей фиксированной длины и первый байт +каждой записи указывает ее тип. Все численнык значения хранятся в +последовательном байтовом порядке (network byte order). +Длина каждой записи равна 40 байт. Первая запись всегда имеет +тип 1 и только этот тип! + + +FIXME: The layout changed, document it here. + + Тип записи 0: + ------------- + Unused record, can be reused for any purpose. + Неиспользуемая запись, можно использовать заново для любых целей. + + Тип записи 1: + ------------- + Информация о версии таблицы TrustDB. Это всегда первая запись в таблице + и только с типом 1. + 1 байт Содержит 1 + 3 байта волшебное слово 'gpg' + 1 байт Версия таблицы TrustDB (2) + 1 байт marginals needed + 1 байт completes needed + 1 байт max_cert_depth + The three items are used to check whether the cached + validity value from the dir record can be used. + Эти три параметра используются длфя проверки того, + что закешированное значение из dir записи можно использовать. + 1 u32 locked flags + флаги блокировок + 1 u32 отметка времени создания таблицы TrustDB + 1 u32 timestamp of last modification which may affect the validity + of keys in the trustdb. This value is checked against the + validity timestamp in the dir records. + отметка времени последней модификации таблицы, которая могла + затронуть действительность ключей в таблице TrustDB. + 1 u32 timestamp of last validation + (Used to keep track of the time, when this TrustDB was checked + against the pubring) + отметка о времени последней ревизии доверий + (Используется для хранения связи со временем, когда таблица + была проверена относительно таблицы открытых ключей) + 1 u32 record number of keyhashtable + номер записи keyhashtable + 1 u32 first free record + первая свободная запись + 1 u32 record number of shadow directory hash table + It does not make sense to combine this table with the key table + because the keyid is not in every case a part of the fingerprint. + номер записи теневого каталога таблицы хешей. + + 1 u32 record number of the trusthashtbale + номер записи trusthashtable + + + Тип записи 2: (запись каталога) (directory record) + ------------- + Informations about a public key certificate. + These are static values which are never changed without user interaction. + Информация о сертификате публичного ключа. + Это постоянное значение, которое не изменяется без участия пользователя. + + 1 байт значение 2 + 1 байт зарезервирован + 1 u32 LID. (This is simply the record number of this record.) + LID. (Уникальный внутренний идентификатор для записей данного типа) + 1 u32 List of key-records (the first one is the primary key) + Список записей о ключах (первый - для главного ключа) + 1 u32 List of uid-records -- Список записей о UID + 1 u32 cache record -- запись кеша + 1 байт ownertrust -- доверие владельцу + 1 байт dirflag + 1 байт maximum validity of all the user ids + максимальная достоверность для всех User ID + 1 u32 time of last validity check. + отметка времени послдней проверки действительности + 1 u32 Must check when this time has been reached. + (0 = no check required) + Нужно проверить, когда данная отметка времени устареет + (0 - ничего проверять не требуется) + + Тип записи 3: (запись о ключе) (key record) + ------------- + Informations about a primary public key. + (This is mainly used to lookup a trust record) + + 1 байт значение 3 + 1 байт зарезервирован + 1 u32 LID + 1 u32 следующая запись о ключе + 7 байт зарезервированы + 1 байт keyflags + 1 байт алогитм шифрования открытым ключом + 1 байт length of the fingerprint (in bytes) + длина отпечатка в байтах + 20 байт fingerprint of the public key + (This is the value we use to identify a key) + отпечаток открытого ключа + (Значение, которое мы используем для идентификации ключа) + + Тип записи 4: (запись о UID) (uid record) + ------------- + Informations about a userid + We do not store the userid but the hash value of the userid because that + is sufficient. + Информация о User ID + Мы не храним User ID, но используем хеш значение User ID, + т.к. этого достаточно. + + 1 байт значение 4 + 1 байт зарезервирован + 1 u32 LID + 1 u32 следующая запись о User ID + 1 u32 указатель на запись со списком предпочтений + 1 u32 siglist list of valid signatures + siglist список действительных подписей + 1 байт uidflags + 1 байт validity of the key calculated over this user id + действительность ключа вычисленного для данного User ID + 20 байт ripemd160 хеш данного User ID + + Тип записи 5: (запись о предпочтениях) (pref record) + ------------- + This record type is not anymore used. + Данная запись не используется где-либо + + 1 байт значение 5 + 1 байт зарезервирован + 1 u32 LID; points to the directory record (and not to the uid record!). + (or 0 for standard preference record) + LID; указывает на запись каталога (не на UID запись!). + (0 для записи стандартных предпочтений) + 1 u32 следующая запись о предпочтениях + 30 байт данные о предпочтениях + + Тип записи 6 (sigrec) + ------------ + Used to keep track of key signatures. Self-signatures are not + stored. If a public key is not in the DB, the signature points to + a shadow dir record, which in turn has a list of records which + might be interested in this key (and the signature record here + is one). + Используется для хранения пути подписей ключа. Самоподписи + не хранятся. Если открытого ключа нет в таблице, то подпись + ссылается на запись теневого каталога, где имеется список записей, + которые возможно интересны для данного ключа (и данная запись тоже) + + 1 байт значение 6 + 1 байт зарезервирован + 1 u32 LID. указатель на запись каталога + 1 u32 next next sigrec of this uid or 0 to indicate the last sigrec. + следующая sigrec данного UID или 0 для последней sigrec. + 6 раз + 1 u32 Local_id of signatures dir or shadow dir record + Local_ID каталога подписей или записи теневого каталога + 1 byte Флаг: Бит 0 = checked: Bit 1 is valid (we have a real + directory record for this) + проверено: Бит 1 действителен (мы имеем + запись каталога для данного ID) + 1 = valid is set (but may be revoked) + действительность установлена (но возможно отозван)? + + + Тип записи 8: (запись теневого каталога) (shadow directory record) + ------------- + This record is used to reserve a LID for a public key. We + need this to create the sig records of other keys, even if we + do not yet have the public key of the signature. + This record (the record number to be more precise) will be reused + as the dir record when we import the real public key. + Данная запись используется, чтобы зарезервировать LID для + открытого ключа. Нам это необходимо для создания sigrec других + ключей, даже если мы не имеем пока открытого ключа подписи. + Данная запись (точнее номер записи) будет затем использована, + как запись каталога, когда мы импортируем открытый ключ. + + 1 байт значение + 1 байт зарезервирован + 1 u32 LID + 2 u32 keyid + 1 байт алгоритм шифрования открытым ключом + 3 байт зарезервированы + 1 u32 hintlist A list of records which have references to + this key. This is used for fast access to + signature records which are not yet checked. + Note, that this is only a hint and the actual records + may not anymore hold signature records for that key + but that the code cares about this. + Список записей, которые ссылаются на данный ключ. + Используется для быстрого доступа к записям sigrec, + которые еще не проверены. + Заметьте, что на самом деле записи, указанные в + списке, могут уже не содержать sigrec для данного + ключа, но об этом позаботится? + 18 byte зарезервированы + + + + Тип записи 10 (таблица хешей) (hash table) + ------------- + Due to the fact that we use fingerprints to lookup keys, we can + implement quick access by some simple hash methods, and avoid + the overhead of gdbm. A property of fingerprints is that they can be + used directly as hash values. (They can be considered as strong + random numbers.) + What we use is a dynamic multilevel architecture, which combines + hashtables, record lists, and linked lists. + В следствие того, что мы используем отпечатки ключей для их поиска, + мы можем реализовать быстрый доступ простыми хеш методами и избежать + перегрузки gdbm. Особенность отпечатков + ключей то, что они сами могут быть использованы непосредственно, + как хеш-значения. (Их можно рассматривать, как *сильные* числа). + Мы используем динамическую многоуровневую архитектуру, которая + совмещает таблицы хешей, списки записей и списки ссылок. + + This record is a hashtable of 256 entries; a special property + is that all these records are stored consecutively to make one + big table. The hash value is simple the 1st, 2nd, ... byte of + the fingerprint (depending on the indirection level). + Данная запись - таблица хешей из 256 записей; особенность + в том, что все эти записи хранятся последовательно для получения + одной большой таблицы. Значение хеша это просто 1-й, 2-й, ... байты + отпечатка (основываясь на indirection level) + + When used to hash shadow directory records, a different table is used + and indexed by the keyid. + Когда используется записи каталога теневых хешей, другая таблица + используется и индексируется по KeyID. + + 1 байт значение 10 + 1 байт зарезервирован + n u32 recnum; n depends on the record length: + n = (reclen-2)/4 which yields 9 for the current record length + of 40 bytes. + recnum; n вычисляется на основе длины записи: + n = (reclen-2)/4 которое равно 9 для текущей длины записи в 40 байт. + + the total number of such record which makes up the table is: + m = (256+n-1) / n + which is 29 for a record length of 40. + общее число таких записей из которых состоит таблица: + m = (256+n-1) / n + которое равняется 29 для текущей длины в 40 байт. + + To look up a key we use the first byte of the fingerprint to get + the recnum from this hashtable and look up the addressed record: + - If this record is another hashtable, we use 2nd byte + to index this hash table and so on. + - if this record is a hashlist, we walk all entries + until we found one a matching one. + - if this record is a key record, we compare the + fingerprint and to decide whether it is the requested key; + Для поиска ключа мы используем первый байт отпечатка для получения recnum + из данной таблицы хешей и ищем адресуемую запись: + - Если данная запись - другая таблица, мы используем второй байт как + индекс в данной хеш таблице и т.д. + - если данная запись - список хешей, мы просматриваем весь список, + до тех пор, пока мы не найдем соотвествие. + - если данная запись - запись ключа, мы сравниваем отпечаток и решаем + является ли данный ключ искомым. + + + Тип записи 11 (список хешей) (hash list) + ------------- + см. таблицу хешей для разъяснений. + Это также используется и для других целей. + + 1 байт значение 11 + 1 байт зарезервирован + 1 u32 следующий следующая запись хеш списка + n раз n = (reclen-5)/5 + 1 u32 recnum + + Для используемой в настоящее время длины записи в 40 байт, n = 7. + + + + Тип записи 254 (свободная запись) (free record) + -------------- + All these records form a linked list of unused records. + Все эти записи являются неиспользуемыми. + 1 байт значение 254 + 1 байт зарезервирован (0) + 1 u32 следующая свободная + + + +Packet Headers +Заголовки пакета +================ + +GNUPG uses PGP 2 packet headers and also understands OpenPGP packet header. +There is one enhancement used with the old style packet headers: +GnuPG использует PGP 2 заголовки пакета и понимает также заголовок OpenPGP +пакета. Со старым стилем заголовков пакета используется одно расширение: + + CTB bits 10, the "packet-length length bits", have values listed in + the following table: + CTB биты 10, биты длины "packet-length", имеют ниже описанные значения: + + 00 - 1-byte packet-length field + 01 - 2-byte packet-length field + 10 - 4-byte packet-length field + 11 - no packet length supplied, unknown packet length + 00 - 1-байтовое поле packet-length + 01 - 2-байтовое поле packet-length + 10 - 4-байтовое поле packet-length + 11 - не указана длина пакета, неизвестная длина пакета. + + As indicated in this table, depending on the packet-length length + bits, the remaining 1, 2, 4, or 0 bytes of the packet structure field + are a "packet-length field". The packet-length field is a whole + number field. The value of the packet-length field is defined to be + the value of the whole number field. + Как показано в таблице, в зависимости от битов длины packet-lenght, + оставшиеся 1, 2, 4 или 0 байт поля структуры пакета + это поле "packed-length". Поле packed-length - целочисленное поле. + Значение поля packet-length должно быть целочисленным значением + числа полей. + + A value of 11 is currently used in one place: on compressed data. + That is, a compressed data block currently looks like <A3 01 . . .>, + where <A3>, binary 10 1000 11, is an indefinite-length packet. The + proper interpretation is "until the end of the enclosing structure", + although it should never appear outermost (where the enclosing + structure is a file). + Значение 11 в настоящее время используется в одном месте: сжатые данные. + Сжатые данные в настоящее время выглядят примерно так <A3 01 . . .>, + где <A3> есть двоичное <10 1000 11>, т.е. пакет неопределенной длины. + Правильная интерпретация "до завершения вложенной структуры", + хотя она и не является истиной в последней инстанции + (где вложенная структура - файл). + ++ This will be changed with another version, where the new meaning of ++ the value 11 (see below) will also take place. ++ Это будет изменео в другой версии, где новый смысл значения 11 (см. ниже) ++ будет иметь место. ++ ++ A value of 11 for other packets enables a special length encoding, ++ which is used in case, where the length of the following packet can ++ not be determined prior to writing the packet; especially this will ++ be used if large amounts of data are processed in filter mode. ++ Значение 11 для других пакетов позволяет особое кодирование длины, ++ используемое в тех случаях, когда невозможно определить длину ++ следующего пакета до записи пакета; это особенно будет использоваться при ++ обработке большого объема данных через фильтр. ++ ++ It works like this: After the CTB (with a length field of 11) a ++ marker field is used, which gives the length of the following datablock. ++ This is a simple 2 byte field (MSB first) containing the amount of data ++ following this field, not including this length field. After this datablock ++ another length field follows, which gives the size of the next datablock. ++ A value of 0 indicates the end of the packet. The maximum size of a ++ data block is limited to 65534, thereby reserving a value of 0xffff for ++ future extensions. These length markers must be inserted into the data ++ stream just before writing the data out. ++ Это работает так: После CTB (с полем длины 11) используется поле маркера, ++ которое дает длину последующего блока данных. Это простое двухбайтовое поле ++ (сперва MSB) содержащее объем данных следующих за этим полем, не включая ++ размер самого поля. После блока данных следует другое поле длины, которое ++ дает объем следующего блока данных. Значение 0 указывает на конец пакета. ++ Максимальный размер блока данных ограничен 65534, этим резервируется ++ значение 0xFFFF для будущих расширений. Эти маркеры длины должны быть ++ внедрены в поток данных непосредственно перед записью этих данных. ++ ++ This 2 byte field is large enough, because the application must buffer ++ this amount of data to prepend the length marker before writing it out. ++ Data block sizes larger than about 32k doesn't make any sense. Note ++ that this may also be used for compressed data streams, but we must use ++ another packet version to tell the application that it can not assume, ++ that this is the last packet. ++ Это двухбайтовое поле достаточно большое потому, что приложение должно ++ иметь буффер данного размера для хранения данных перед их выводом. Блоки ++ данных больше 32К не имеет смысла делать. Учтите, что это может также ++ использоваться для потоков сжатых данных, но мы должны пользоваться другой ++ версией пакета, что бы указать приложению, что нельзя предполагать, что ++ это последний пакет. + +GNU extensions to the S2K algorithm +GNU расширения в S2K алгоритме +============================== +S2K mode 101 is used to identify these extensions. +After the hash algorithm the 3 bytes "GNU" are used to make +clear that these are extensions for GNU, the next bytes gives the +GNU protection mode - 1000. Defined modes are: +S2K режим 101 импользован для идентификации данных расширений. +После хеш алгоритма 3 байта "GNU" используются, что бы дать понять, что данные +расширения для GNU, следующие байты дают режим защиты GNU - 1000. +Определены следующие режимы: + 1001 - do not store the secret part at all + 1001 - не хранить секретную часть совсем + 1002 - a stub to access smartcards (not used in 1.2.x) + 1002 - корешок для доступа смарткарт (не используется в 1.2.x) + + +Pipemode +Каналы +====== +NOTE: This is deprecated and will be removed in future versions. +ЗАМЕЧАНИЕ: Это устарело и будет удалено в следующих версиях. + +This mode can be used to perform multiple operations with one call to +gpg. It comes handy in cases where you have to verify a lot of +signatures. Currently we support only detached signatures. This mode +is a kludge to avoid running gpg n daemon mode and using Unix Domain +Sockets to pass the data to it. There is no easy portable way to do +this under Windows, so we use plain old pipes which do work well under +Windows. Because there is no way to signal multiple EOFs in a pipe we +have to embed control commands in the data stream: We distinguish +between a data state and a control state. Initially the system is in +data state but it won't accept any data. Instead it waits for +transition to control state which is done by sending a single '@' +character. While in control state the control command os expected and +this command is just a single byte after which the system falls back +to data state (but does not necesary accept data now). The simplest +control command is a '@' which just inserts this character into the +data stream. + +Here is the format we use for detached signatures: +"@<" - Begin of new stream +"@B" - Detached signature follows. + This emits a control packet (1,'B') +<detached_signature> +"@t" - Signed text follows. + This emits the control packet (2, 'B') +<signed_text> +"@." - End of operation. The final control packet forces signature + verification +"@>" - End of stream + + + + + + +Other Notes +Другие замечания +================ + * For packet version 3 we calculate the keyids this way: + * Для пакета 3 версии мы вычисляем keyid-ы таким методом: + RSA := low 64 bits of n + нижние 64 бита n + ELGAMAL := build a v3 pubkey packet (with CTB 0x99) and calculate + a rmd160 hash value from it. This is used as the + fingerprint and the low 64 bits are the keyid. + создать v3 пакет открытого ключа (с CTB 0x99) и + вычислить rmd160 значение хеша из него. Это используется + как отпечаток и нижние 64 бита используются как KeyId. + + * Revocation certificates consist only of the signature packet; + "import" knows how to handle this. The rationale behind it is + to keep them small. + Сертификаты отзыва включают только пакет подписи; "import" знает + как это обрабатывать. Целесообразно сохранять размер сертификатов + небольшим. + + + +Keyserver Message Format +Формат сообщений сервера ключей +=============================== + +The keyserver may be contacted by a Unix Domain socket or via TCP. +Соединение с сервером ключей может производится через Unix Domain сокет или +посредством TCP. +The format of a request is: +Формат запроса следующий: + +==== +command-tag +Команда +"Content-length:" digits +CRLF +======= + +Where command-tag is +Где "Команда": + +NOOP +GET <user-name> +PUT +DELETE <user-name> + + +The format of a response is: +Формат ответа: + +====== +"GNUPG/1.0" status-code status-text +"Content-length:" digits +CRLF +============ +followed by <digits> bytes of data +с последующей передачей <digits> байт данных + + +Status codes are: +Коды статуса: + + o 1xx: Informational - Request received, continuing process + Информационные - Запрос принят, процесс продолжается + + o 2xx: Success - The action was successfully received, understood, + and accepted + Успешно - Команда принята успешно, распознана и принята к + исполнению. + + o 4xx: Client Error - The request contains bad syntax or cannot be + fulfilled + Ошибка клиента - Запрос имеет неправильный синтаксис или + не может быть выполнен. + + o 5xx: Server Error - The server failed to fulfill an apparently + valid request + Ошибка сервера - Сервер дал сбой при исполнении кажущегося + правильным значением запроса. + +Documentation on HKP (the http keyserver protocol): +Описание HKP (протокол http сервера ключей): + +A minimalistic HTTP server on port 11371 recognizes a GET for /pks/lookup. +Минимальный HTTP сервер на порте 11371 понимает GET для /pks/lookup. +The standard http URL encoded query parameters are this (always key=value): +Стандартный http URL содержит параметры запроса (всегда ключ=значение) + +- op=index (like pgp -kv), op=vindex (like pgp -kvv) and op=get (like + pgp -kxa) + op=index (типа pgp -kv), op=vindex (типа pgp -kvv) и op=get (типа pgp -kxa) + +- search=<stringlist>. This is a list of words that must occur in the key. + The words are delimited with space, points, @ and so on. The delimiters + are not searched for and the order of the words doesn't matter (but see + next option). + search=<stringlist>. Это список слов, которые могжет содержать ключ. Слова + разделены пробелом, точкой, @ и т.п. Разделители не ищутся и порядок слов не + имеет значения (но см. следующий параметр). + +- exact=on. This switch tells the hkp server to only report exact matching + keys back. In this case the order and the "delimiters" are important. + exact=on. Это заставляет сервер ключей искать полные соотвествия. В данном + случае порядок слов и "разделители" важны. + +- fingerprint=on. Also reports the fingerprints when used with 'index' or + 'vindex' + fingerprint=on. Также выдавать отпечатки, когда используется с 'index' или + 'vindex'. + +The keyserver also recognizes http-POSTs to /pks/add. Use this to upload +keys. +Сервер ключей также понимает http POST к /pks/add. Это используется для +загрузки ключей на сервер. + +A better way to do this would be a request like: +Наилучший способ сделать это - воспользоваться запросом типа: + + /pks/lookup/<gnupg_formatierte_user_id>?op=<operation> + +This can be implemented using Hurd's translator mechanism. +However, I think the whole key server stuff has to be re-thought; +I have some ideas and probably create a white paper. +Это может быть реализовано с использованием механизмов транслятора Hurd. +Однако я думая, что весь материал по серверу ключей должен быть переосмыслен; +у меня имеются некторые идеи и, возможно я напишу по этому поводу отдельный +документ. diff --git a/doc/ru/faq163_ru2.raw b/doc/ru/faq163_ru2.raw new file mode 100644 index 000000000..df5e54a7f --- /dev/null +++ b/doc/ru/faq163_ru2.raw @@ -0,0 +1,1403 @@ +[$htmltitle=GnuPG FAQ] +[$htmlcharset=<meta http-equiv="content-type" content="text/html; charset=utf-8">] +[$sfaqheader=The GnuPG FAQ says:] +[$sfaqfooter= +The most recent version of the FAQ is available from +<http://www.gnupg.org/> +] +[$usenetheader= +] +[$maintainer=David D. Scribner, <faq 'at' gnupg.org>] +[$hGPGHTTP=http://www.gnupg.org] +[$hGPGFTP=ftp://ftp.gnupg.org] +[$hVERSION=1.2.2] + +[H body bgcolor=#ffffff text=#000000 link=#1f00ff alink=#ff0000 vlink=#9900dd] +[H h1]GnuPG Frequently Asked Questions[H /h1] + + +[H p] +Версия: 1.6.3[H br] +Редакция от: 30 Июля 2003[H br] +Руководитель проекта: [$maintainer] +[H br]Перевод на русский: Maxim Britov <[email protected]>, GnuPG KeyID 0x6F3DB1FB +[H br]CODEPAGE: UTF-8 +[H /p] + + +В данном документе (далее - "FAQ") Вы найдете ответы на наиболее часто +задаваемые вопросы по GnuPG. Последняя версия FAQ (английская) в формате HTML +доступна [H a href=[$hGPGHTTP]/documentation/faqs.html]здесь[H /a]. + +Содержание создано автоматически, поэтому может содержать ошибки и может +случиться, что некоторые из отвеченных ниже вопросов могут в него не попасть. +Принимаются любые предложения по усовершенствованию структуры настоящего документа. + +Все дополнения и исправления отправляйте на англ. языке руководителю проекта. +Будет правильнее, если Вы предложите и ответ на Ваш новый вопрос или укажете +и вопрос, и ответ по которым Вы имеете свои предложения. Ваша помощь будет +оценена по достоинству. + +Не следует присылать сообщения типа "Это следует поместить в FAQ - Каков ответ?". +Если вопрос не задавался ранее, видимо он не относится к часто задаваемым. +В этом случае Вам следует поискать ответ в архиве соответствующей почтовой +рассылки. + +[H hr] +<C> +[H hr] + + +<S> ОБЩЕЕ + +<Q> Что такое GnuPG? + + [H a href=[$hGPGHTTP]]GnuPG[H /a] расшифровывается как GNU Privacy Guard и + является GNU инструментом для секретных коммуникаций и хранения данных. + GnuPG может использоваться для шифрования данных и создания цифровых подписей. + GnuPG представляет собой легкое, но мощное средство управления ключами + и совместимо с предложенным OpenPGP Internet стандартом, как описано + в [H a href=http://www.rfc-editor.org/]RFC 2440[H/a]. + Также, по возможности, обеспечивается совместимость с PGP от NAI, Inc. + +<Q> GnuPG совместимо с PGP? + + В основном, да. GnuPG и новейшие версии PGP следуют стандарту OpenPGP. + Но существуют некоторые проблемы при взаимодействии. + Подробности см. в вопросе <Rcompat>. + +<Q> Свободен ли GnuPG для персонального или коммерческого использования? + + Да! GnuPG является частью инструментов и приложений GNU созданных + и распространяемых в соответствии с Free Software Foundation (FSF) + General Public License (GPL). Поэтому GnuPG свободно для копирования, + использования, изменения и распространения в соответствии с данной + лицензией. Прочитайте, пожалуйста, файл озаглавленный COPYING, который + прилагается к данной программе для получения более полной информации. + +<Q> Какие соглашения используются в данном FAQ? + + Поскольку GnuPG разрабатывается для нескольких оперционных систем + (часто параллельно), то соглашения используемые в данном FAQ отражают + окружение оболочки UNIX. Для пользователей Win32, ссылки на подсказку + командной строки ("$") следует рассматривать, как приглашение (">"), + имена каталогов разделенные прямым слешем ("/") следует разделять + обратным слешем ("\"), и тильду ("~") рассматривать, как путь к + домашнему каталогу пользователя (см. ответ на <Rhomedir> для примера). + + Некоторые командные строки в настоящем FAQ слишком длинны для правильного + отображения некоторыми браузерами в Web версии данного документа + и поэтому некоторые строки могут быть разбиты на две и более. Такие + команды следует ввести целиком - одной строкой, иначе команда будет + ошибочна и как минимум, не даст требуемого результата. + + Помните, что данный FAQ содержит информацию, которая может оказаться + не актуальной для Вашей текущей версии программы, т.к. постоянно + производятся усовершенствование программы и исправления найденных ошибок + (см. файл NEWS поставляемый вместе с исходными текстами). Один из + пунктов которого сообщает, что в GnuPG начиная с версии 1.1.92 файл + персональных параметров программы переименован из "options" в "gpg.conf". + Информация в FAQ, ссылающаяся на файл параметров "options" полностью + применима к новому файлу "gpg.conf" в большинстве случаев. + Подробнее см. в вопросе <Roptions>. + + +<S> ИСТОЧНИКИ ИНФОРМАЦИИ + +<Q> Где я могу получить больше информации о GnuPG? + + Онлайновые источники: + + [H ul] + [H li]Страница документации на [H a href=[$hGPGHTTP]/documentation/]<[$hGPGHTTP]/documentation/>[H/a]. + Также смотрите HOWTO и GNU Privacy Handbook (GPH, доступную на Английском, Испанском и Русском (Спасибо Павлу Шайдо за русский перевод)). Последнее является + подробным руководством пользователя GnuPG. Вы также найдете документ о том, + как перейти с PGP 2.x на GnuPG. + + [H li]На [H a href=[$hGPGHTTP]/documentation/mailing-lists.html]<[$hGPGHTTP]/documentation/mailing-lists.html>[H/a] + Вы найдете онлайновый архив дискуссионных списков рассылки (в т.ч. gnupg-ru). + Более интереным должен быть gnupg-users - где обсуждаются проблемы + пользовательского уровня, для русскоязычных пользователей существует + также рассылка gnupg-ru; gnupg-devel - для контактов с разработчиками. + + Дополнительно можно поискать на MARC, например: [H br] + gnupg-users: [H a href=http://marc.theaimsgroup.com/?l=gnupg-users&r=1&w=2]<http://marc.theaimsgroup.com/?l=gnupg-users&r=1&w=2>[H/a][H br] + gnupg-devel: [H a href=http://marc.theaimsgroup.com/?l=gnupg-devel&r=1&w=2]<http://marc.theaimsgroup.com/?l=gnupg-devel&r=1&w=2>[H/a][H br] + + [H b]ПОЖАЛУЙСТА:[H /b] + Перед отправкой вопроса с список рассылки, прочтите данный FAQ и доступную + докуменцию. Следует просмотреть также архив рассылки, т.к. вплне возможно, + что Ваш вопрос уже обсуждался ранее. Это поможет людям сконцентрировать + внимание на решении новых, еще не решенных вопросов. + + [H li]Пакет с исходным кодом GnuPG содержит подкаталог: + + [H samp] + ./doc + [H /samp] + + в котором Вы можете найти некоторую дополнительную информацию (интересную в + основном Хакерам, а не обычным пользователям). + [H /ul] + +<Q> Где я могу взять GnuPG? + + Вы можете скачать GNU Privacy Guard с главного FTP сервера проекта + [H a href=[$hGPGFTP]/gcrypt/]<[$hGPGFTP]/gcrypt/>[H /a] или с одного из зеркал: + + [H a href=[$hGPGHTTP]/download/mirrors.html] + <[$hGPGHTTP]/download/mirrors.html> + [H /a] + + Текущая стабильная версия GnuPG [$hVERSION]. Обновите Вашу программу до + указанной версии, т.к. она включает дополнительные функции и исправления + найденных ошибок, которые могли быть найдены в предыдущих версиях. + + +<S> УСТАНОВКА + +<Q> На каких операционных системах может работает GnuPG? + + GnuPg должен работать на большинстве Unix, а также Windows (включая + Windows NT/2000/XP) и Macintosh OS/X. Текущий список поддерживаемых + систем можно посмотреть здесь: + + [H a href=[$hGPGHTTP]/download/supported_systems.html] + <[$hGPGHTTP]/download/supported_systems.html> + [H /a] + +<Q> Какие поставщики случайных чисел мне следует использовать? + + "Хорошие" случайные числа имеют решающее значение для секретного шифрования. + Различные операционные системы предоставляют различные механизмы поставки + более или менее качественных случайных числа. Linux и *BSD поставляют + случайные числа созданные ядром посредством /dev/random - этот вариант + предпочтителен для данных систем. + Solaris с установленным SUNWski пакетом также предоставляет /dev/random. + В данном случае следует использовать параметр конфигурирования: + + [H samp] + --enable-static-rnd=linux + [H /samp] + + Также существует устройство ядра для поставки случайных чисел разработанное + Andi Maier [H a href= http://www.cosy.sbg.ac.at/~andi/SUNrand/]<http://www.cosy.sbg.ac.at/~andi/SUNrand/>[H /a], но это всё еще бета версия. + Используйте ее на свой страх и риск! + + На других системах, хорошим выбором будет Entropy Gathering Daemon (EGD). + Это perl-демон, который наблюдает за системной активностью и хеширует ее в + случайные числа. См. страницу загрузки [H a href=[$hGPGHTTP]/download/]<[$hGPGHTTP]/download/>[H /a] + для получения EGD. Используйте параметр конфигурирования: + + [H samp] + --enable-static-rnd=egd + [H /samp] + + Если указанные выше параметры не работают, можете использовать генератор + случайных чисел "unix". Но он [H B]очень[H /B] медленен и его следует + избегать. Качество поставляемых случайных чисел не очень хорошее, поэтому + им не следует пользоваться для важных данных. + +<Didea> +<Q> Как добавить поддержку RSA и IDEA? + + RSA включен в поставку GnuPG начиная с версии 1.0.3. + + Официальная поставка GnuPG не включает поддержку IDEA по причине + патентных ограничений. Патент на IDEA истечет в 2007, поэтому не ждите + официальной поддержки до этого момента. + + Однако существует неофициальный модуль поддержки IDEA для GnuPG. + Он доступен на + [H a href=ftp://ftp.gnupg.dk/pub/contrib-dk/]<ftp://ftp.gnupg.dk/pub/contrib-dk/>[H /a]. Ищите: + + [H pre] + idea.c.gz (модуль на C ) + idea.c.gz.sig (файл подписи) + [H /pre] + + [H pre] + ideadll.zip (модуль на C и win32 dll) + ideadll.zip.sig (файл подписи) + [H /pre] + + Директивы компиляции в заголовках файлов. Вам будет необходимо добавить + следующую строку в Ваш файл персональных настроек ~/.gnupg/gpg.conf: + + [H samp] + load-extension idea + [H /samp] + + +<S> ПРИМЕНЕНИЕ + +<Q> Каков рекомендуемый размер ключа? + + 1024 бита для DSA подписей; даже и для простых ElGamal подписей. + Этого достаточно, т.к. при большем рамере ключа слабейшим звеном + оказывается уже размер хеша. + Вы можете добавить ключи шифрования большего размера, но Вам следует + просмотреть отпечаток этого ключа командой: + + [H samp] + $ gpg --fingerprint <User ID> + [H /samp] + + Вам следует придерживаться стандартных алгоритмов (т.е. DSA для подписей + и ElGamal для шифрования). Ключ ElGamal для подписи невыгоден по следующим + причинам: большой размер подписей; сложно создать пригодный для подписи ключ, + который сможет противостоять настоящим атакам, Вы не получите чего-то особенно + секретного или надежного в сравнении с DSA, плюс существуют также проблемы + совместимости с некоторыми версиями PGP. + Он был предложен потому, что в то в свое время имелись проблемы + с патентами на DSA. + +<Q> Почему процесс создания ключей занимает иногда так много времени? + + Основная проблема в том, что необходимо собрать много случайных чисел + и для этого мы (в Linux - с устройства /dev/random) должны собирать + случайные числа. На самом деле трудно заполнить внутренний буфер Linux + энтропией; я говорил с Ted Ts'o и он сказал, что лучший способ заполнить + буфер это понажимать клавиши на Вашей клавиатуре. Хорошая секретность + имеет свою цену. Я нажимаю на клавиши Shift, Ctrl, Alt and CapsLock + потому, что эти клавиши не выводят что-либо на экран. И таким путем + Вы получаете ключи быстрее (это то, что делает PGP2). + + Также проблема может быть в том, что другая программа забирает данные + из Вашего генератора случайных чисел (например из /dev/random). + +<Q> И это действительно долго, когда я работаю на удаленной системе. Почему? + + Никогда не делайте этого! Вы никогда не должны создавать ключи и + даже пользоваться GnuPG на удаленной системе потому, что Вы обычно + не имеете физического контроля за Вашей таблицей секретных ключей + (которая зачастую может быть неустойчива к атакам на подбор стандартных + паролей по словарю). Я настойчиво рекомендую всем создавать ключи только + на локальном компьютере (неподключенный лаптоп возможно наилучший выбор). + А если Вы вынуждены делать это на Вашем подключенном к сети компьютере + (я знаю, все мы так делаем) будьте уверены, что используете сильный пароль + для всех Ваших аккаунтов и для секретного ключа, и что Вы можете доверять + Вашему системному администратору. + + Когда я проверял GnuPG на удаленной машине через ssh (это была не альфа);-) + я имел некоторые проблемы. Создание ключа занимамо *очень* долгое время, + так что я использовал специальный параметр --quick-random для создания + несекретных ключей, которые пригодны разве что для некоторых экспериментов. + +<Q> Каковы различия между командами и параметрами? + + Если Вы выполните 'gpg --help', то Вы получите два разных списка. + Первый - список команд, а второй - параметров. Всякий раз когда Вы + запускаете GPG, Вы [H b]должны[H /b] использовать хотя бы одну команду + (с одним исключением, см. ниже). Вы [H b]можете[H /b] использовать один + или более параметров. Команде следует, в точности по описанию, находиться + в конце списка аргуметов, после всех параметров. Если команда задает имя + файла (в основном все они это делают), имя файла должно быть в самом конце. + Базовый формат вызова gpg: + + [H samp] + $ gpg [--option что-либо] [--option2] [--option3 что-либо] --command файл + [H /samp] + + Некоторым параметрам требуются аргументы. Например параметр --output + (который можно сократить до -o) это параметр которому требуется имя файла. + Аргументы параметра должны следовать непосредственно после требующего их + параметра, иначе gpg не сможет узнать какой аргумент, какому параметру + принадлежит. Как параметр --output так и имя файла должны предшествовать + команде. Параметр --recipient (-r) задает имя или KeyID того, кому + шифруется сообщение и которые должны находиться справа от параметра -r. + Команда --encrypt (-e) должна находится после всех параметров и следовать + за файлом, который Вы хотите шифровать. Поэтому в данном примере командная + строка должна иметь следующий вид: + + [H samp] + $ gpg -r Алиса -o секрет.txt -e тест.txt + [H /samp] + + Если Вы используете полные названия параметров, читать станет легче: + + [H samp] + $ gpg --recipient Алиса --output секрет.txt --encrypt тест.txt + [H /samp] + + Если Вы шифруете файл с расширением ".txt" и Вы можете захотите + получить результат в текстовом виде ASCII-формата (не двоичном), + Вам следует воспользоваться параметром --armor (-a), который + не имеет аргументов: + + [H samp] + $ gpg --armor --recipient Алиса --output секрет.txt --encrypt тест.txt + [H /samp] + + Если предположить квадратные скобки вокруг параметров, это будет + выглядеть так: + + [H samp] + $ gpg [--armor] [--recipient Алиса] [--output секрет.txt] --encrypt тест.txt + [H /samp] + + Параметры могут следовать в произвольном порядке: + + [H samp] + $ gpg --output секрет.txt --recipient Алиса --armor --encrypt тест.txt + [H /samp] + + Если имя Вашего файла начинается с дефиса (например файл "-a.txt"), + GnuPG примет это за параметр и может сообщить об ошибке. В таких случаях + следует использовать "./-a.txt" или остановть обработку команд и параметров + двойным дефисом: "-- -a.txt". + + [H B]Исключение составляет только одна команда:[H /B] одновременное + подписывание и шифрование. Для этого Вы следует скомбинировать обе команды, + как показано ниже: + + [H samp] + $ gpg [--параметры] --sign --encrypt тест.txt + [H /samp] + +<Q> Не могу удалить User ID из связки секретных ключей потому, + что он отсутствует в связке открытых ключей. Что делать? + + Поскольку Вы можете выбрать User ID только из списка открытых ключей, + то прямого способа сделать это нет. Однако сделать это на самом деле + совсем не трудно. Создайте новый User ID с полностью идентичным именем + и увидите, что получилось два идентичных User ID в связке секретных + ключей. Теперь выберите данный User ID и удалите его. Оба User ID будут + удалены из связки секретных ключей. + +<Q> Не могу удалить секретный ключ потому, что пропал открытый ключ. + Что делать? + + Поиск ключа, для выполнения операций с ним, всегда производится по связке + открытых ключей, поэтому невозможно удалить секретный ключ не имея + открытого ключа. Обычно не должно возникать ситуаций, когда открытый ключ + потерян, а секретный ключ всё еще присутствует. Но такое случается, + поэтому в GnuPG имеется способ сделать это: просто используйте длинный + KeyID для указания удаляемого ключа, который можно получить применением + параметра --with-colons (см. 5 поле в строке начинающейся с "sec"). + + Если потерян открытый ключ и нужно взамен его создать новый для + продолжения использования секретного ключа, можно воспользоваться + утилитой gpgsplit так, как описано в вопросе <Rgpgsplit>. + +<Q> Что означают понятия доверие, достоверность и доверие владельцу? + + Ответ приведу с английским текстом, т.к. вопрос очень важен. + + В 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. + +<Q> Как подписать файл патча? + + Воспользуйтесь "gpg --clearsign --not-dash-escaped ...". Есть проблема с + --clearsign в том, что все строки начинающиеся с дефиса выделяются + как "- "; но поскольку diff создает множество строк начинающихся с дефиса, + то если они будут выделены таким образом, будет не очень хорошо для Вашего + патча ;-). + Для применения патча без удаления прозрачной подписи, можно использовать + специальный параметр --not-dash-escaped для отключения выделния таких + последовательностей. Не следует отсылать такие патчи по email потому, + что пробелы и завершители строк также являются частью подписи, а почтовик + может не сохранить их. Если Вы хотите послать файл почтой, то можно + подписать его используя Ваш MUA (Mail User Agent, т.е Почтовый агент). + +<Q> Где параметр "encrypt-to-self"? + + Используйте "--encrypt-to Ваш_KeyID". Можно использовать больше, чем одну + копию данного параметра. Временно отменить действие данного параметра + можно использованием параметра "--no-encrypt-to". + +<Q> Как избавиться от строки Version и добавить комментарий в заголовках + сообщений кодированных в ASC-формате? + + Используйте " --no-version --comment '' ". Учтите, что стандарт требует + обязательного наличия пустой строки. + +<Q> Что означает "Используется таблица символов xxxx."? + + Вы увидите данное сообщение, когда необходимо преобразование введенных + данных в 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! Хотя некоторые + программы-оболочки могут понимать (а может и нет) большее число кодировок. + +<Q> Как просмотреть список KeyID для которых зашифровано сообщение? + + [H samp] + $ gpg --batch --decrypt --list-only --status-fd 1 2>/dev/null | + awk '/^\[GNUPG:\] ENC_TO / { print $3 }' + [H /samp] + +<Q> Почему я не могу расшифровать файлы зашифрованные симметричным + шифром (-c) используя GnuPG версий ниже 1.0.1. + + Версии GnuPG ниже 1.0.1 содержали ошибку, которая проявлялась только + при использовании шифров 3DES и Twofish для симметричного шифрования + (они никогда не использовались, как шифры по умолчанию). + Ошибка исправлена, но для расшифровки таких файлов необходимо запустить + gpg с параметром " --emulate-3des-s2k-bug "; расшифровать файл и + зашифровать снова без данного параметра. + + Замечение: Данный параметр удален в GnuPG версии 1.1.0 и более новых, + поэтому Вам придется воспользоваться версией между 1.0.1 и 1.0.7 для + расшифровки таких файлов. + +<Q> Как можно автоматизировать работу с GnuPG? + + Следует воспользоваться параметром --batch и не использовать паролей, + т.к. обычно нет возможности хранить их безопаснее, чем в связке секретных + ключей. Рекомендуем следующий способ создания ключей для автоматизации + работы: + + На безопасном компьютере: + [H ol] + [H li] Если Вам требуется автоматическое подписывание, создайте для + Вашего ключа - подключ имеющий возможность подписи (используйте + интерактивное меню редактирования предоставляемое командой + " gpg --edit-key KeyID ", введите "addkey" и выберите типа ключа DSA). + [H li] Необходим пароль. + [H li] gpg --export-secret-subkeys --no-comment ВашПодключ >secring.auto + [H li] Скопируйте secring.auto и файл таблицы открытых ключей во временный + каталог. + [H li] Перейдите в этот каталог. + [H li] " gpg --homedir . --edit ВашПодключ " и используйте "passwd" для + удаления пароля из подключа. Можете заодно удалить и все неиспользуемые + подключи. + [H li] Скопируйте secring.auto на дискету и вставьте ее в нужный компьютер. + [H /ol] + + На нужном компьютере: + [H ol] + [H li] Установите secring.auto, как связку секретных ключей. + [H li] Теперь можно запустить Ваш новый сервис. Хорошо бы также установить + систему обнаружения вторжений, для предупреждения об удачном + вторжении, после чего Вы сможете отозвать все подключи + установленные на данном компьютере и создать новые. + [H /ol] + +<Q> Какие почтовые клиенты можно использовать совместно с GnuPG? + + Использование GnuPG для шифрования почтовой корреспонденции это + одно из наиболее популярных его применений. Некоторые почтовые программы + или почтовые агенты (MUA) умеют работать с GnuPG. На данный момент + существует два способа шифрования с применением GnuPG: "старый метод" + с применением ASCII-кодирования (т.е. прозрачные подписи и шифрование) + и в соответствиии с RFC 2015 (ранее именуемое PGP/MIME, сейчас OpenPGP). + Последнее полностью поддерживает MIME. Некоторые MUA поддерживают только + один из этих методов. Поддержка может быть как встроена в MUA, так и + реализоваться в виде подключаемых подулей "плагинов", а также может + выполняться внешним, дополнительным программным обеспечением. + + Нижепреведённый список неполон: + + [H pre] + 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 Д Д С + + С-Сам, встроена поддержка , П-плагин , Д-Дополнительной программой + [H /pre] + + Ниже дан список несвободных MUA. Проект GNU не рекомендует применение + этих программ, но они представлены для полноты информации. + + [H pre] + 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) + [H /pre] + + Хороший обзор поддержки OpenPGP можно найти на:[H br] + [H a href=http://www.openpgp.fr.st/courrier_en.html]<http://www.openpgp.fr.st/courrier_en.html>[H /a] и[H br] + [H a href=http://www.bretschneidernet.de/tips/secmua.html]<http://www.bretschneidernet.de/tips/secmua.html>[H /a]. + + Пользователи программ MUA для Win32 для использования OpenPGP могут рассмотреть + применение GPGrelay [H a href=http://gpgrelay.sourceforge.net]<http://gpgrelay.sourceforge.net>[H /a], это небольшой + email-ориентированный сервер, который использует GnuPG для предоставления + возможности почтовым клиентам отправлять и принимать сообщения + соответствующие PGP-MIME (RFC 2015). + +<Q> Не могу найти библиотеки gpg? + + Про них часто спрашивают. Однако текущая точка зрения разработчиков GnuPG, + то что это создаст некоторые проблемы безопасности и следовательно + не стоит ожидать подобного в ближайшем будущем. Однако в некоторых + областях возможно применение gpgme. Вы найдете его на [H a href=[$hGPGFTP]/gcrypt/alpha/gpgme]<[$hGPGFTP]/gcrypt/alpha/gpgme>[H /a]. + +<Q> Я благополучно создал сертификат отзыва, но я не понимаю, как отослать его + на сервер ключей. + + Большинство серверов ключей не принимают 'голый' сертификат отзыва. + Вам придется сначала импортировать сертификат в GnuPG: + + [H samp] + $ gpg --import МойСертификатОтзыва.asc + [H /samp] + + затем отошлите отозванный ключ на сервер ключей: + + [H samp] + $ gpg --keyserver keyserver.kjsl.com --send-keys Мой_KeyID + [H /samp] + + (или воспользуйтесь для этого Web интерфейсом сервера ключей). + +<Dhomedir> +<Q> Как перенести файл таблицы связок ключей в другой каталог? + + GnuPG хранит несколько файлов в специальном домашнем каталоге. + Это файл персональных настроек, pubring.gpg, secring.gpg, trustdb.gpg, + и другие. GnuPG всегда будет создавать и использовать эти файлы. + Для Unix систем домашним обычно будет каталог " ~/.gnupg "; + для Windows " C:\gnupg\ ". + + Если Вы хотите переместить эти файлы в другое место, + воспользуйтесь параметром: + + [H samp] + --homedir /Мой/путь/ + [H /samp] + + и тогда GnuPG создаст эти файлы в указанном каталоге. Файл таблицы открытых + ключей будет в " /Мой/путь/pubring.gpg ". Таким образом можно хранить + свои секреты на дискете. Не используйте для этого параметр " --keyring ", + т.к. он задает дополнительные файлы связок ключей. + +<Q> Как проверить подписанный пакет? + + Перед проверкой подписи, сопровождающей пакет, необходимо сперва + импортировать ключ поставщика подписи, организации или человека + создавщего подпись в используемую таблицу связок ключей. Для + продотвращения предупреждений от GnuPG ключу следует иметь степень + достоверности (или подписать его локально). + + Скачайте файл с отделенной подписью вместе с пакетом. Обычно эти файлы + имеют тоже имя, что и подписанный пакет со следующими расширениями (.sig) + для бинарных или (.asc) для ASCII-кодированных подписей. + + После того, как ключ импортирован и пакет с сопровождающей его подписью + получен, используйте: + + [H samp] + $ gpg --verify ФайлПодпись ПодписанныйФайл + [H /samp] + + Если файл подписи имеет то же имя, что и файл пакета, то для проверки + пакета достаточно указать только файл подписи, тогда GnuPG получит + имя проверяемого файла путем удаления из имени расширения .sig или .asc. + Например, для проверки пакета названного Пакет.tar.gz используйте: + + [H samp] + $ gpg --verify Пакет.tar.gz.sig + [H /samp] + +<Q> Как экспортировать связку ключей только с избранными ключами? + + Если Вы желаете создать таблицу связок ключей имеющую только небольшое + подмножество ключей из Вашей основной таблицы связок, то просто укажите + ключи, которые Вы хотите экспортировать: + + [H samp] + $ gpg --armor --export Ключ1 Ключ2 Ключ3 Ключ4 > Ключи1-4.asc + [H /samp] + +<Dgpgsplit> +<Q> Имеется секретный ключ, но я потерян открытый ключ. Что можно сделать? + + Все OpenPGP секретные ключи имеют внутри себя копию открытого ключа + и имеется возможность создать новый открытый ключ используя секретный. + + Утилита для преобразования секретного ключа в открытый ключ (сейчас + это параметр запуска утилиты gpgsplit) включена в дистрибутив GnuPG + версии 1.2.1 и новейшие (а также может быть найдена в CVS). + Пример использования: + + [H samp] + $ gpgsplit --no-split --secret-to-public secret.gpg >publickey.gpg + [H /samp] + + Сперва следует экспортировать секретный ключ и преобразовывать + только его. Хотя использование всей таблицы также будет работать. + После завершения, файл publickey.gpg можно импортировать в GnuPG + обычным способом. + +<Q> Письмо с подписью имеет неверную подпись. Почему? + + Если Вы используете web-mail: + Убедитесь, что в настройках web-mail адреса отключено использование + HTML форматирования для отправляемых сообщений имеющих прозрачную подпись. + Такое форматирование может дополнить сообщение пробелами, символами + табуляции и в итоге дать неверную подпись. Отправленное чистотекстовым + сообщение получатель сможет скопировать текстовый файл для проверки или + возможно web-mail сервис может позволить приложить подписанное сообщение, + как файл, если нет возможности отправки его чистотекстовым. + + Для русскоязычной аудитории: существует также проблема таблиц символов. + Сообщение на русском языке может подвергнуться перекодировке по пути + следования (и не один раз). Например отправленное в cp1251 сообщение + может прийти к получателю в koi8-r. Так же многие почтовые программы + по разному совмещают проверку/подписывание сообщений с их + перекодировыванием в другие кодировки. Например почтовая программа + в Windows показывает сообщение в windows кодировке cp1251, а + рекомендуемая кодировка для email koi8-r и если в настройках программы + выбрана эта кодировка для отправки сообщений, то почтовый агент может + подписать тескт в cp1251, а затем сконвертировать его в koi8-r, что + приведет к неверной подписи, если программа у получателя не имеет + такой же ошибки (или не знает о ней). Аналогично может происходить + и при проверке сообщения созданного в koi8-r, но отображаемого + в cp1251. + + +<S> ПРОБЛЕМЫ СОВМЕСТИМОСТИ + +<Dcompat> +<Q> Как зашифровать сообщение в GnuPG так, чтобы его можно было бы + расшифровать в PGP? + + Это зависит от версии PGP. + + [H ul] + [H li]PGP 2.x[H br] + Обычно нельзя этого сделать потому, что PGP 2.x обычно использует шифр IDEA, + который не поддерживается GnuPG, т.к. данный алгоритм шифрования патентован + (см. <Ridea>), но если Вы имеете модифицированную версию PGP можете + попробовать: + + [H samp] + $ gpg --rfc1991 --cipher-algo 3des ... + [H /samp] + + Пожалуйста не пользуйтесь каналами для передачи данных в gpg, + а сделайте это используя файл; иначе PGP 2 не сможет понять это. + + Вы не сможете зашифровать симметричным шифром файл для PGP 2. + + + [H li]PGP 5.x и новейшие[H br] + Необходимо использовать два параметра: + + [H samp] + --compress-algo 1 --cipher-algo cast5 + [H /samp] + + Можно также воспользоваться "3des" вместо "cast5"; "blowfish" работает + не со всеми версиями PGP 5. Также можно добавить параметр: + + [H samp] + compress-algo 1 + [H /samp] + + в файл персональных настроек " ~/.gnupg/gpg.conf ", что не помешает + нормальной работе GnuPG. + Это относится и к симметричному шифрованию. + [H /UL] + +<Q> Как перейти с PGP 2.x на GnuPG? + + PGP 2 использует RSA и IDEA алгоритмы шифрования. Срок патента на RSA + истек и RSA поддерживается GnuPG с версии 1.0.3, а IDEA алгоритм остается + патентованным до 2007. При определенных условиях можно пользоваться + IDEA даже сейчас. В этом случае следует прочитать вопрос <Ridea> + о том, как получить поддержку IDEA в GnuPG и прочитать + [H a href=[$hGPGHTTP]/gph/en/pgp2x.html]<[$hGPGHTTP]/gph/en/pgp2x.html>[H /a] для выполнения перехода. + +<Q> (удален) + + (пусто) + +<Q> Почему PGP 5.x не сможет шифровать сообщения некоторыми ключами? + + PGP, Inc. отказалость от использования ключей ElGamal типа 20 даже для + шифрования. Они поддерживают только тип 16 (котрый идентичен, по крайней + мере для расшифрования). Для больше совместимости, GnuPG (с версии 0.3.3), + также использует тип 16 для подключей ElGamal, которые создаются, если + выбран рекомендованный по умолчанию алгоритм ключа. Можно добавить + ключ ElGamal типа 16 в связку ключей. + +<Q> Почему PGP 5.x не сможет проверить мои подписи? + + PGP 5.x не понимает подписи v4, но OpenPGP требует v4 подписей, что + GnuPG и делает по умолчанию. Используйте параметр "--force-v3-sigs" для + создания v3 подписей. + +<Q> Как перенести степени доверия владельцам ключей из PGP в GnuPG? + + Существует скрипт в каталоге tools, что бы помочь Вам. После импорта + из PGP таблицы связок ключей можно выполнить следующию команду: + + [H samp] + $ lspgpot pgpkeyring | gpg --import-ownertrust + [H /samp] + + где pgpkeyring это оригинальная таблица связок ключей, а не GnuPG таблица, + которую Вы возможно создали на первом этапе. + +<Q> PGP не нравится мой секретный ключ. + + Старые версии PGP могут не работать с некоторыми пакетами создаваемыми + GnuPG. Эти пакеты создаются в полном соотвествии с OpenPGP; однако PGP + не настоящее OpenPGP. Обойти это можно экспортировав секретные ключи + следующей командой: + + [H samp] + $ gpg --export-secret-keys --no-comment -a Ваш-KeyID + [H /samp] + + Другая возможная причина: по умолчанию GnuPG шифрует секретный ключ + симметричным шифром Blowfish. Старые версии PGP поймут только симметричные + шифры 3DES, CAST5 или IDEA. Используйте следующий способ, чтобы + перешифровать секретный ключ gpg другим шифром: + + [H samp] + $ gpg --s2k-cipher-algo=CAST5 --s2k-digest-algo=SHA1 + --compress-algo=1 --edit-key <User ID> + [H /samp] + + Затем командой passwd можно сменить пароль (можно сменить его на тотже + самый, но он зашифруется уже шифром CAST5). + + Сейчас можно экспортировать ключ и PGP должно принять его. + + Для PGP 6.x используются следующие параметры экспорта: + + [H samp] + $ gpg --s2k-cipher-algo 3des --compress-algo 1 --rfc1991 + --export-secret-keys <KeyID> + [H /samp] + +<Doptions> +<Q> GnuPG больше не инсталлирует файл " ~/.gnupg/options " file. Он не нужен? + + Нет. Файл " ~/.gnupg/options" переименован в " ~/.gnupg/gpg.conf" для + всех версий новее 1.1.92. Если файл " ~/.gnupg/options " существует, то + он будет найден при установке и всё еще будет использован, но данное + переинменование потребуется для совместимости по именам файлов с будущими + инструментами. Существующий файл настроек можно переименовать в gpg.conf + для обновляющихся пользователей и получающих сообщение, что "файл + настроек старого формата проигнорирован" (это происходит, когда программа + обнаруживает оба файла и gpg.conf, и options). + +<Q> Как экспортировать ключи GnuPG для использования в PGP? + + Данный вопрос задают настолько часто, что здесь получилось целое HOWTO: + + PGP сможет (для большинства типов ключей) использовать созданные в GnuPG + секретные ключи. Проблемы возникают от того, что GnuPG поддерживает + немного больше положений стандарта OpenPGP, чем PGP. Если секретный ключ + использует одно из них, то PGP отвергнет их или позднее могут возникать + какие-либо проблемы. Учтите, что PGP совсем не признает ElGamal ключи + предназначенные для подписи, так что они неприменимы ни в одной версии. + + Данные инструкции применимы для GnuPG 1.0.7 и последующих, + а также для PGP 7.0.3 и последующих. + + Начнем с редактирования ключа. Большинство параметров не обязательны, + т.к. значения используемые по умолчанию правильны, но лучше воспризвести всё + в точности потому, что некоторые иные значения параметров могут быть заданы + в файле персональный настроек. + + [H samp] + $ gpg --s2k-cipher-algo cast5 --s2k-digest-algo sha1 --s2k-mode 3 + --simple-sk-checksum --edit KeyID + [H /samp] + + Отключаем некоторые особенности GnuPG. Устанавливаем предпочтения + для шифров, хешей и сжатия в понимаемые PGP. (Да, Я понимаю, что + список шифров получился своеобразный, но это то, что использует PGP + без IDEA). + + [H samp] + > setpref S9 S8 S7 S3 S2 S10 H2 H3 Z1 Z0 + [H /samp] + + Теперь сохраняем список в ключе. + + [H samp] + > updpref + [H /samp] + + И наконец, мы должны расшифровать секретный ключ и зашифровать заново + шифром, который понравится PGP. Он указан в строке параметров при + вызове команды --edit выше, поэтому сейчас необходимо только сменить + пароль. Можно использовать и старый пароль, а можно воспользоваться + возможностью сменить его наконец. + + [H samp] + > passwd + [H /samp] + + Сохраняем изменения. + + [H samp] + > save + [H /samp] + + Сейчас можно использовать обычный экспорт: + + [H samp] + $ gpg --export KeyID > МойОткрытыйКлюч.pgp[H br] + $ gpg --export-secret-key KeyID > МойСекретныйКлюч.pgp + [H /samp] + + За эту информацию спасибо David Shaw! + + +<S> ПРОБЛЕМЫ и СООБЩЕНИЯ ОБ ОШИБКАХ + +<Q> Что означает сообщение "ВНИМАНИЕ: используется незащищенная память!" + + GnuPG требует установки прав setuid(root) на многих системах. + Это необходимо для блокирования страниц памяти. Блокирование страниц + не позволяет операционной системе сохранять их на диск, что позволяет + хранить Ваши данные в секрете. Если Вы не получаете это сообщение, + то видимо операционая система позволяет блокировать страницы + непревелигированным пользователям. GnuPG отказывается от + привелигированного режима сразу после блокирования страниц. + + Для установки прав setuid(root) исполняемому файлу gpg выполните: + + [H samp] + $ chmod u+s /путь/к/gpg + [H /samp] + + или + + [H samp] + $ chmod 4755 /путь/к/gpg + [H /samp] + + Некоторые люди предпочитают избегают применения setuid(root), если + нет каких-либо причин для создания особой секретности. Посоветуйтесь + с системным администратором, если нет возможности выполнить указанные + действия самостоятельно. + + На UnixWare 2.x и 7.x следует установить GnuPG с привилегиями 'plock' + для получения аналогичного эффекта: + + [H samp] + $ filepriv -f plock /путь/к/gpg + [H /samp] + + Если нет возможности или Вы не хотите устанавливать для GnuPG права + setuid(root), можно воспользоваться параметром "--no-secmem-warning" + или добавить: + + [H samp] + no-secmem-warning + [H /samp] + + в файл персональных настроек ~/.gnupg/gpg.conf (это избавит + от предупреждений). + + На некоторых системах (например Windows) GnuPG не блокирует страницы + памяти и старые версии GnuPG (<=1.0.4) предупреждали: + + [H samp] + gpg: Please note that you don't have secure memory + gpg: Учтите, что Вы не имеете безопасной памяти + [H /samp] + + Данное предупреждение нельзя было отключить вышеуказанным параметром потому, + что причина его возникновения очень серьезна. Однако это слишком смущало + пользователей, поэтому сообщение было убрано. + +<Q> Поддержка больших файлов (LFS) не работает. + + LFS корректно работает начиная с версии 1.0.4. Если configure не + видит этого - попробуйте другой компилятор. egcs 1.1.2 работает + прекрасно, другие gccs иногда нет. Некоторые проблемы компиляции + GnuPG 1.0.3 и 1.0.4 на HP-UX и Solaris были вызваны плохой + поддержкой LFS. + +<Q> При редактировании ключа значения доверий отображаются некорректно после + подписывания User ID. Почему? + + Это вызвано тем, что некоторая информация хранится непосредственно в + trustdb, но все вычисления степеней доверия могут быть выполнены только + после команды сохранения " save ". Это трудно поправимая ошибка архитектуры + программы, которая будет пересмотрена в какой-нибудь из будущих версий. + +<Q> В чем смысл сообщения "skipping pubkey 1: already loaded"? + + Шифр RSA входит в пакет GnuPG начиная с версии 1.0.3. Если Вы всё еще + используете параметр "load-extension rsa" в файле персональных + параметров Вы увидите данное сообщение. + Просто удалите данную команду загрузки модуля из файла персональных + параметров. + +<Q> GnuPG 1.0.4 не создает ~/.gnupg. + + Это известная ошибка, уже исправленная в последовавшей версии GnuPG. + +<Q> Подписи ElGamal не проверяются всеми версиями начиная с 1.0.2 + + Используйте параметр --emulate-md-encode-bug. + +<Q> Старые версии GnuPG не могут проверить ElGamal подписи + + Обновите GnuPG до версии 1.0.2 или новее. + +<Q> При использовании --clearsign, в тексте появляются дополнительные минусы. + Почему? + + Это называется отделенный черточками текст, что является требованием + OpenPGP. Это происходит всегда, когда строка начинается с черточки ("-") + и необходмо для четкого отделения структур подписи (типа + "-----BEGIN PGP SIGNATURE-----") от других строк начинающихся с более + чем двух черточек. + + Если Вы используете GnuPG для обработки подобных сообщений, то все + дополнительные черточки удалятся. Хорошие почтовые клиенты (MUA) + удаляют эти черточки при отображении сообщения. + +<Q> Что означает сообщение "не могу обработать эти множественные подписи" + + Из-за различий в форматах сообщений GnuPG не всегда может правильно + разделить файл с множественными подписями на части. Данное сообщение + указывает на проблемы с входными данными. + + Единственный способ иметь множественные подписи в файле это использование + формата OpenPGP с пакетами One-Pass Signature (которые используются GnuPG + по умолчанию) или формат прозрачных подписей. + +<Q> Отправил ключ на сервер ключей, но ничего не произошло + Вы счастливый обладатель версии GnuPG 1.0.2 или старше под Windows. + В этих версиях GnuPg данная функция еще не была реализована, но это + не было ошибкой, поэтому и предупреждений никаких не было. Новейшие + версии сообщают об этом. + Обновите GnuPG до версии 1.0.4 или более новой. + +<Q> Что значит сообщение "gpg: waiting for lock ..." + + Старые версии gpg любили ненормально завершаться и оставлять + блокировочные файлы. Зайдите в ~/.gnupg удалеите все " .*.lock " файлы. + +<Q> Старые версии GnuPG (например 1.0) имеют проблемы с ключами созданными + новейшими версиями GnuPG + + Начиная с версии 1.0.3, ключи в GnuPG создаются с предпочтением + шифра TWOFISH (и шифра AES начиная с версии 1.0.4), и что тоже важно, + они совместимы с новым методом шифрования MDC. В будущем это станет частью + OpenPGP и поддерживается также PGP 7. Новый метод предотвращает атаки + на системы шифрования почты. + + Это означает, что версии GnuPG до 1.0.3 имеют проблемы с новыми ключами. + По причине исправления ошибок и прорех в безопасности, Вам настоятельно + рекомендуется использовать последнюю стабильную версию GnuPG. В качестве + временной меры, для решения проблемы, Вы можете принудить GnuPG использовать + старый шифр по умолчанию в качестве основного, добавив: + + [H samp] + cipher-algo cast5 + [H /samp] + + в Ваш файл персональных параметров. + +<Q> Начиная с 1.0.4, я вижу "не рекомендуем данный алгоритм шифрования ..." + + Если предупреждение появляется сразу после создания нового ключа, то + Вы являетесь свидетелем ошибки версии 1.0.4. Она использует новый шифр AES + (Rijndael), который некорректно называет "нерекомендуемым". + Игнорируйте данной предупреждение. Все последовавшие затем версии + GnuPG не имеют данной проблемы. + +<Q> Некоторые даты отображаются как ????-??-??. Почему? + + Во многих реализациях libc, даты превышающие 2038-01-19 не могут быть + правильно отображены. 64-bit ОС не имеют данной проблемы. Чтобы не + выводить неверное значение даты GnuPG заменяет ее вопросиками. + Если хотите получить корректное значение - используйте параметры + --with-colons и --fixed-list-mode. + +<Q> Проблема всё еще очтается. Как сообщить об ошибке? + + А Вы уверены, что Ваша проблема еще не обсуждалась в почтовых рассылках? + Вы просмотрели список ошибок (ссылку Вы найдете в документации)? + Если не уверены в том, что это ошибка, отправьте письмо в gnupg-devel + рассылку. В противном случае воспользуйтесь системой отслеживания ошибок + GUUG [H a href=http://bugs.guug.de/Reporting.html]<http://bugs.guug.de/Reporting.html>[H /a]. + +<Q> Почему GnuPG не поддерживает X.509 сертификаты? + + GnuPG во-первых, и это главное, внедряет OpenPGP стандарт (RFC 2440), + который использует инфраструктуру отличную от X.509. + + Всё это криптосистемы с открытым ключом, но открытые ключи в них + на самом деле обрабатываются различным образом. + +<Q> Почему национальные символы в моем User ID выглядят, мягко говоря, странно? + + В соотвествии с OpenPGP GnuPG сохраняет User ID строки (и другие + вещи) используя UTF-8. В процессе перекодирования в формат Unicode, + многие национальные символы кодируются как дву- или трех-байтовые + последовательности. Например, å (0xE5 в ISO-8859-1) + станет Ã¥ (0xC3, 0xA5). Это также может быть причиной того, + почему серверы ключей не находях Ваш ключ. + +<Q> Ошибка 'sed' при запуске ./configure на Mac OS X + + Это будет исправлено после обновления GnuPG до autoconf-2.50. + До тех пор: найдите строку CDPATH в скрипте configure вставьте после него: + + [H samp] + unset CDPATH + [H /samp] + +<Q> Почему GnuPG 1.0.6 падает на связках ключей из версии 1.0.7? + + Есть небольшая ошибка в версии 1.0.6, из-за которой которой некорректно + обрабатываются пакеты доверий. Возможно понадобится данный патч, если нет + возможности обновить GnuPG: + + [H a href=http://www.gnupg.org/developer/gpg-woody-fix.txt]<http://www.gnupg.org/developer/gpg-woody-fix.txt>[H /a] + +<Q> После обновления GmuPG до версии 1.0.7 файлы связок ключей очень медленно + обрабатываются. Что делать? + + Был изменен способ хранения подписей для сохранения совместимости с v3 + подписями. Можете воспользоваться новым параметром --rebuild-keydb-caches, + который был добавлен в данной версии и предназначен для миграции на новые + версии и также увеличивает скорость многих операций со связками ключей. + +<Q> Разве полное доверие одному User ID-у на ключе не отменяет + предупреждающего сообщения, при шифровании сообщения для другого User ID? + + Нет. В GnuPG версии 1.2.1 и более ранних имелась ошибка в способе + определения достоверности ключей. В процессе разработки GnuPG 1.2.2, + ошибка была обнаружена в коде вычисления достоверности. Ошибка приводила + к тому, что для ключей и имеющиех больше одного User ID достоверность + одного User ID распространялась на все присутствующие в ключе. + Ошибка исправлена в GnuPG версии 1.2.2 и рекомендуется обновить GnuPG. + Больше информации и патч для некоторых до-1.2.2 версий GnuPG см. здесь: + + [H a href=http://lists.gnupg.org/pipermail/gnupg-announce/2003q2/000268.html]<http://lists.gnupg.org/pipermail/gnupg-announce/2003q2/000268.html>[H /a] + +<Q> Только что скомпилированная из исходников GnuPG для GNU/Linux + основанную на RPM и GnuPG не работает. Почему? + + Многие дистрибутивы 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 ". + +<S> ДРУГИЕ ВОПРОСЫ + +<Q> Как пользоваться GnuPG? + + Для создания пары ключей секретный/открытый запустите: + + [H samp] + $ gpg --gen-key + [H /samp] + + и выберите значения по умолчанию. + + Данные зашифрованные открытым ключом могут быть расшифрованы только + соответствующим ему секретным ключом. Секретный ключ защищается паролем, + а открытый ключ - нет. + + Чтобы отправить шифрованное сообщение кому-либо необхоимо зашифровать + это сообщение открытым ключом получателя и тогда он сможет расшифровать + сообщение своим и только своим секретным ключом и вводом пароля секретного + ключа. + + GnuPG также широко используется для создания подписей. Файлы зашифрованные + секретным ключом могут быть расшифрованы открытым ключом. Чтобы + подписать что-нибудь, вычисляется хеш подписываемых данных и затем + хеш шифруется каким-либо образом секретым ключом. Если кто-либо + имеет Ваш открытый ключ, он может проверить, что подпись создана именно + Вами и что оно не было изменено. + + Таблица связок ключей это файл на диске, который хранит ключи. + Есть таблица связок открытых ключей, в которой хранятся Ваши открытые + ключи и открытые ключи Ваших друзей. Также имеется таблица связок + секретных ключей, в которой хранятся Ваши секретные ключи и + Вы должны беречь их от посторонних. Никогда не предоставляйте доступ + к данным файлам другим людям и используйте *сильные* пароли для + защиты Ваших данных. + + Вы можете зашифровать что-либо стандартным способом используя параметр + " gpg -c ". Это позволит зашифровать данные паролем и не использовать + открытый и секретный ключи. Если получатель шифрованного сообщения знает + пароль - он сможет расшифровать его. Обычно это используется для + шифрования себе. Следует пользоваться этим только для переписки с теми, + кто знает или может легко обменяться с Вами паролями (например с Вашим + приятелем или женой). Преимущество данного подхода в том, что можно + время от времени менять пароль, чем снизить риск того, что многие старые + сообщения будут прочтены теми, кто узнает Ваш пароль. + + Можно добавить/скопировать ключи в/из таблицы связок ключей командами + " gpg --import " и " gpg --export ". " gpg --export-secret-keys " + экспортирует секретные ключи. Это обычно не нужно делать, но можно создать + ключ на одном компьютере, а затем перенести на другой. + + Ключи могут быть сертифицированы используя команду " gpg --edit-key ". + Когда Вы подписываете ключ, Вы подтверждаете, что ключ принадлежит + персоне, указанной в идентификаторе ключа. Вам следует полностью убедиться + в том, что ключ действительно принадлежит данной персоне: Поэтому Вам + следует проверить отпечатки ключа командой: + + [H samp] + $ gpg --fingerprint KeyID + [H /samp] + + по телефону (если Вы хорошо знаете голос другого человека), на + собрании по подписыванию ключей (обычно устраивается на компьютерных + конференциях) или встрече местной группы пользователей GNU/Linux. + + Так, что еще. Можете воспользоваться параметром " -o ИмяФайла " для + переназначения вывода некоторой информации в файл (используйте + "-" для принудительного вывода в stdout). " -r " позволяет указать + получателя (чьим открытым ключом шифровать) в командной строке вместо + ввода в интерактивном режиме. + + Да, еще одно важное дополнение. По умолчанию зашифрованные данные + имеют двоичный формат. Если неоходимо получить их как ASCII текст, + который выглядит читабельным, то добавьте параметр " -a ". Но + предпочтительно использовать MIME, который понимаемают почтовые клиенты + (Mutt, Pine и мн. другие). + + Существует небольшая проблема безопасности в OpenPGP (и соответственно + в GnuPG); чтобы избежать ее Вам следует всегда подписывать и шифровать + сообщения вместо простого шифрования. + +<Q> Почему некторые подписи ELG-E ключом достоверны? + + Это ключи ElGamal, которые сгенерированы GnuPG в v3 (RFC 1991) пакетах. + Черновой OpenPGP позднее изменил идентификатор ElGamal ключей, которые + используются и для подписи и для шифрования, с 16 на 20. + GnuPG сейчас использует 20 при создании новых ElGamal ключей, но всё еще + признает 16 (которые согласно OpenPGP теперь "только для шифрования"), + если такой ключ в v3 пакете. GnuPG единственная программа, которая + использовала эти v3 ElGamal ключи - поэтому такое допущение вполне + безопасно. + +<Q> Как работает механизм доверий? + + Он работает более или менее похоже на то, как это сделано в PGP. Отличие + в том, что степень доверия высисляется в тот момент, когда она необходима. + Это одна из причин необходимости файла trustdb, который содержит + список подписей достоверных ключей. Если Вы не запустили программу в + пакетном режиме, то Вам предложат назначить значение параметра доверия + (доверия владельцу ключа) для ключа. + + Вы можете просмотреть достоверность (вычисленное значение) используя + команду. + + [H samp] + $ gpg --list-keys --with-colons + [H /samp] + + Если первое поле "pub" или "uid", то второе поле показывает Ваше доверие: + + [H pre] + o = Неизвестно (ключ нов для программы) + e = Срок действия ключа истек + q = Не определено (нет присвоенного значения) + n = Полностью нет доверия данному ключу + m = Ограниченное доверие ключу + f = Полное доверие + u = Абсолютное доверие ключу; обычно используется, + только для ключей, для которых Вы имеете также и секретный ключ. + r = Ключ был отозван + d = Ключ отключен + [H /pre] + + Значение в "pub" записи предпочтительнее всех "uid" записей. + Вы можете получить список присвоенных степеней доверия (степень Вашего + доверия корректности подписывания ключей другими людьми) командой: + + [H samp] + $ gpg --list-ownertrust + [H /samp] + + Первое поле это отпечаток главного ключа, а второе поле - присвоенная + степень: + + [H pre] + - = Нет степени доверия вледьцу, не присвоена еще или не вычислена. + n = Не доверять подписям данного человека на других ключах. + m = Ограниченное доверие подписям данного человека. + f = Считать, что человек действительно знает, как правильно + подписывать ключи. + u = Не нужно доверий потому, что у нас имеется секретный ключ. + [H /pre] + + Храните данные значения в секрете потому, что они означают Ваше + отношение к другим людям. PGP хранит данную информацию в своей таблице + связок ключей, поэтому публиковать свою таблицу связок ключей, вместо + экспорта конкретных связок ключей - плохая идея. GnuPG хранит значения + доверий файле trustdb.gpg, поэтому можно свободно дать кому-либо + свой файл таблицы связок колючей (но можете использовать также и параметр + --export). + +<Q> Что означают: "key C26EE891.298, uid 09FB: ...."? + + Это внутреннее представление User ID в trustdb. + "C26EE891" это KeyID, "298" это локальный ID (LID) (номер записи trustdb) + и "09FB" это последние два байта хеша ripe-md-160 из User ID для данного + ключа. + +<Q> Как мне понять некоторые информационные сообщения? + + Во время проверки достоверности ключа GnuPG иногда печатает некоторую + информацию, которая предваряет информацию о проверяемых данных. + + [H samp] + "key 12345678.3456" + [H /samp] + + Это о том, что Key ID имеет 12345678 и его внутренний номер 3456, + который является номером записи в так называемой записи каталога trustdb. + + [H samp] + "uid 12345678.3456/ACDE" + [H /samp] + + Это о том, что это User ID для того же ключа. Для идентификации User ID + в связке - печатаются два последних байта (ACDE) его ripe-md-160 хеша. + + [H samp] + "sig 12345678.3456/ACDE/9A8B7C6D" + [H /samp] + + Это о том, что это подпись ключом с Key ID 9A8B7C6D указанных выше + ключа и User ID, если это подпись, подписывающая сам ключ, то + User ID часть будет пуста (..//..). + +<Q> Строки заголовка прозрачной подписи являются частью подписанного? + + Нет. Можно, например, добавить или удалить "Comment:" строки. + Они аналогичны строкам заголовка письма. Однако, срока "Hash:" + требуется для OpenPGP подписей для указания использованного + алгоритма цифровой подписи. + +<Q> Что такое список предпочитаемых алгоритмов? + + Список предпочитаемых алгоритмов это список шифров, хешей и + алгоритмов сжатия сохраняемый в самоподписи ключа во время создания + ключа. Когда Вы шифруете документ, GnuPG использует данный список + (который является частью открытого ключа) для того, чтобы определить + какие алогоритмы использовать. В основном это предназначеначено для + того, чтобы сообщить другим лючям, какие алгоритмы получатель сможет + принять и порядок предпочтения им данных алгоритмов. + +<Q> Как сменить список предпочитаемых алгоритмов? + + В версии 1.0.7 и новейших, Вы можете использовать редактирование + ключа и установить новый список предпочтений используя команду + "setpref"; формат данной команды аналогичен выводу команды "pref". + Предпочтения не изменятся немедленно, но они будут использованы при + создании нового User ID. Если Вы хотите обновить предпочтения + существующих User ID, выберите эти User ID (или ни одного для + обновления всех сразу) и дайте команду "updpref". Учтите, что + отметка времени на самоподписи увеличивается на одну секунду, + когда выполняется данная команда. + + +<S> БЛАГОДАРНОСТИ + + Премного благодарны Nils Ellmenreich за ведение настоящего FAQ столь + длительный срок, Werner Koch за первоначальный FAQ, всем участникам + почтовых рассылок gnupg-users и gnupg-devel присылавших вопросы и ответы. + Они предоставили наибольшее количество ответов. + + Также спасибо Casper Dik за скрипт для создания данного FAQ + (он использует его для великолепного FAQ по Solaris2). + + От переводчика: + Огромное спасибо разработчикам GnuPG. + Премного благодарен Павлу Шайдо за его переводы GNU Privacy Handbook + и руководства (man), за ценные советы по переводу интерфейса, настоящего + FAQ и пр. документов по GnuPG.[H br] + Спасибо также Gyre, Андрею Кавко, всем участникам почтовых рассылок + gnupg-ru и pgp-n-gpg. + +[H hr] + +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. + |