Версия для печати

Архив документации на OpenNet.ru / Раздел "Безопасность" (Многостраничная версия)

Руководство GNU по обеспечению конфиденциальности

Аннотация

Разрешается копирование, распространение и/или модификация этого документа на условиях GNU Free Documentation License, Version 1.1 или любой другой более поздней версии, опубликованной Free Software Foundation; без Инвариантных Разделов, Текстов Передней Обложки и Текстов Задней Обложки. Копия лицензии находится в приложении "GNU Free Documentation License".

Направляйте вопросы, описания ошибок и предложения по содержанию данного руководства Майку Эшли (Mike Ashley) (). (Это относится к английской версии)

Замечания и предложения относительно русской версии направляйте Павлу Шайдо ().

Вклад в создание данного руководства внесли, также, Мэтью Коуплэнд (Matthew Copeland), Йорген Грэн (Joergen Grahn), Дэвид А. Вилер (David A. Wheeler).

Последнюю версию данного документа можно найти на http://www.gnupg.org.


Содержание

1. Быстрый старт
Генерация новой пары ключей
Создание отзывающего сертификата
Обмен ключами
Экспорт открытого ключа
Импорт открытого ключа
Шифрование
Генерация подключа.
Зашифрование и расшифрование документов
Цифровые подписи и их проверка
Прозрачно подписанные(Clearsigned) документы
Отделённая подпись
2. Основы криптографии
Шифры
Симметричные шифры
Шифры с открытым ключом
Гибридные шифры
Хэширующие функции.
Цифровые подписи.
Шифры используемые в GnuPG
3. Управление ключами
Управление Вашей парой ключей
Целостность ключа.
Добавление и удаление компонент ключа
Отзыв компонент ключа
Изменение срока действия ключа
Проверка достоверности ключей
Доверие владельцу ключа
Использование доверия для проверки достоверности ключей
Распространение ключей
4. Повседневное использование GnuPG
Определение Ваших требований к защите
Выбор размера ключа
Защита Вашего секретого ключа
Выбор срока действия и использование дополнительных ключей
Управление Вашей сетью доверия.
Построение Вашей сети доверия
Законность использования GnuPG
5. Различные вопросы
Написание пользовательского интерфейса
A. Изменения (History)
B. GNU Free Documentation License
0. PREAMBLE
1. APPLICABILITY AND DEFINITIONS
2. VERBATIM COPYING
3. COPYING IN QUANTITY
4. MODIFICATIONS
5. COMBINING DOCUMENTS
6. COLLECTIONS OF DOCUMENTS
7. AGGREGATION WITH INDEPENDENT WORKS
8. TRANSLATION
9. TERMINATION
10. FUTURE REVISIONS OF THIS LICENSE
How to use this License for your documents

Список иллюстраций

3.1. Пример сети доверия

Список таблиц

2.1. Симметричные шифры
2.2. Алгоритмы с открытым ключом
2.3. Хэш-функции

Приложение A. Изменения (History)

$Id: history.xml 6 2005-10-08 22:09:59Z zwon $


Приложение B. GNU Free Documentation LicenseПред.   След.

Приложение B. GNU Free Documentation License

$Id: license.xml 5 2005-10-02 16:50:06Z zwon $

Содержание

0. PREAMBLE
1. APPLICABILITY AND DEFINITIONS
2. VERBATIM COPYING
3. COPYING IN QUANTITY
4. MODIFICATIONS
5. COMBINING DOCUMENTS
6. COLLECTIONS OF DOCUMENTS
7. AGGREGATION WITH INDEPENDENT WORKS
8. TRANSLATION
9. TERMINATION
10. FUTURE REVISIONS OF THIS LICENSE
How to use this License for your documents

Version 1.1, March 2000

Copyright (C) 2000 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

PREAMBLE

The purpose of this License is to make a manual, textbook, or other written document "free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others.

This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software.

We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.


APPLICABILITY AND DEFINITIONSПред. Приложение B. GNU Free Documentation License След.

APPLICABILITY AND DEFINITIONS

This License applies to any manual or other work that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. The "Document", below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as "you".

A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language.

A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (For example, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.

The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License.

The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License.

A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, whose contents can be viewed and edited directly and straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup has been designed to thwart or discourage subsequent modification by readers is not Transparent. A copy that is not "Transparent" is called "Opaque".

Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML designed for human modification. Opaque formats include PostScript, PDF, proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML produced by some word processors for output purposes only.

The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text.


VERBATIM COPYINGПред. Приложение B. GNU Free Documentation License След.

VERBATIM COPYING

You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3.

You may also lend copies, under the same conditions stated above, and you may publicly display copies.


COPYING IN QUANTITYПред. Приложение B. GNU Free Documentation License След.

COPYING IN QUANTITY

If you publish printed copies of the Document numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.

If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.

If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a publicly-accessible computer-network location containing a complete Transparent copy of the Document, free of added material, which the general network-using public has access to download anonymously at no charge using public-standard network protocols. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.

It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.


MODIFICATIONSПред. Приложение B. GNU Free Documentation License След.

MODIFICATIONS

You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:

  1. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission.

  2. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has less than five).

  3. State on the Title page the name of the publisher of the Modified Version, as the publisher.

  4. Preserve all the copyright notices of the Document.

  5. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices.

  6. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below.

  7. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document's license notice.

  8. Include an unaltered copy of this License.

  9. Preserve the section entitled "History", and its title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section entitled "History" in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence.

  10. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the "History" section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission.

  11. In any section entitled "Acknowledgements" or "Dedications", preserve the section's title, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein.

  12. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles.

  13. Delete any section entitled "Endorsements". Such a section may not be included in the Modified Version.

  14. Do not retitle any existing section as "Endorsements" or to conflict in title with any Invariant Section.

If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles.

You may add a section entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by various parties--for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.

You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one.

The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.


COMBINING DOCUMENTSПред. Приложение B. GNU Free Documentation License След.

COMBINING DOCUMENTS

You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice.

The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.

In the combination, you must combine any sections entitled "History" in the various original documents, forming one section entitled "History"; likewise combine any sections entitled "Acknowledgements", and any sections entitled "Dedications". You must delete all sections entitled "Endorsements."


COLLECTIONS OF DOCUMENTSПред. Приложение B. GNU Free Documentation License След.

COLLECTIONS OF DOCUMENTS

You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects.

You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.


AGGREGATION WITH INDEPENDENT WORKSПред. Приложение B. GNU Free Documentation License След.

AGGREGATION WITH INDEPENDENT WORKS

A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, does not as a whole count as a Modified Version of the Document, provided no compilation copyright is claimed for the compilation. Such a compilation is called an "aggregate", and this License does not apply to the other self-contained works thus compiled with the Document, on account of their being thus compiled, if they are not themselves derivative works of the Document.

If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one quarter of the entire aggregate, the Document's Cover Texts may be placed on covers that surround only the Document within the aggregate. Otherwise they must appear on covers around the whole aggregate.


TRANSLATIONПред. Приложение B. GNU Free Documentation License След.

TRANSLATION

Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License provided that you also include the original English version of this License. In case of a disagreement between the translation and the original English version of this License, the original English version will prevail.


TERMINATIONПред. Приложение B. GNU Free Documentation License След.

TERMINATION

You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.


FUTURE REVISIONS OF THIS LICENSEПред. Приложение B. GNU Free Documentation License След.

FUTURE REVISIONS OF THIS LICENSE

The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/.

Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation.


How to use this License for your documentsПред. Приложение B. GNU Free Documentation License 

How to use this License for your documents

To use this License in a document you have written, include a copy of the License in the document and put the following copyright and license notices just after the title page:

Copyright (c) YEAR YOUR NAME. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with the Invariant Sections being LIST THEIR TITLES, with the Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST. A copy of the license is included in the section entitled "GNU Free Documentation License".

If you have no Invariant Sections, write "with no Invariant Sections" instead of saying which ones are invariant. If you have no Front-Cover Texts, write "no Front-Cover Texts" instead of "Front-Cover Texts being LIST"; likewise for Back-Cover Texts.

If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software.


Глава 1. Быстрый старт Пред.   След.

Глава 1. Быстрый старт

$Id: c1.xml 5 2005-10-02 16:50:06Z zwon $

Содержание

Генерация новой пары ключей
Создание отзывающего сертификата
Обмен ключами
Экспорт открытого ключа
Импорт открытого ключа
Шифрование
Генерация подключа.
Зашифрование и расшифрование документов
Цифровые подписи и их проверка
Прозрачно подписанные(Clearsigned) документы
Отделённая подпись

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

GnuPG использует криптографию с открытым ключом. Каждый пользователь имеет пару ключей (keypair), состоящую из секретного (private) и открытого (public) ключей. Секретный ключ является секретом пользователя и не может быть передан другому лицу, ни при каких обстоятельствах. Открытый ключ передается всем людям, с которыми пользователь будет обмениваться сообщениями. На самом деле GnuPG использует несколько более хитроумную схему, при которой пользователь имеет первичную пару ключей и, возможно, дополнительно несколько подчиненных. Первичный и подчиненные ключи объединены, для упрощения их использования, и эта связка, зачастую, может рассматриваться просто, как одна пара ключей.

Генерация новой пары ключей

Для создания первичной пары ключей используется команда --gen-key.

alice$ gpg --gen-key
gpg (GnuPG) 1.4.0; Copyright (C) 2004 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.

Please select what kind of key you want:
   (1) DSA and Elgamal (default)
   (2) DSA (sign only)
   (5) RSA (sign only)
Your selection?

GnuPG может создавать несколько разных типов ключей, но первичный ключ должен быть пригоден для создания подписи (signature). Поэтому в данном меню предлагается только три варианта. Вариант 1 создает две пары ключей. DSA - первичная, используемая только для подписи. ElGamal - подчиненная, используемая для шифрования. Вариант 2 похож, но создает только пару DSA, которая не может использоваться для шифрования. Вариант 5 создаёт пару RSA, которая может использоваться только для подписи. В любом случае, позже можно создать дополнительные подчинённые пары ключей для подписи и шифрования.

Также Вы должны выбрать размер ключа. Размер ключа DSA должен быть между 512 и 1024 бит. Ключи ElGamal и RSA могут иметь любой размер. GnuPG не допускает длину ключей менее 768 бит. Если Вы выбрали вариант 1, то размер DSA ключа полагается равным 1024 битам и запрашивается только размер ключа ElGamal.

Your selection? 1
DSA keypair will have 1024 bits.
ELG-E keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048)

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

Наконец, Вы должны указать срок действия ключа. В случае варианта 1, указанный срок используется для обоих ключей.

Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0) 

Большинству пользователей подойдет бессрочный ключ. Срок действия следует выбирать с осторожностью; хотя можно изменить срок действия после создания ключа, не исключены проблемы с передачей изменений тем пользователям, у которых уже имеется Ваш открытый ключ.

В дополнение к параметрам ключа, Вы должны указать идентификатор пользователя. Идентификатор нужен, чтобы связать созданный ключ с конкретным лицом.

You need a User-ID to identify your key; the software constructs the user id
from Real Name, Comment and Email Address in this form:
    "Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>"

Real name: Alice
Email address: alice@wonderland.uk
Comment: test key                 
You selected this USER-ID:
    "Alice (test key) <alice@wonderland.uk>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit?

Для того, чтобы принять данный идентификатор введите 'O'. Если Вы хотите изменить имя, коментарий или адрес e-mail введите, соответственно, 'N', 'C' или 'E'. Ввод символа 'Q' приведёт к выходу из программы. При генерации ключа создается только один идентификатор пользователя, но возможно создание дополнительных идентификаторов, если Вы хотите использовать ключ в нескольких контекстах; например, как инженер на работе и как политический деятель после нее. Идентификатор пользователя не может быть отредактирован после создания.

GnuPG запросит пароль для защиты первичного и подчиненного секретных ключей, которые Вы будете держать в недоступном для других месте.

You need a Passphrase to protect your private key.    

Enter passphrase: 

На длину пароля нет ограничений, и его следует выбирать тщательно. С точки зрения безопасности, пароль для защиты ключа очень важен в GnuPG (и других системах с открытым ключом), т.к. это Ваша единственная защита в случае, если Ваш секретный ключ попадет в чужие руки. Не следует брать слова из БСЭ, чередуйте регистр букв и используйте неалфавитные символы. Хороший пароль критичен для надежности GnuPG. При вводе пароля GnuPG не отображает вводимые символы.

Далее GnuPG генерирует ключ. В случае если в Вашей системе не очень хороший генератор случайных чисел, процедура генерации ключа может занять довольно много времени. В некоторых случаях помогает шевеление мышкой, в некоторых настройка системы.

We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
++++++++++++++++++++++++++++++.+++++++++++++++.+++++.++++++++++...+++++.+++++.++
+++++++++++++...++++++++++++++++++++.+++++...+++++..++++++++++..+++++.+++++.>+++
++............<+++++>+++++......................................................
.+++++
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
+++++.++++++++++++++++++++++++++++++..++++++++++++++++++++.+++++.+++++.+++++.+++
++.++++++++++...+++++.+++++.+++++++++++++++.+++++++++++++++...++++++++++++++++++
++>++++++++++>..+++++...........................................................
...............................................................+++++^^^^^
gpg: /home/alice/.gnupg/trustdb.gpg: trustdb created
gpg: key 5715A306 marked as ultimately trusted
public and secret key created and signed.

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 1u
pub   1024D/5715A306 2005-04-09
      Key fingerprint = F62B 2DBE A548 8077 6AA1  088F F69B 1489 5715 A306
uid                  alice (test key) <alice@wonderland.uk>
sub   2048g/4710371E 2005-04-09

Создание отзывающего сертификата

После создания пары ключей, Вам следует создать отзывающий сертификат (revokation certificate) для первичного открытого ключа, используя команду --gen-revoke. Если Вы забудете пароль, либо Ваш секретный ключ будет похищен или утерян, этот сертификат может быть разослан для уведомления о том, что открытый ключ нельзя больше использовать. Отозванный открытый ключ может использоваться для проверки сделанных Вами подписей и дальше, но он не может быть использован для зашифрования сообщений для Вас. При этом, Вы сохраняете возможность расшифровывать отправленные Вам сообщения, при наличии секретного ключа.

alice% gpg --output revoke.asc --gen-revoke mykey
[...]

Аргумент mykey - идентификатор Вашей первичной пары ключей или любая часть идентификатора пользователя Вашей пары ключей. В нашем случае в качестве аргумента можно указать, например: 'alice', 'alice@wonderland.uk', '5715A306'. '5715A306' -- это идентификатор ключа, он был выведен при выполнении команды --gen-key после генерации ключа (см. предыдущий раздел). Сгенерированный сертификат будет сохранен в файле revoke.asc. Если опция --output опущена, результат помещается в стандартный вывод. Кроме того, GnuPG запрашивает причину генерации отзывающего сертификата.

alice% gpg --output revoke.asc --gen-revoke alice@wonderland.uk

sec  1024D/5715A306 2005-04-09 alice (test key) <alice@wonderland.uk>

Create a revocation certificate for this key? y
Please select the reason for the revocation:   
  0 = No reason specified
  1 = Key has been compromised
  2 = Key is superseded
  3 = Key is no longer used
  Q = Cancel
(Probably you want to select 1 here)
Your decision? 1
Enter an optional description; end it with an empty line:
> 
Reason for revocation: Key has been compromised
(No description given)
Is this okay? y

Вы можете вывести сертификат на принтер и хранить его где-нибудь в надежном месте (банковский сейф подойдет). Сертификат ни в коем случае не должен попасть к посторонним лицам. Если сертификат попадет в чужие руки и будет опубликован, то Ваш открытый ключ утратит свое действие.


Обмен ключами Пред. Глава 1. Быстрый старт  След.

Обмен ключами

Для общения с кем-либо, вы должны обменяться ключами. Просмотреть список имеющихся открытых ключей, можно используя команду --list-keys.

alice% gpg --list-keys
/home/alice/.gnupg/pubring.gpg
---------------------------------------
pub  1024R/B115BDB6 2002-05-01 Alice (test key) <alice@wonderland.uk>

Экспорт открытого ключа

Перед тем как послать кому-либо открытый ключ, Вы должны его экспортировать. Для этого используйте команду --export. Ей требуется, дополнительно, аргумент, идентифицирующий экспортируемый открытый ключ, как и для --gen-revoke.

alice% gpg --output alice.gpg --export alice@wonderland.uk

Ключ экспортируется в двоичном формате, что бывает неудобно. GnuPG имеет опцию командной строки --armor, которая указывает на необходимость вывода в формате ASCII. Практически любой вывод GnuPG, т.е. ключи, зашифрованные документы, подписи, может происходить в формате ASCII.[1]

alice% gpg --armor --export alice@wonderland.uk
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.2.0 (FreeBSD)

mIsEPNAu8wEEALf1zGv9/bkEKL1fTpkr0lvsmtK5Frgymlk7uInWfFdoucjAci9t
wyU8HXNdFNCx1utWT5GNDD1aDhiFukc7UrFVuVbAjtOikFrZ939RrLKqOEoVd8XI
ZXbgiSjs2ZqG32PpB+9X+3Z4OM64tna0NTvyqYP9LtOPHZpYGHwd5McfAAYptCZB
bGljZSAodGVzdCBrZXkpIDxhbGljZUB3b25kZXJsYW5kLnVrPoiyBBMBAgAcBQI8
0C7zAhsDBAsHAwIDFQIDAxYCAQIeAQIXgAAKCRDHOpmHsRW9tvsYBACmRyUoCnj5
Awh/bFTcmsZi687ec4EzCby8OF586FAQSj4HX4LvAUc/u+4NHVbQRkKW2RJVnaHv
YHUmjgteywMN3YqKd80/fbWIjyIgKNY+vgSEPMwiNMo6hR1frtfTMBnmwIWADMn0
3I1kxP2GfreSCHgy+FA3k5lrxvFnZwkXcA==
=RowZ
-----END PGP PUBLIC KEY BLOCK-----

Импорт открытого ключа

Открытый ключ может быть добавлен к связке Ваших открытых ключей при помощи команды --import.

alice% gpg --import blake.asc
gpg: key 01A1FE63: public key "Blake (dumb) <blake@anywhere.ru>" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
alice% gpg --list-keys
/home/alice/.gnupg/pubring.gpg
---------------------------------------
pub  1024R/B115BDB6 2002-05-01 Alice (test key) <alice@wonderland.uk>

pub  1024R/01A1FE63 2002-05-01 Blake (dumb) <blake@anywhere.ru>
sub  1024R/526C7F7F 2002-05-01 [expires: 2003-05-01]

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

alice% gpg --fingerprint alice@wonderland.uk
pub  1024R/B115BDB6 2002-05-01 Alice (test key) <alice@wonderland.uk>
     Key fingerprint = DE49 CDEF 12A3 8B7B 272B  A572 C73A 9987 B115 BDB6

alice% gpg --fingerprint
/home/test/.gnupg/pubring.gpg
-----------------------------
pub  1024R/B115BDB6 2002-05-01 Alice (test key) <alice@wonderland.uk>
     Key fingerprint = DE49 CDEF 12A3 8B7B 272B  A572 C73A 9987 B115 BDB6

pub  1024R/01A1FE63 2002-05-01 Blake (dumb) <blake@anywhere.ru>
     Key fingerprint = 80B8 1955 7D68 FE4F D882  DAD1 D85C 124A 01A1 FE63
sub  1024R/526C7F7F 2002-05-01 [expires: 2003-05-01]

Отпечатки ключа проверяются его владельцем. Это может быть сделано при личной встрече, по телефону, или любым другим способом, гарантирующим, что Вы общаетесь с владельцем ключа. Если отпечатки полученные Вами совпадают с указанными владельцем ключа, то можете быть уверены, что обладаете достоверной копией ключа.

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

Для подписи ключа необходимо перейти в режим редактирования ключа при помощи команды --edit-key.

alice% gpg --edit-key blake@anywhere.ru

pub  1024R/01A1FE63  created: 2002-05-01 expires: never      trust: -/-
sub  1024R/526C7F7F  created: 2002-05-01 expires: 2003-05-01
(1). Blake (dumb) <blake@anywhere.ru>

Command> sign
             
pub  1024R/01A1FE63  created: 2002-05-01 expires: never      trust: -/-
 Primary key fingerprint: 80B8 1955 7D68 FE4F D882  DAD1 D85C 124A 01A1 FE63

     Blake (dumb) <blake@anywhere.ru>

How carefully have you verified the key you are about to sign actually belongs
to the person named above?  If you don't know what to answer, enter "0".

   (0) I will not answer. (default)
   (1) I have not checked at all.
   (2) I have done casual checking.
   (3) I have done very careful checking.

Your selection? 3
Are you really sure that you want to sign this key
with your key: "Alice (test key) <alice@wonderland.uk>"

Really sign? y

GnuPG поинтересуется насколько тщательно Вы проверили достоверность ключа и попросит подтвердить Ваше желание подписать ключ. Подписав ключ, Вы можете просмотреть список подписей на ключе и увидеть там добавленную Вами. Каждый идентификатор пользователя ключа подписан самим ключом и ключом каждого пользователя, заверившего этот ключ.

Command> check
uid  Blake (dumb) <blake@anywhere.ru>
sig!3       01A1FE63 2002-05-01   [self-signature]
sig!        B115BDB6 2002-05-01   Alice (test key) <alice@wonderland.uk>


[1] Многие, часто используемые, опции командной строки могут быть установлены в файле конфигурации.


Шифрование Пред. Глава 1. Быстрый старт  След.

Шифрование

Генерация подключа.

Если Вы при генерации ключа выбрали вариант 2 (DSA) или 5 (RSA), то имеющийся у Вас ключ может использоваться только для подписи. Для того, чтобы Ваши корреспонденты могли зашифровывать направляемые Вам сообщения, необходимо создать дополнительный ключ, который может использоваться для шифрования. Генерация дополнительного ключа осуществляется в режиме редактирования.

alice%gpg --edit-key alice@wonderland.uk
Secret key is available.

pub  1024R/B115BDB6  created: 2002-05-01 expires: never      trust: u/u
(1). Alice (test key) <alice@wonderland.uk>

Command> addkey
Key is protected.

You need a passphrase to unlock the secret key for
user: "Alice (test key) <alice@wonderland.uk>"
1024-bit RSA key, ID B115BDB6, created 2002-05-01

Please select what kind of key you want:
   (2) DSA (sign only)
   (3) ElGamal (encrypt only)
   (5) RSA (sign only)
   (6) RSA (encrypt only)
Your selection?

Если Вы намерены использовать подключ для шифрования, то следует выбрать вариант 3 или 6.

Your selection? 6
What keysize do you want? (1024) 
Requested keysize is 1024 bits   
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0) 
Key does not expire at all
Is this correct (y/n)? y
Really create? y        
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
+++++
..+++++

pub  1024R/B115BDB6  created: 2002-05-01 expires: never      trust: u/u
sub  1024R/89D3ED33  created: 2002-05-03 expires: never     
(1). Alice (test key) <alice@wonderland.uk>

Command> save

Нетрудно заметить, что в списке ключей появился второй ключ. Для того, чтобы выйти из режима редактирования, сохранив изменения, воспользуйтесь командой save.

Зашифрование и расшифрование документов

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

Если Вы хотите послать сообщение другу, то зашифровываете его при помощи открытого ключа друга, а тот расшифровывает его при помощи своего секретного ключа. Если друг захочет Вам ответить, то он зашифрует ответ при помощи Вашего открытого ключа, а Вы расшифруете его своим секретным.

Для зашифрования документа используется команда --encrypt. Вы должны иметь открытые ключи предполагаемых получателей. Программа ожидает в качестве параметра имя шифруемого документа или, в случае его отсутствия, шифрует стандартный ввод. Зашифрованный результат помещается в стандартный вывод, если не указана опция --output. Для повышения защиты документ дополнительно сжимается.

alice% gpg --output message.gpg --encrypt --recipient blake@anywhere.ru message.txt

Опция --recipient используется для каждого получателя и имеет аргумент, идентифицирующий открытый ключ, которым должен быть зашифрован документ. Зашифрованный документ может быть расшифрован только тем, чей секретный ключ соответствует одному из указанных открытых ключей. В частности, Вы не можете расшифровать зашифрованный Вами документ, если не включили свой открытый ключ в список получателей.

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

blake% gpg --output message.txt --decrypt message.gpg

You need a passphrase to unlock the secret key for
user: "Blake (dumb) <blake@anywhere.ru>"
1024-bit RSA key, ID 526C7F7F, created 2002-05-01 (main key ID 01A1FE63)

Enter passphrase: 

Документы, также, можно зашифровывать без открытого ключа. Вместо этого используется симметричный алгоритм для зашифровки документа. Ключ, используемый при зашифровании, образуется из ключевой фразы. Для большей безопасности эта ключевая фраза не должна совпадать с той, которую Вы используете для защиты секретного ключа. Симметричный шифр применим, когда нет необходимости обмениваться ключевой фразой. Для использования симметричного шифра применяется команда --symmetric.

alice% gpg --output message.gpg --symmetric message.txt
Enter passphrase: 

Цифровые подписи и их проверка Пред. Глава 1. Быстрый старт  След.

Цифровые подписи и их проверка

Цифровая подпись удостоверяет создателя и дату создания документа. Если документ будет каким-либо образом изменен, то проверка цифровой подписи будет неудачной. Цифровая подпись может использоваться в тех же целях, что и обычная подпись. Исходные тексты GnuPG, например, подписаны, и Вы можете убедиться, что они дошли до Вас неизменёнными.

Создание и проверка подписей отличается от зашифрования/расшифрования. При подписи документа используется закрытый ключ подписывающего, а проверяется подпись с использованием его открытого ключа. Например, Alice использует свой секретный ключ, чтобы подписать свою новую статью в журнал. Редактор, получив письмо, использует открытый ключ Alice, чтобы проверить, что письмо действительно от Alice и не было изменено за время пересылки.

Для подписи документов используется команда --sign.

alice% gpg --output doc.sig --sign doc

You need a passphrase to unlock the secret key for
user: "Alice (test key) <alice@wonderland.uk>"
1024-bit RSA key, ID B115BDB6, created 2002-05-01

Enter passphrase: 

Если не указать подписываемый документ, то данные считываются со стандартного ввода. Перед подписью документ сжимается. Подписанный документ выводится в двоичном формате.

Имея подписанный документ, Вы можете либо только проверить подпись, либо проверить подпись и восстановить исходный документ. Для проверки подписи используется команда --verify. Для проверки подписи и извлечения документа используется команда --decrypt.

blake% gpg --output doc --decrypt doc.sig
gpg: Signature made Sat May  4 19:04:21 2002 MSD using RSA key ID B115BDB6
gpg: Good signature from "Alice (test key) <alice@wonderland.uk>"

Прозрачно подписанные(Clearsigned) документы

Обычно цифровые подписи применяются при подписи сообщений usenet и e-mail. При этом нежелательно сжимать подписываемые документы. Команда --clearsign добавляет к документу цифровую подпись в формате ASCII, не изменяя при этом сам документ.

alice% gpg --output doc.asc --clearsign doc

You need a passphrase to unlock the secret key for
user: "Alice (test key) <alice@wonderland.uk>"
1024-bit RSA key, ID B115BDB6, created 2002-05-01

Enter passphrase:
alice% cat doc.asc
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

GnuPG - инструмент для защиты коммуникаций. Эта глава коротко описывает
основы работы с GnuPG, включая создание пар ключей, обмен ключами и их
проверку, зашифровку и расшифровку документов, заверение документов
цифровой подписью.  Она не описывает в деталях принципы криптографии с
открытым ключом, шифрования и цифровых подписей. Эти вопросы
рассматриваются в главе 2. Здесь, также, не рассматриваются тонкости
использования GnuPG. Эти вопросы рассматриваются в главах 3 и 4.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (FreeBSD)

iQCVAwUBPNP8VMc6mYexFb22AQLdAAP/SXHINHglH00hLlscGoVE1FCiFX7qTSO3
qwUFQi29WhqCXCq4DFTfZGTs4XQzb7592KpDy9swwNZ2sB7vaxQjqukffBdWrksZ
ERSZsz+xxKLWPiiBURg958Nym/eIRFY7nislv9Kc4V0UFDD9CjuE0rA7eWCg1XEX
0RcI2Zxiiv4=
=UV8s
-----END PGP SIGNATURE-----

Отделённая подпись

Применение подписанных документов ограниченно. Получатель должен восстанавливать документ из подписанной версии, и даже в случае прозрачной подписи, подписанный документ должен быть отредактирован для получения оригинала. Поэтому имеется третий метод подписи документов, который создает отделённую подпись (detached signature). Отделённая подпись создается при использовании команды --detach-sign.

alice% gpg --output doc.sig --detach-sign doc

You need a passphrase to unlock the secret key for
user: "Alice (test key) <alice@wonderland.uk>"
1024-bit RSA key, ID B115BDB6, created 2002-05-01

Enter passphrase: 

Для проверки подписи необходимы и подпись, и сам документ. Для проверки используется команда --verify.

blake% gpg --verify doc.sig doc
gpg: Signature made Sat May  4 19:34:08 2002 MSD using RSA key ID B115BDB6
gpg: Good signature from "Alice (test key) <alice@wonderland.uk>"

Глава 2. Основы криптографии Пред.   След.

Глава 2. Основы криптографии

$Id: c2.xml 7 2005-10-18 21:05:13Z zwon $

Содержание

Шифры
Симметричные шифры
Шифры с открытым ключом
Гибридные шифры
Хэширующие функции.
Цифровые подписи.
Шифры используемые в GnuPG

GnuPG использует несколько криптографических методов, включая симметричные шифры, шифры с открытым ключом, и однонаправленное хэширование. Если Вы используете GnuPG, то Вам необходимо, хотя бы в общих чертах, понимать как работают эти методы.

Эта глава содержит краткое описание основных криптографических методов, используемых в GnuPG. Для более серьёзного знакомства с криптографией Вам следует обратиться к другим источникам. Хорошая книга, для дальнейшего изучения: Bruce Schneier ``Applied Cryptography''. (Имеется перевод на русский язык: Б.Шнайер. Прикладная криптография. Протоколы, алгоритмы, исходные тексты на языке Си.-М.:Издательство ТРИУМФ, 2002 - 816с.:ил.)

Шифры

Предположим, что Алиса хочет переслать Бобу сообщение M таким образом, чтобы никто кроме Боба не мог прочитать это сообщение. Алиса может преобразовать это сообщение в некоторую недоступную для прочтения посторонними лицами форму C=EK(M) и в таком виде переслать Бобу. Боб получив C выполняет обратное преобразование и восстанавливает исходное сообщение M=DK(C). Принято называть исходное сообщение M открытым текстом, его закрытую форму C шифртекстом, преобразование EK(M) функцией зашифрования, а DK(C) функцией расшифрования. Дополнительный параметр K функций зашифрования и расшифрования называется ключом. Преобразования E и D обычно известны и не сохраняются в тайне, но для вычисления значения DK(C) необходимо ещё знать ключ расшифрования K, соответствующий тому ключу, который был использован при зашифровании. Без знания ключа расшифровать сообщение нельзя. Значение ключа выбирается из некоторого множества допустимых значений, достаточно большого, чтобы сделать перебор всех возможных ключей практически нереализуемым.

Вместе функции зашифрования и расшифрования образуют шифр. Если в шифре ключ расшифрования совпадает с ключом зашифрования, или может быть легко из него получен, то шифр называется симметричным. Если ключ расшифрования практически невозможно получить из ключа зашифрования, то шифр называется шифром с открытым ключом или ассиметричным. В ассиметричных шифрах ключ зашифрования называется открытым (public key), а соответствующий ему ключ расшифрования секретным или закрытым (secret key, private key). Открытый и секретный ключи образуют пару ключей (keypair).


Симметричные шифры Пред. Глава 2. Основы криптографии  След.

Симметричные шифры

Симметричный шифр это шифр в котором ключ расшифрования совпадает с ключом зашифрования (или может быть легко из него вычислен). Стороны, общающиеся при помощи симметричного шифра, должны договориться о ключе до начала обмена сообщениями. После того как они договорились, отправитель зашифровывает сообщение, используя ключ, отправляет получателю, и получатель расшифровывает сообщение, используя тот же самый ключ. Симметричные шифры делятся на блочные и потоковые. Блочные шифры обрабатывают данные блоками фиксированной длины, а потоковые побитно или побайтно. GnuPG использует только блочные шифры.

К достоинствам симметричных шифров можно отнести их высокую скорость работы и простоту использования для защиты данных. Недостатком симметричных шифров является сложность распространения ключей и невозможность использования их для цифровой подписи. Предположим, что Алиса хочет обмениваться данными с Бобом используя симметричный шифр, тогда она должна договориться с ним об используемом ключе. Для этого ей, скорее всего, придётся лично встретиться с Бобом, поскольку необходимо исключить вероятность попадания ключа к посторонним лицам. Если Алиса захочет переписываться с двумя десятками своих друзей, то ей придётся встретится с каждым, что может быть проблематично, особенно если друзья разбросаны по всему миру. Если друзья Алисы захотят переписываться не только с ней, но и друг с другом[2]...

Наиболее важными характеристиками блочного шифра являются длина ключа и размер блока. В общем случае, чем больше длина ключа, тем более надёжен шифр. Если длина ключа n бит, то количество возможных ключей 2n. В среднем необходимо перебрать 2n-1 ключей до нахождения правильного. GnuPG использует шифры с длиной ключа от 128 бит. 2128 это огромное число и, даже если объединить все компьютеры нашей планеты, им потребуется времени больше, чем возраст вселенной, для нахождения ключа. Однако, на практике ключ шифрования зачастую генерируется по определённому алгоритму из задаваемой пользователем ключевой фразы (пароля). В этом случае можно вместо перебора всех возможных ключей попытаться угадать или подобрать ключевую фразу, которая зачастую значительно короче, чем 128 бит. Поэтому очень важно выбирать хорошие ключевые фразы. Длина блока также важна, но она меньше влияет на надёжность шифра. Размер блока у современных шифров 64-256 бит.



[2] Если имеется группа из n человек, попарно переписывающихся друг с другом, то для каждой пары потребуется свой ключ, т.е. ключей.


Шифры с открытым ключом Пред. Глава 2. Основы криптографии  След.

Шифры с открытым ключом

Основная проблема симметричных шифров - обмен ключами. Отправитель и получатель должны обменяться ключами, которые будут использоваться для защищенного обмена информацией, но каким защищенным каналом они могут воспользоваться для обмена самими ключами? Шифры с открытым ключом позволяют решить эту проблему. При использовании такого шифра у каждого пользователя имеется пара ключей. Один ключ открытый, его не требуется сохранять в тайне и можно передать любому другому лицу. Второй ключ секретный, который хранится только у владельца пары и ни при каких обстоятельствах не должен попасть к посторонним. Отправитель зашифровывает сообщение открытым ключом получателя, и, будучи зашифровано этим ключом, сообщение может быть расшифровано только закрытым ключом получателя.

Этот метод решает проблему обмена ключами, присущую симметричным шифрам. Отпадает необходимость договоренности о ключе между отправителем и получателем. Все что требуется, это чтобы отправитель до начала секретного обмена информацией взял копию открытого ключа получателя.[3] Кроме того, один открытый ключ может использоваться всеми корреспондентами получателя. Таким образом, только n пар ключей необходимо для n человек, переписывающихся друг с другом. Ещё одним достоинством шифров с открытым ключом является возможность их использования для цифровой подписи.

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

Как и в случае симметричных шифров, безопасность шифра с открытым ключом зависит от ключа. Так же, как и для симметричных шифров, чем больше размер ключа, тем выше защита шифра, но нельзя сравнивать длины ключей симметричных шифров и шифров с открытым ключом как меру их относительной надежности. При грубом взломе симметричного шифра с ключом длиной 128 бит, взломщик должен перебрать до 2128-1 ключей для нахождения правильного. При взломе шифра RSA с открытым ключом с длиной ключа 1024 бита, взломщик должен разложить на множители число длиной 1024 бита. В зависимости от типа шифра с открытым ключом действия взломщика сильно различаются, поэтому нельзя сравнивать даже длины ключей различных шифров с открытым ключом.



[3] На самом деле здесь тоже имеются определённые сложности. Подробности описаны в главе "Управление ключами"


Гибридные шифры Пред. Глава 2. Основы криптографии  След.

Гибридные шифры

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

Гибридный шифр использует и симметричный шифр, и шифр с открытым ключом. Сначала генерируется случайный ключ для симметричного шифра, называемый сеансовым ключом. Сообщение зашифровывается симметричным шифром с использованием сеансового ключа. Затем сеансовый ключ зашифровывается открытым ключом получателя. Сеансовый ключ, зашифрованный шифром с открытым ключом, и сообщение, зашифрованное симметричным шифром, автоматически объединяются вместе. Получатель использует свой секретный ключ для расшифровки сеансового ключа и, затем, использует полученный сеансовый ключ для расшифровки сообщения. Так как ключ симметричного шифра передаётся защищённым образом, то для каждого сообщения генерируется новый сеансовый ключ. Дополнительно, появляется возможность зашифровать сообщение сразу для нескольких получателей, при этом к сообщению, зашифрованному сеансовым ключом, добавляется несколько копий сеансового ключа, зашифрованного открытыми ключами разных получателей. И PGP и GnuPG используют именно гибридную схему.

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


Хэширующие функции. Пред. Глава 2. Основы криптографии  След.

Хэширующие функции.

Хэширующая функция это многозначная функция H, ставящая в соответствие своему аргументу M произвольной длины значение h=H(M) фиксированной длины. Простая хэширующая функция - f(x) = 0 для всех целых x. Более интересна функция f(x) = x mod 37, которая отображает x в остаток от деления x на 37. Хэш-функции используемые в криптографических приложениях обладают следующими свойствами:

  1. Для любого M легко вычислить его хэш-значение  h=H(M);
  2. По известному значению h=H(M) практически невозможно определить M;
  3. Для сообщения M практически невозможно найти сообщение M' такое, что H(M)=H(M')
  4. Практически невозможно найти два случайных сообщения M и M' таких, что H(M)=H(M')  (свойство сильной устойчивости к коллизиям).

Хэш-значение сообщения может использоваться в качестве его уникального идентификатора. Если сообщение изменить, то изменится и хэш-значение. Найти другое сообщение с точно таким же хэш-значением практически невозможно. Благодаря этому свойству хэш-функции можно использовать для проверки целостности документов и для цифровой подписи. Предположим, что Алиса отправила Бобу некоторое сообщение, и хочет быть уверена, что никто посторонний не изменит сообщение по пути к Бобу. Алиса может вычислить значение хэш-функции для сообщения и передать это значение Бобу некоторым защищённым образом (например по телефону). Боб, приняв сообщение, может вычислить его хэш-значение и сравнить с тем, которое передала Алиса. Если значения совпадут, то сообщение дошло без изменений, в противном случае сообщение было повреждено. Очевидно, что наиболее важным параметром хэш-функции является длина возвращаемого ею значения. Если эта длина n бит, то для того, чтобы найти сообщение M', имеющее такое же хэш-значение, как и M, придётся перебрать в среднем 2n-1 различных сообщений.

Свойство сильной устойчивости к коллизиям так же является очень важным. Предположим, что Чарли хочет, чтобы Алиса подписала некоторый документ, но он знает, что Алиса его ни за что не подпишет. Чарли может создать другой документ, который Алиса согласится подписать, а затем, внося случайные изменения в оба документа (например, добавляя пробелы в разных местах текста) он может найти пару разных документов с одинаковым хэш-значением перебрав всего 2n/2 вариантов[4]. После этого Чарли даёт Алисе на подпись вариант хорошего документа, а затем прилагает полученную подпись к варианту плохого документа с тем же хэш-значением.



[4] Это явление называется парадоксом дней рождений. Если Вы хотите, чтобы с вероятностью 1/2 у одного из пришедших к Вам гостей день рождения совпадал с Вашим, то придётся пригласить 253 человека. Если же Вы хотите, чтобы с вероятностью 1/2 день рождения совпадал у любых двух гостей, то достаточно пригласить только 23 человека.


Цифровые подписи. Пред. Глава 2. Основы криптографии  След.

Цифровые подписи.

Некоторые алгоритмы с открытым ключом могут быть использованы для подписи документов. Подписывающий генерирует подпись используя свой секретный ключ. А желающий проверить подпись, использует для этого открытый ключ подписавшего.

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


Шифры используемые в GnuPG Пред. Глава 2. Основы криптографии  След.

Шифры используемые в GnuPG

В данном разделе содержатся краткие сведения об используемых в GnuPG шифрах. При выборе предпочитаемых алгоритмов шифрования следует учитывать, что в других реализациях OpenPGP некоторых из перечисленных шифров может не быть. Стандарт требует, чтобы в любой реализации имелись 3DES, DSA, ElGamal для шифрования и SHA1. Другие шифры могут отсутствовать.

Таблица 2.1. Симметричные шифры

НазваниеРазмер блока, битДлина ключа, битОписание
IDEA64128IDEA (International Data Encryption Algorithm) разработали Джеймс Мэсси (James Massey) и Ксуэджа Лай (Xuejia Lai) в 1991 году. Алгоритм используется в PGP 2.x и необходим для обмена информацией с пользователями PGP 2.x. Алгоритм запатентован и поэтому в основной дистрибутив GnuPG не входит, но может быть подключен в виде модуля расширения.
3DES641683DES (Triple-DES) шифр заключающийся в троекратном шифровании с помощью алгоритма DES - американского стандарта блочного шифрования до 2002 года. Сравнительно медленный, но зато имеется в любой реализации стандарта OpenPGP (RFC 2440).
CAST564128CAST5 (CAST-128) - алгоритм описанный в RFC 2144. Обладает высокой скоростью работы. Совместим с большинством реализаций.
Blowfish64128Разработан Брюсом Шнайером в 1993 году.
AES128128AES (Advanced Encryption Standard). Американский стандарт блочного шифрования (FIPS PUB 197) с 2001 года, разработаный на основе алгоритма Rijndael.
AES192128192
AES256128256
Twofish128256Разработан группой специалистов во главе с Брюсом Шнайером в качестве кандидата на AES.

Таблица 2.2. Алгоритмы с открытым ключом

НазваниеОписание
RSAАлгоритм RSA разработан Рональдом Райвестом (Ronald Rivest), Ади Шамиром (Adi Shamir) и Леонардом Адлеманом (Leonard Adleman) в 1978 году. Это первый алгоритм с открытым ключом, получивший широкое распространение. Алгоритм может использоваться как для подписи, так и для шифрования.
ElGamalАлгоритм предложил Тахер Эль-Гамаль (Taher ElGamal) в 1985 году. Алгоритм может использоваться и для подписи и для шифрования, но в реализациях алгоритма для подписей были обнаружены уязвимости и теперь алгоритм используется в GnuPG только для шифрования. ElGamal для шифрования имеется в любой реализации OpenPGP.
DSAАлгоритм описанный в стандарте цифровой подписи США (Digital Signature Standard (DSS), FIPS PUB 186-2). Обязателен для любой реализации OpenPGP.

Длина ключа в алгоритмах с открытым ключом выбирается пользователем в зависимости от личных потребностей. Не следует использовать ключи длиной менее 1024 бит. Для DSA это максимально допустимая длина. RSA и ElGamal позволяют использовать ключи большей длины. Не следует, однако, выбирать слишком большую длину ключа, т.к. это приводит к увеличению времени шифрования и генерации/проверки подписей, увеличивает размер подписей. Не следует забывать и о том, что надёжность гибридной схемы не выше, чем у слабейшего из компонентов. Т.е., например, нет смысла использовать ключ длиной 4096 бит с хэш-функцией со значением 160 бит. Рекомендации по выбору размера ключа можно найти на сайте http://www.keylength.com/

Таблица 2.3. Хэш-функции

НазваниеДлина значения, битОписание
MD5128Хэш-функция разработанная Рональдом Райвестом. Широко распространена. В данной хэш-функции были найдены уязвимости и использовать её не рекомендуется
SHA1160SHA-1 (Secure Hash Algorithm). Определена стандартом США FIPS PUB 180-2. В данной хэш-функции, как и в MD5, найдены уязвимости. Отказаться от использования данной хэш-функции не представляется возможным, т.к. её использование предусмотрено стандартом DSS. Кроме того, данная функция используется в OpenPGP для вычисления отпечатков и идентификаторов ключей.
RIPEMD160160Разработана в рамках проекта RIPE. Используется сравнительно редко
SHA256256Функции определены стандартом FIPS PUB 180-2 в качестве замены SHA1 и имеют большую длину значения.
SHA384384
SHA512512

Глава 3. Управление ключами Пред.   След.

Глава 3. Управление ключами

$Id: c3.xml 7 2005-10-18 21:05:13Z zwon $

Содержание

Управление Вашей парой ключей
Целостность ключа.
Добавление и удаление компонент ключа
Отзыв компонент ключа
Изменение срока действия ключа
Проверка достоверности ключей
Доверие владельцу ключа
Использование доверия для проверки достоверности ключей
Распространение ключей

Подделка ключа - наиболее слабое место в криптографии с открытым ключом. Злоумышленник может изменить пользовательскую связку ключей или подделать открытый ключ пользователя и посылать его другим для загрузки и использования. Например, предположим, что Хлой хочет отслеживать сообщения, которые Элис посылает Блэйку. Она могла бы использовать атаку, называемую человек в середине (man in the middle). Для этого Хлой создает новую пару ключей. Она заменяет копию открытого ключа Блэйка, принадлежащую Элис, новым открытым ключом. Затем она перехватывает сообщения, которые Элис посылает Блэйку. Каждое перехваченное сообщение она расшифровывает, используя новый секретный ключ, зашифровывает настоящим открытым ключом Блэйка и направляет их ему. Все сообщения, направленные Элис Блэйку, теперь могут быть прочитаны Хлой.

Правильное управление ключами является решающим фактором для обеспечения целостности не только Ваших связок ключей, но и связок ключей других пользователей. Основой управления ключами в GnuPG является подписание ключей. Подписание ключей имеет два основных применения: это позволяет Вам обнаруживать вмешательство в Вашу связку ключей, а также позволяет удостоверять, что ключ действительно принадлежит человеку, чьим идентификатором пользователя он помечен. Подписи на ключах также используются в схеме известной как сеть доверия (web of trust), которая позволяет считать допустимыми не только ключи подписанные лично Вами, но и подписанные людьми, которым Вы доверяете. Аккуратные пользователи, правильно реализовавшие управление ключами, могут исключить подмену ключей как вид атаки на конфиденциальность связи при помощи GnuPG.

Управление Вашей парой ключей

Пара ключей состоит из открытого и секретного ключей. Открытый ключ состоит из открытой части главного подписывающего ключа, открытых частей подчиненных подписывающих и шифрующих ключей, набора идентификаторов пользователя, ассоциирующих открытый ключ с реальным человеком. Каждая часть содержит данные о себе. Для ключа -- это его идентификатор, дата создания, срок действия и т.д. Для идентификатора пользователя -- имя человека, дополнительный комментарий и адрес email. Структура секретного ключа аналогична, но содержит секретные части ключей и не содержит информацию об идентификаторе пользователя.

Для просмотра пары ключей используется команда --edit-key. Например,

joe% gpg --edit-key joe@duck.zu
Secret key is available.

pub  1024R/3AA48DCE  created: 2002-05-05 expires: never      trust: u/u
sub  1024D/13375D62  created: 2002-05-06 expires: never     
sub  2048G/3745CA64  created: 2002-05-06 expires: 2004-05-05
sub  1024g/015418C9  created: 2002-05-06 expires: 2004-05-05
(1)  Joe Duck <joe@duck.zu>
(2). Joe Duck (cook) <jd@other.mail.zu>

Command>

При отображении открытого ключа выводится информация о том, доступен секретный ключ или нет. Затем выводится информация о каждом компоненте открытого ключа. Первая колонка показывает тип ключа. Символы pub обозначают открытую часть главного подписывающего ключа, а символы sub открытую часть подчиненных ключей. Вторая колонка показывает длину ключа в битах, тип и идентификатор. Тип D это ключ DSA, R - ключ RSA, g - ключ ElGamal, пригодный только для шифрования, G - ключ ElGamal, который может использоваться и для подписи и для шифрования. Дата создания и окончания срока действия показана в колонках три и четыре. Идентификаторы пользователя перечислены после ключей.

Дополнительная информация о ключе может быть получена различными командами. Команда toggle переключает между открытой и закрытой компонентами пары ключей, если обе из них доступны.

Command> toggle
               
sec  1024R/3AA48DCE  created: 2002-05-05 expires: never     
ssb  1024D/13375D62  created: 2002-05-06 expires: never     
ssb  2048G/3745CA64  created: 2002-05-06 expires: never     
ssb  1024g/015418C9  created: 2002-05-06 expires: never     
(1)  Joe Duck <joe@duck.zu>
(2)  Joe Duck (cook) <jd@other.mail.zu>

Command>

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

Целостность ключа.

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

Использование цифровых подписей решает эту проблему. Когда данные подписаны секретным ключом, соответствующий открытый ключ ограничен подписанными данными. Другими словами, только соответствующий открытый ключ может быть использован для проверки подписи и гарантирует, что данные не были изменены. Открытый ключ может быть защищен от изменения использованием соответствующего главного секретного ключа для подписи компонентов открытого ключа и идентификаторов пользователя, привязывая, таким образом, компоненты главного открытого ключа. Подпись компонентов открытого ключа соответствующим главным секретным подписывающим ключом называется самоподписью (self-signing), и открытый ключ, имеющий самоподписанные идентификаторы пользователя, привязанные к нему, называется сертификатом (certificate).

Например, у Джо есть два идентификатора пользователя и три подключа. Подписи на идентификаторах пользователя могут быть проверены командой check из меню редактирования ключа.

joe% gpg --edit-key joe
Secret key is available.

pub  1024R/3AA48DCE  created: 2002-05-05 expires: never      trust: u/u
sub  1024D/13375D62  created: 2002-05-06 expires: never     
sub  2048G/3745CA64  created: 2002-05-06 expires: 2004-05-05
sub  1024g/015418C9  created: 2002-05-06 expires: 2004-05-05
(1)  Joe Duck <joe@duck.zu>
(2). Joe Duck (cook) <jd@other.mail.zu>

Command> check
uid  Joe Duck <joe@duck.zu>
sig!3       3AA48DCE 2002-05-05   [self-signature]
uid  Joe Duck (cook) <jd@other.mail.zu>
sig!3       3AA48DCE 2002-05-06   [self-signature]

Как и ожидалось, все подписи сделаны главным подписывающим ключом с идентификатором ключа 0x3AA48DCE. Самоподписи на подключах также представлены в открытом ключе, но они не показываются в GnuPG.

Добавление и удаление компонент ключа

Как новые подключи, так и идентификаторы пользователя могут быть добавлены к Вашей паре ключей после ее создания. Идентификатор пользователя добавляется командой adduid. Вам будет выдан запрос относительно Вашего имени, адреса электронной почты и комментария, также как при создании пары ключей. Подключ добавляется командой addkey. Процедура аналогична используемой при первичном создании пары ключей. Подключ может быть подписывающим DSA ключом, ElGamal ключом пригодным только для шифрования, ключом ElGamal пригодным и для подписи и для шифрования или ключом RSA пригодным либо для подписи, либо для шифрования. Когда создаются подключ или идентификатор пользователя, они подписываются главным подписывающим ключом, при этом Вы должны ввести пароль, которым защищён главный ключ.

Дополнительные идентификаторы применимы, когда Вы выступаете в нескольких качествах. Например, Вы можете быть работником какой-либо фирмы и, в то же время, политическим деятелем. Коллеги по соответствующему виду деятельности будут знать Вас по соответствующему идентификатору. Так как эти группы людей не пересекаются, то каждая группа может не доверять другому идентификатору. Следовательно, оба идентификатора нужны.

Дополнительные подключи также могут быть полезны. Идентификаторы пользователя, ассоциированные с Вашим главным открытым ключом, заверяются другими людьми, с которыми Вы общаетесь, и смена главного ключа, следовательно, потребует переподтверждения. Это может оказаться сложным и занять много времени, если Вы общаетесь со многими людьми. С другой стороны, неплохо периодически менять подключи шифрования. Если подключ взломан, все данные, зашифрованные им, станут уязвимы. При смене подключа, уязвимой станет только часть данных.

Подключи и идентификаторы пользователя могут быть удалены. Для удаления подключа или идентификатора пользователя, Вы должны сначала выбрать его, используя команду key или uid. Это команды переключатели. Например, команда key 2 выберет второй подключ, повторная команда key 2 отменит выбор. Если не заданы дополнительные аргументы, выбор всех подключей или идентификаторов пользователя будет отменен. Если идентификатор пользователя, который надо удалить, выбран, то команда deluid удалит его из ключа. Аналогично, команда delkey удаляет все выбранные подключи из обоих, открытого и секретного, ключей.

Для управления локальными наборами ключей, удаление компонентов ключа -- хороший способ очистить открытые ключи других людей от ненужного материала. Удаление идентификаторов пользователя и подключей из Вашего собственного ключа, однако, не всегда разумно, т.к. усложняет распространение ключа. По умолчанию, когда пользователь импортирует Ваш обновленный открытый ключ, тот объединяется со старой копией Вашего открытого ключа, если она есть в его наборе ключей. Компоненты обоих ключей объединяются, и это эффективный способ восстановить удаленные Вами компоненты. Чтобы правильно обновить ключ, пользователь должен сначала удалить старую версию Вашего ключа и только затем импортировать новую. Это добавляет мороки людям, с которыми Вы общаетесь. Кроме того, если Вы отправляете ключ на сервер ключей, объединение произойдет неминуемо, и никто из получивших Ваш ключ с сервера ключей никогда не узнает о том, что Вы что-то там удалили. Следовательно, для обновления Вашего собственного ключа лучше отозвать соответствующие компоненты ключа, нежели удалять их.

Отзыв компонент ключа

Для отзыва подключа он должен быть выбран. Будучи выбран, он может быть отозван командой revkey. Ключ отзывается добавлением отзывающей самоподписи к ключу. В отличие от опции командной строки --gen-revoke, эффект наступает немедленно.

Command> revkey
Do you really want to revoke this key? y
Please select the reason for the revocation:
  0 = No reason specified
  1 = Key has been compromised
  2 = Key is superseded
  3 = Key is no longer used
  Q = Cancel
Your decision? 2
Enter an optional description; end it with an empty line:
> 
Reason for revocation: Key is superseded
(No description given)
Is this okay? y
               
You need a passphrase to unlock the secret key for
user: "Joe Duck (cook) <jd@other.mail.zu>"
1024-bit RSA key, ID 3AA48DCE, created 2002-05-05

pub  1024R/3AA48DCE  created: 2002-05-05 expires: never      trust: u/u
sub  1024D/13375D62  created: 2002-05-06 expires: never     
sub  2048G/3745CA64  created: 2002-05-06 expires: 2004-05-05
rev! subkey has been revoked: 2002-05-07
sub  1024g/015418C9  created: 2002-05-06 expires: 2004-05-05
(1)  Joe Duck <joe@duck.zu>
(2). Joe Duck (cook) <jd@other.mail.zu>

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

Спецификация OpenPGP не поддерживает отзыв идентификатора пользователя, но идентификатор может быть эффективно отозван отзывом самоподписи на нем. По причинам безопасности, описаным ранее, корреспонденты не будут доверять идентификатору пользователя не имеющему самоподписи.

Подпись отзывается командой revsig. Т.к. Вы можете иметь любое число подписанных идентификаторов пользователя, программа запросит Вас о каждой подписи.

Command> revsig
You have signed these user IDs:
     Joe Duck <joe@duck.zu>
   signed by 3AA48DCE at 2002-05-05
     Joe Duck (cook) <jd@other.mail.zu>
   signed by 3AA48DCE at 2002-05-06
user ID: "Joe Duck <joe@duck.zu>"
signed with your key 3AA48DCE at 2002-05-05
Create a revocation certificate for this signature? (y/N) n
user ID: "Joe Duck (cook) <jd@other.mail.zu>"              
signed with your key 3AA48DCE at 2002-05-06
Create a revocation certificate for this signature? (y/N) y
You are about to revoke these signatures:                  
     Joe Duck (cook) <jd@other.mail.zu>
   signed by 3AA48DCE at 2002-05-06
Really create the revocation certificates? (y/N) y
Please select the reason for the revocation:      
  0 = No reason specified
  4 = User ID is no longer valid
  Q = Cancel
Your decision? 4
Enter an optional description; end it with an empty line:
> 
Reason for revocation: User ID is no longer valid
(No description given)
Is this okay? y
               
You need a passphrase to unlock the secret key for
user: "Joe Duck (cook) <jd@other.mail.zu>"
1024-bit RSA key, ID 3AA48DCE, created 2002-05-05

                  
pub  1024R/3AA48DCE  created: 2002-05-05 expires: never      trust: u/u
sub  1024D/13375D62  created: 2002-05-06 expires: never     
sub  2048G/3745CA64  created: 2002-05-06 expires: 2004-05-05
rev! subkey has been revoked: 2002-05-07
sub  1024g/015418C9  created: 2002-05-06 expires: 2004-05-05
(1)  Joe Duck <joe@duck.zu>
(2). Joe Duck (cook) <jd@other.mail.zu>

Отозванный идентификатор пользователя указан отзывающей подписью при перечислении подписей на идентификаторах пользователя.

Command> check
uid  Joe Duck <joe@duck.zu>
sig!3       3AA48DCE 2002-05-05   [self-signature]
uid  Joe Duck (cook) <jd@other.mail.zu>
rev!        3AA48DCE 2002-05-07   [revocation]
sig!3       3AA48DCE 2002-05-06   [self-signature]

Отзыв и подключей, и самоподписей на идентификаторе пользователя добавляет отзывающие самоподписи к ключу. Т.к. подписи были добавлены, и ничего не удалялось, то отзыв всегда будет виден другим при распространении Вашего обновленного открытого ключа и объединении его с ранними копиями. Отзыв, таким образом, гарантирует, что у всех будет непротиворечивая копия Вашего открытого ключа.

Изменение срока действия ключа

Срок действия ключа может быть изменен командой expire из меню редактирования ключа. Если нет выбранных ключей, то будет изменен срок действия первичного ключа. Иначе изменяется срок действия выбранного подчиненного ключа.

Время окончания срока действия ключа связано с самоподписью на ключе. Окончание срока действия изменяется удалением старой подписи и добавлением новой. Так как Ваши корреспонденты не будут удалять старую копию ключа, они будут видеть дополнительную самоподпись на ключе после его обновления. Позднейшая самоподпись имеет приоритет, поэтому все корреспонденты будут однозначно осведомлены о времени действия Вашего ключа.


Проверка достоверности ключей Пред. Глава 3. Управление ключами  След.

Проверка достоверности ключей

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

GnuPG решает эту проблему при помощи механизма именуемого сеть доверия (web of trust). В модели сети доверия ответственность за проверку открытых ключей возложена на людей, которым Вы доверяете. Например, предположим

Если Элис уверена, что Блэйк проверяет достоверность ключей, которые он подписывает, то Элис может быть уверена, что ключи Хлой и Дхармы достоверны не проверяя их лично. Она просто использует свою достоверную копию открытого ключа Блэйка для проверки его подписи на ключах Хлой и Дхармы. Вообще, предполагая, что Элис совершенно уверена, что все правильно проверяют ключи, перед тем как их подписать, то любой ключ, подписанный достоверным ключом, будет достоверным.

Доверие владельцу ключа

На практике доверие субъективно. Например, ключ Блэйка достоверен, т.к. Элис подписала его, но она может не быть уверена, что Блэйк правильно проверяет ключи, которые он подписывает. В этом случае, она не будет считать ключи Хлой и Дхармы достоверными, основываясь на подписи Блэйка. Модель сети доверия решает эту задачу связывая с каждым открытым ключом в Вашем наборе значение указывающее уровень Вашего доверия владельцу ключа. Имеется пять уровней доверия.

unknown (неизвестное)

Ничего не известно о политике подписания ключей данным владельцем. Ключам в Вашем наборе, кроме Вашего собственного, первоначально присваивается этот уровень доверия.

none (нет)

Известна недобросовестность этого лица при подписи чужих ключей.

marginal (граничное)

Понимает смысл подписания ключей и проверяет их достоверность перед тем, как подписывать.

full (полное)

Владелец очень разборчив в подписи ключей и тщательно проверяет их перед тем, как подписывать.

ultimate (безоговорочное)

Владельцу данного ключа Вы верите как самому себе.

Уровень доверия ключу это то, что Вы присваиваете лично, и это Ваша частная информация. Она не экспортируется с ключом; она даже хранится отдельно от ключей в специальной базе данных.

Для присвоения уровня доверия владельцу ключа используется команда trust режима редактирования ключа. В этом примере Элис редактирует уровень своего доверия Блэйку и затем обновляет базу данных доверия, чтобы пересчитать достоверность ключей основываясь на новом значении доверия Блэйку.

alice% gpg --edit-key blake

pub  1024R/01A1FE63  created: 2002-05-01 expires: never      trust: -/f
sub  1024R/526C7F7F  created: 2002-05-01 expires: 2003-05-01
(1). Blake (dumb) <blake@anywhere.ru>

Command> trust
pub  1024R/01A1FE63  created: 2002-05-01 expires: never      trust: -/f
sub  1024R/526C7F7F  created: 2002-05-01 expires: 2003-05-01
(1). Blake (dumb) <blake@anywhere.ru>

Please decide how far you trust this user to correctly
verify other users' keys (by looking at passports,
checking fingerprints from different sources...)?

 1 = Don't know
 2 = I do NOT trust
 3 = I trust marginally
 4 = I trust fully
 5 = I trust ultimately
 i = please show me more information
 m = back to the main menu
 
Your decision? 3
                
pub  1024R/01A1FE63  created: 2002-05-01 expires: never      trust: m/f
sub  1024R/526C7F7F  created: 2002-05-01 expires: 2003-05-01
(1). Blake (dumb) <blake@anywhere.ru>

Доверие владельцу ключа и достоверность ключа выводятся справа от ключа, когда выводится ключ. Доверие владельцу выводится первым, достоверность ключа второй[5]. Пять уровней доверия/достоверности обозначаются символами: неизвестный (q), нет (n), граничный (m), полный (f), безоговорочный (u). В этом случае, ключ Блэйка полностью достоверен, т.к. Элис сама подписала его. Изначально установлено неизвестное доверие относительно правильности подписи Блэйком ключей, но Элис решает установить граничный уровень доверия.

Использование доверия для проверки достоверности ключей

Сеть доверия позволяет использовать весьма гибкий алгоритм для проверки достоверности ключа. Если прежде достоверными считались только те ключи, которые Вы подписали лично, то теперь используется следующий алгоритм. Ключ K считается достоверным, если он удовлетворяет следующим двум условиям:

  1. он подписан достаточным количеством достоверных ключей, т.е.

    • Вы подписали его лично (или обладатель ключа, которому Вы безоговорочно доверяете),

    • он был подписан ключом владельцу которого Вы полностью доверяете, или

    • он был подписан тремя ключами с граничным уровнем доверия владельцу; и

  2. цепочка подписанных ключей начинающаяся с K и заканчивающаяся Вашим ключом не длиннее пяти ключей.

Длина цепочки, число требуемых ключей с граничным уровнем доверия и число ключей с полным доверием может быть изменено при помощи параметров --max-cert-depth, --marginals-needed и --completes-needed. Цифры приведенные выше - значения используемые GnuPG по умолчанию.

Рисунок 3.1, Пример сети доверия рассмотрим сеть доверия начинающуюся с Элис. Граф иллюстрирует кто подписал чей ключ. Таблица показывает ключи, которые Элис признает достоверными основываясь на доверии другим членам сети. Этот пример предполагает, что для признания другого ключа достоверным требуется два ключа с граничным доверием или один с полным. Максимальная длина цепочки равна трем.

При вычислении достоверности ключей, в этом примере, ключи Блэйка и Дхармы всегда считаются полностью достоверными, т.к. они подписаны Элис. Достоверность других ключей зависит от доверия. В первом случае, доверие Дхарме полное, что делает ключи Хлой и Фрэнсиса полностью достоверными. Во втором случае, доверие Блэйку и Дхарме граничное. Т.к. два ключа с граничным доверием требуется для подтверждения достоверности ключа, ключ Хлой будет признан полностью достоверным, но достоверность ключа Фрэнсиса будет только частично подтверждена. В случае граничного доверия Хлой и Дхарме, ключ Хлой будет частично достоверен, а ключ Дхармы полностью достоверен. Ключ Фрэнсиса будет частично достоверен, т.к. только полностью достоверный ключ может быть использован для подтверждения достоверности других ключей, а единственный полностью достоверный ключ, которым подписан ключ Фрэнка, это ключ Дхармы. После добавления граничного доверия Блэйку ключ Хлой становится полностью достоверным и может быть использован для полного подтверждения достоверности ключа Фрэнсиса и частичного подтверждения достоверности ключа Елены. Наконец, если доверие Блэйку, Хлой и Елене полное, этого все еще не достаточно для подтверждения достоверности ключа Джефа, т.к. максимальная длина цепочки подтверждения равна трем, но путь от Джефа к Элис равен четырем.

Модель сети доверия реализует гибкий подход к проблеме безопасного обмена ключами. Она позволяет настраивать GnuPG в соответствии с Вашими потребностями. Вы можете требовать много коротких цепочек от Вашего ключа до ключа K для признания его достоверным. С другой стороны, Вы можете быть удовлетворены одной длинной цепочкой. Требование многочисленных коротких цепочек - сильная гарантия того, что ключ K принадлежит тому, на кого указывает его идентификатор пользователя. Цена за такую надежность, конечно, выше, т.к. Вы лично должны проверить и подписать большее количество ключей, чем в случае когда Вас устраивает небольшое число длинных цепочек.

Рисунок 3.1. Пример сети доверия

Граф, показывающий кто подписал чей ключ.
довериедостоверность
граничноеполноеграничнаяполная
 Дхарма Блэйк, Хлой, Дхарма, Фрэнсис
Блэйк, Дхарма ФрэнсисБлэйк, Хлой, Дхарма
Хлой, Дхарма Хлой, ФрэнсисБлэйк, Дхарма
Блэйк, Хлой, Дхарма ЕленаБлэйк, Хлой, Дхарма, Фрэнсис
 Блэйк, Хлой, Елена Блэйк, Хлой, Елена, Фрэнсис


[5] GnuPG перегружает слово ``доверие'' используя его в смысле доверия владельцу и в смысле доверия ключу. Это может вызвать путаницу. Иногда доверие владельцу указывается прямо. В основном, в этом руководстве, термин ``доверие'' используется в смысле доверия владельцу ключа и термин ``достоверность'' для обозначения уверенности в том, что ключ принадлежит человеку указанному идентификатором пользователя.


Распространение ключей Пред. Глава 3. Управление ключами  След.

Распространение ключей

В идеале, Вы распространяете Ваши ключи персонально передавая его Вашим корреспондентам. На практике, однако, ключи часто распространяются по электронной почте или другими способами электронной связи. Распространение по электронной почте хорошо когда Вы имеете только нескольких корреспондентов, если корреспондентов много, Вы можете разместить свой ключ на персональной веб-странице. Это не применимо, однако, если люди, которым нужен Ваш открытый ключ, не знают где найти его в сети.

Для решения этой проблемы используются серверы открытых ключей, которые собирают и распространяют открытые ключи. Открытый ключ либо добавляется к базе данных сервера, либо объединяется с существующим ключом, если такой существует. Когда на сервер приходит запрос ключа, сервер просматривает базу данных и, если находит, возвращает запрошенный ключ.

Серверы ключей также полезны когда многие люди часто подписывают ключи других людей. Без сервера ключей, когда Блэйк подписывает ключ Элис, он должен послать ей подписанную им копию ее открытого ключа, которую Элис может добавить к свому набору и передавать, затем, всем своим корреспондентам. Выполнение этих действий способствует построению плотных сетей доверия и повышению безопасности PGP. Однако они становятся помехой когда ключи подписываются часто.

Использование серверов ключей облегчает этот процесс. Когда Блэйк подписывает ключ Элис он посылает подписанный ключ на сервер ключей. Сервер ключей добавляет подпись Блэйка к своей копии ключа Элис. Те кто интересуется обновлением копии ключей Элис, по своей инициативе связываются с сервером ключей и получают оттуда обновленный ключ Элис. Элис не принимает участия в распространении ключа и может получить подписи на своем ключе просто запросив сервер.

Один или более ключей могут быть отправлены на сервер ключей командой --send-keys. В качестве аргумента указываются один или более спецификаторов ключей. Сервер ключей, которому будут переданы ключи задается опцией --keyserver. Аналогично, команда --recv-keys используется для получения ключей с сервера, но команде --recv-keys требуется идентификатор ключа. В следующем примере Элис обновляет свой открытый ключ с новыми подписями с сервера ключей certserver.pgp.com и затем посылает свою копию открытого ключа Блэйка на тот же сервер ключей для передачи своей подписи на нем.

alice% gpg --keyserver certserver.pgp.com --recv-key 0xBB7576AC
gpg: requesting key B115BDB6 from certserver.pgp.com ...
gpg: key B115BDB6: 1 new signature

gpg: Total number processed: 1
gpg:         new signatures: 1
alice% gpg --keyserver certserver.pgp.com --send-key blake@anywhere.ru
gpg: success sending to 'certserver.pgp.com' (status=200)

Существуют несколько популярных серверов ключей. Основные серверы ключей синхронизируются друг с другом, поэтому лучше выбрать ближайший к Вам и регулярно использовать его для отправки и получения ключей.


Глава 4. Повседневное использование GnuPG Пред.   След.

Глава 4. Повседневное использование GnuPG

$Id: c4.xml 5 2005-10-02 16:50:06Z zwon $

Содержание

Определение Ваших требований к защите
Выбор размера ключа
Защита Вашего секретого ключа
Выбор срока действия и использование дополнительных ключей
Управление Вашей сетью доверия.
Построение Вашей сети доверия
Законность использования GnuPG

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

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

Определение Ваших требований к защите

GnuPG инструмент для защиты Ваших секретов. Ваши секреты защищены если Ваши сообщения не доступны постороннему глазу.

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

Настройка GnuPG включает решение четырех задач:

  • выбор размера Вашей пары ключей,

  • защита Вашего секретного ключа,

  • выбор сроков действия ключей, и

  • управление Вашей сетью доверия.

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

Выбор размера ключа

Выбор размера ключа зависит от типа ключа. В OpenPGP, пара открытого/закрытого ключей обычно состоит из нескольких ключей. Как минимум в нее входит главный ключ для подписи, кроме того, обычно она содержит один или несколько дополнительных ключей для шифрования. При использовании при генерации ключа параметров по умолчанию, главный ключ будет DSA ключом, а подключи будут ElGamal ключами.

DSA допускает ключи длиной до 1024 бит. Это не слишком много, учитывая сегодняшнее развитие технологии, но это то, что описывает стандарт. Если Вы используете DSA ключи, то их длина должна быть 1024 бита.

ElGamal и RSA ключи могут быть любого размера. Т.к. GnuPG смешанная система, открытый ключ используется для зашифрования 128-битного сеансового ключа, а закрытый ключ используется для его расшифрования. Размер ключа влияет на скорость зашифрования и расшифрования, т.к. стоимость этих алгоритмов экспоненциальна относительно размера ключа. Большие ключи также требуют больше времени для генерации и больше места для хранения. Наконец, если ключ слишком велик для атаки в лоб, похититель просто прибегнет к другим методам, чтобы получить интересующие его данные. Примерами других методов являются ограбление Вашего дома или офиса, либо нападение лично на Вас. 1024 бит - рекомендуемый размер ключа. Если Вы действительно нуждаетесь в ключе большего размера, то скорее всего уже знаете об этом и должны проконсультироваться с экспертом по защите данных.

Защита Вашего секретого ключа

Защита секретного ключа одна из наиболее важных задач для надёжной работы GnuPG. Если кто-либо получит Ваш секретный ключ, то он сможет расшифровывать все направленные Вам сообщения и сможет подписываться Вашей подписью. Если Вы потеряете Ваш секретный ключ, то не сможете больше расшифровывать документы зашифрованные для Вас и не сможете подписывать свои сообщения. Потеря единственной копии Вашего секретного ключа катастрофична.

Независимо от того, как Вы используете GnuPG Вы должны сохранить сертификат отзыва открытых ключей и резервную копию Вашего секретного ключа на защищенный от записи носитель и хранить его в надежном месте. Например, Вы можете записать копии на компакт-диск и хранить его в банковском сейфе. Можно, также, записать их на дискету и спрятать ее дома. Чтобы Вы ни делали, копии должны быть скопированы на носитель, на котором они смогут надежно храниться на протяжении всего срока использования ключа, и их следует спрятать более тщательно, чем копию Вашего секретного ключа для ежедневного использования.

Чтобы защитить Ваш ключ, GnuPG не сохраняет его на диск в чистом виде. Вместо этого он шифруется симметричным алгоритмом. Вот зачем нужна ключевая фраза для доступа к ключу. Поэтому взломщик должен решить две проблемы, чтобы получить Ваш секретный ключ: (1) он должен получить ключ, (2) он должен расшифровать ключ.

Надежное хранение секретного ключа - сложная задача. В идеале, Вы должны хранить секретный ключ на сменном, защищенном от записи диске и использовать его только на на однопользовательской машине не подключенной к сети. Это может оказаться неудобным или невозможным для Вас. Например, у Вас может не быть своего компьютера и Вы используете компьютер на работе, или это может означать, что Вам прийдется отключать компьютер от сети каждый раз когда Вы запускаете GnuPG

Это не означает, что Вы не можете или не должны использовать GnuPG. Это означает только, что Вы считаете свои данные достаточно важными, чтобы шифровать, но не настолько важными, чтобы принимать особые меры предосторожности для усиления первого барьера защиты. Это Ваш выбор.

Хорошая ключевая фраза очень критична при использовании GnuPG. Любой взломщик, получивший Ваш секретный ключ, должен взломать шифр на секретном ключе. Вместо атаки в лоб, взломщик, наверняка, попробует угадать ключевую фразу.

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

Хорошая ключевая фраза такова, что Вы можете ее запомнить, но ее трудно подобрать. Она должна включать символы из всего диапазона печатных символов на вашей клавиатуре. Сюда входят алфавитные символы, в разных регистрах, цифры и специальные символы, такие как } и |. Проявите творческий подход и затратьте немного времени обдумывая ключевую фразу, хороший выбор важен для обеспечения Вашей секретности.

Выбор срока действия и использование дополнительных ключей

По умолчанию, когда Вы создаете новую пару ключей, генерируется главный ключ DSA для подписи и подчиненный ключ ElGamal для шифрования. Это удобно, т.к. роли двух ключей различны, и Вы можете пожелать, чтобы они имели различные сроки действия. Главный ключ для подписи используется для создания цифровых подписей, на нем, также, собираются подписи тех, кто подтверждает принадлежность ключа Вам. Ключ шифрования используется для расшифровки зашифрованных документов, отправленных Вам. Обычно, цифровая подпись имеет продолжительный срок действия, например, неограниченный, и Вы, также, не хотите утратить подписи на Вашем ключе, собранные с большим трудом. С другой стороны, подключ шифрования может периодически изменяться, что повысит безопасность, т.к. взломанный ключ шифрования позволит взломщику прочесть все документы зашифрованные для этого ключа, как в будущем, так и в прошлом.

Поэтому Вы почти всегда захотите оставить главный ключ с неограниченным сроком действия. Есть две причины по которым Вы можете ограничить срок действия ключа. Во-первых, Вам может понадобиться ключ на определенный период. Например, ключ будет использоваться во время избирательной кампании и не понадобится после ее окончания. Другая причина состоит в том, что если Вы теряете контроль над ключом и, при этом, не имеете сертификата отзыва, наличие срока действия гарантирует, что в конечном счете ключ станет недействителен.

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

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

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

Управление Вашей сетью доверия.

Как и защита Вашего секретного ключа, управление сетью доверия является тем аспектом использования GnuPG, который требует соблюдения баланса между защитой и легкостью использования. Если Вы используете GnuPG для защиты от случайного подслушивания и подделок, то можете позволить себе относительную легкость в доверии чужим подписям на ключах. С другой стороны, если Вы считаете, что кто-либо заинтересован в получении доступа к Вашим секретам, то Вам следует проявлять меньшее доверие в отношении чужих подписей и тратить больше времени на проверку ключей.

Независимо от Ваших личных потребностей в защите, Вы всегда должны быть внимательны подписывая чужие ключи. Подписывать ключ опираясь на собственные потребности в защите эгоистично. На Вашу подпись могут полагаться другие, чьи требования, возможно, более высоки. Если они не смогут полагаться на Вас, это ослабит сеть доверия и затруднит общение всего сообщества пользователей GnuPG. Используйте те же меры предосторожности, подписывая ключи, какие Вы хотели бы, чтобы принимали те, на чьи подписи полагаетесь Вы.

На практике, управление Вашей сетью доверия сведено к присвоению значения доверия некоторому минимальному числу других лиц и настройке параметров --marginals-needed и --completes-needed. Любой ключ, подписанный Вами лично, считается подтвержденным, но, кроме как для маленьких групп, не является практичным подписывать ключ каждого, с кем Вы переписываетесь. Вы будете, следовательно, должны полагаться на других.

Наиболее разумно, проявить аккуратность присваивая значения доверия и затем настроить опции, указывающие GnuPG строгость проверки ключей. Например, Вы можете полностью доверять узкому кругу друзей, которые, как Вы знаете, осторожны при подписи ключей, и незначительно доверять всем остальным, чьи ключи имеются в Вашей связке. Тогда, Вы можете установить значения --completes-needed равным 1 и --marginals-needed равным 2. Если Вы более осторожны, то можете выбрать значения 1 и 3 или 2 и 3 соответственно. Если Вы меньше озабочены секретностью и просто заинтересованы в некотором приемлемом подтверждении достоверности, установите значения 1 и 1. В целом, более высокие значения этих параметров означают, что большее число людей должны сговориться против Вас, чтобы получить подтвержденный ключ, не принадлежащий тому, кому Вы думаете.


Построение Вашей сети доверия Пред. Глава 4. Повседневное использование GnuPG  След.

Построение Вашей сети доверия

Одного желающего использовать GnuPG недостаточно. Для того, чтобы сообщаться защищенно с другими, Вы должны иметь сеть доверия. Построение сети доверия похоже на укрощение. Люди, с которыми Вы общаетесь, должны использовать GnuPG[6], и должно иметься достаточное количество подписанных ключей, чтобы ключи могли подтверждаться. Это не столько технические, сколько социальные проблемы. Однако, Вы должны преодолеть эти проблемы, если хотите использовать GnuPG.

Когда Вы начинаете использовать GnuPG, важно понять, что нет необходимости в защите переписки с каждым корреспондентом. Начните с небольшого круга людей, возможно только Вы и один или два Ваших товарища, тоже желающих реализовать свое право на тайну переписки. Создайте Ваши ключи и подпишите открытые ключи друг друга. Это Ваша начальная сеть доверия. Делая так, Вы оцените значение маленькой, надежной сети доверия и будете более осторожны в будущем, когда Ваша сеть станет расти.

В дополнение к этой начальной сети доверия, Вы можете захотеть конфиденциально переписываться с другими людьми, также использующими GnuPG. Реализация этого желания, однако, может оказаться неуклюжей по двум причинам: (1) Вы не всегда знаете, что человек использует или желает использовать GnuPG, и (2) если Вы и знаете, что человек использует его, могут возникнуть сложности с подтверждением ключей. Первая причина является следствием того, что люди не всегда объявляют о том, что используют GnuPG. Возможный вариант решения этой проблемы, подать пример и объявить, что Вы используете GnuPG. Есть как минимум три способа сделать это: Вы можете подписывать свои сообщения, Вы можете положить свой открытый ключ на своей веб-странице, Вы можете указать идентификатор Вашего ключа в подписи почтового сообщения. Если Вы сообщаете о своем ключе, то делаете более уместным для других сообщить об их ключах. Более того, Вашим корреспондентам будет проще начать с Вами переписываться конфиденциально, если Вы проявите инициативу и сделаете ясным использование Вами GnuPG.

Проверка правильности ключа более сложна. Если Вы не знакомы лично с человеком, чей ключ собираетесь подписать, то не можете подписать ключ сами. Вы должны опираться на чужие подписи и постараться найти цепочку подписей, начиная с ключа под вопросом и заканчивая Вашим. Для нахождения цепочки, Вы должны проявить инициативу и получить Ваш ключ подписанный кем-либо за пределами Вашей начальной сети доверия.

Имейте однако в виду, что все это в зависимости от потребностей. Вы не обязательно должны заявлять о своем ключе или подписывать чужие ключи. Сила GnuPG состоит в том, что он достаточно гибок и может быть адаптирован к Вашим потребностям, какими бы они не были. При этом действительность такова, что Вы должны проявлять инициативу, если хотите расширить свою сеть доверия и использовать GnuPG как можно больше.



[6] В этом разделе, GnuPG относится к GnuPG реализации OpenPGP также, как к другим реализациям, типа PGP произодимому NAI.


Законность использования GnuPG Пред. Глава 4. Повседневное использование GnuPG  След.

Законность использования GnuPG

Законодательный статус криптографических программ различен в разных странах, кроме того, законы, регулирующие использование криптографических средств, быстро меняются. Bert-Japp Koops сделал неплохую страничку Crypto Law Survey, к которой Вы можете обратиться, чтобы узнать законодательный статус криптографических программ в Вашей стране.


Глава 5. Различные вопросы Пред.   След.

Глава 5. Различные вопросы

$Id: c5.xml 5 2005-10-02 16:50:06Z zwon $

Содержание

Написание пользовательского интерфейса

Эта глава рассматривает различные вопросы которым не нашлось места в другом месте руководства. Добавленные вопросы могут собираться и распределяться по главам. Если Вы хотели бы увидеть освещенным некоторый вопрос, пожалуйста сообщите об этом. А еще лучше, напишите черновую версию, описывающую интересующий Вас вопрос!

Написание пользовательского интерфейса

Alma Whitten и Doug Tygar провели анализ пользовательского интерфейса PGP 5.0 и пришли к заключению, что начинающие пользователи находят PGP сложным и непонятным. По результатам их тестов, только четверо из двенадцати тестируемых правильно отправили зашифрованные сообщения членам их команды, и трое из двенадцати отправили секрет незашифрованным. При этом половина тестируемых прошли техническую подготовку.

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

Вам следует внимательно ознакомиться с выводами Whitten'а и Tygar'а если Вы пишете пользовательский интерфейс. Они дают комментарии по каждому из тестируемых. Например, оказалось, что многие верят, что сообщение посылаемое другим людям надо зашифровывать своим собственным открытым ключом. Задумайтесь над этим, и Вы поймете, что легко допустить такую ошибку. Как правило, начинающие пользователи испытывают трудности в понимании различий между открытым и закрытым ключами когда используют GnuPG. Как дизайнер пользовательского интерфейса, Вы должны постараться сделать выбор того или ключа прозрачным. Вы можете, также, использовать мастера и другие общепринятые приемы GUI для проведения пользователя сквозь основные задачи, такие как генерация ключа, дополненная генерацией сертификата отзыва ключа, и т.п. Из документа следуют, также, следующие выводы.

  • Безопасность, обычно является второстепенной задачей; люди хотят отправлять почту, просматривать и т.д. Не думайте что пользователи станут читать толстые руководства или разбираться в настройках шифрования.

  • Защита сетевого компьютера не сильнее самого слабого из ее компонентов. Пользователи должны быть осведомлены обо всех аспектах своей безопасности, не ограничиваясь частичными сведениями, как это может быть с текстовыми процессорами или электронными таблицами.

  • Всегда используйте одинаковые термины для одинаковых действий. Избегайте употребления синонимов, типа ``encrypt'' и ``encipher''.

  • Для неискушеных пользователей упростите вывод информации. Слишком большое количество информации скрывает ту, которая важна. Начальная конфигурация интерфейса должна обеспечить пользователя правильной моделью отношений между открытым и закрытым ключами и прозрачным пониманием функций получения и распространения ключей.

Разработка эффективного пользовательского интерфейса для управления ключами еще более сложна. Модель сети доверия OpenPGP, к сожалению, довольно трудна для понимания. Например, спецификация определяет три степени доверия пользователю: нет (none), относительное (marginal), и полное (сomplete). Все грани доверия, испытываемого пользователем, должны уместиться в эти три ячейки. Алгоритм подтверждения ключей также сложен для понимания не специалистов, особенно параметры ``marginals needed'' и ``completes needed''. Так как модель сети доверия четко определена и не может быть изменена, Вам прийдется постараться и разработать интерфейс, который поможет понять ее пользователю. Определенная функция, к примеру, могла бы отображать диаграмму того, как был подтвержден ключ, по запросу пользователя. Основные выводы следующие.

  • Пользователи могут оставаться в неведении относительно того, как и когда предоставить доступ.

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