Перевод статьи: GPG Quickstart
Автор: Эндрю Бикхоф (Andrew Beekhof)
Оказалось кстати, что мне нужно было одновременно освежить знания о GPG и обновить ключи. Я собрал свой опыт (и источники) в тексте ниже, на случай если это окажется кому-то полезным:
Следующие настройки обеспечат, чтобы все ключи, создаваемые в дальнейшем, строго соответствовали стандартам 2013 года. Поместите эти настройки в файл ~/.gnupg/gpg.conf:
# Если все адресаты поддерживают несколько алгоритмов хэширования, выбирать самый надёжный из них: personal-digest-preferences SHA512 SHA384 SHA256 SHA224 # Предпочтения для новых ключей должны учитывать приоритет алгоритмов, в соответствии с их надёжностью: default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 BZIP2 ZLIB ZIP Uncompressed # При создании сертификата OpenPGP использовать наиболее надёжный алгоритм хэширования, # а не алгоритм SHA1, который используется по умолчанию: cert-digest-algo SHA512
Следующая порция настроек не обязательна, но полезна для улучшения вывода команд gpg в различных ситуациях - в частности, для защиты от подделки. Их тоже нужно поместить в ~/.gnupg/gpg.conf:
# При выводе сертификатов показывать идентификатор пользователя, выделенный из ключей: fixed-list-mode # Длинные идентификаторы ключей более защищены от коллизий, чем короткие идентификаторы ключей # (можно легко создать ключ с любым желаемым коротким идентификатором ключа): keyid-format 0xlong # Если вы пользуетесь графической средой (и даже если не пользуетесь ей), вам нужно использовать агента # (похожие аргументы в пользу этого приведены по ссылке https://www.debian-administration.org/users/dkg/weblog/64): use-agent # Взглянув на идентификатор пользователя, вы всегда должны знать, что по мнению gpg он является доверенным, # т.к. ключ присутствует в вашем брелоке: verify-options show-uid-validity list-options show-uid-validity # Включить недвусмысленный индикатор ключа, которым сделана подпись # (см. http://thread.gmane.org/gmane.mail.notmuch.general/3721/focus=7234): sig-notation issuer-fpr@notations.openpgp.fifthhorseman.net=%g
Существует несколько проверок для принятия решения о том, хорош ли ваш старый ключ (или ключи). Однако, если вы создали ключ больше чем пару лет назад, тогда возможно вам действительно нужен новый.
Я воспользовался инструкциями из статьи Анны Гереро (Ana Guerrero), которые были основой текущего руководства Debian, но выбрал тип ключа по умолчанию в соответствии со стандартами 2013 года:
С этого момента мой брелок gpg --list-keys выглядит следующим образом:
pub 4096R/0x726724204C644D83 2013-06-24 uid [ultimate] Andrew Beekhof <andrew@beekhof.net> sub 4096R/0xC88100891A418A6B 2013-06-24 [expires: 2015-06-24]
Как и у большинства людей, у меня есть несколько адресов электронной почты и я хочу использовать GPG и с ними тоже. Поэтому сейчас самое время добавить их к ключу. Для этого нужно воспользоваться командой gpg --edit-key. У Анны есть хороший пример добавления идентификаторов пользователей и настройки предпочтений. Просто поищите в её инструкциях текст "Add other UID" - "Добавить другой идентификатор пользователя".
Общепринято использовать отдельные ключи для подписывания и шифрования.
Коротко: бывает нужно что-то зашифровать, не подписывая, поскольку подписание может повлечь за собой юридически последствия. Также существует вероятность, что подписанные сообщения могут быть использованы для взлома зашифрованных данных.
По умолчанию gpg создаёт подключ для шифрования, но я воспользуюсь руководством Debian по субключам, чтобы создать ещё один для подписания (вместо того, чтобы использовать секретный мастер-ключ).
Это позволит сделать ваш секретный мастер-ключ ещё более защищённым, избегая его повседневного использования.
Идея заключается в том, чтобы сначала создать копию и сохранить её в ещё более безопасном месте так, что если подключ (и компьютер, где он находится) будут взломаны, мастер-ключ оставался бы в безопасности и им бы всё равно можно было бы отозвать подключи и создать новые.
Если ваш ключ старый, то им можно подписать новый ключ. Это даст знать всем, кто доверяет старому ключу, что новый ключ законный и поэтому ему можно доверять.
Вернёмся снова к советам Анны. Делается это так:
gpg --default-key СТАРЫЙ-КЛЮЧ --sign-key НОВЫЙ-КЛЮЧ
В моём случае команда будет такой:
gpg --default-key 0xEC3584EFD449E59A --sign-key 0x726724204C644D83
Сообщим людям, что они могут проверять вашу подпись и отправлять вам зашифрованные сообщения:
gpg --send-key 0x726724204C644D83
Как и в моём случае, вы можете перестать пользоваться каким-то из адресов электронной почты, указанных в старом ключе. Вы не можете удалить адреса из ваших ключей, но вы можете сообщить людям, чтобы они прекратили его использовать.
Чтобы сделать это с моим старым ключом, я воспользуюсь инструкциями из списка рассылки gnupg.
При поиске старого ключа всё выглядит по-прежнему:
pub 1024D/D449E59A 2007-07-20 Andrew Beekhof <beekhof@mac.com>
Andrew Beekhof <abeekhof@suse.de>
Andrew Beekhof <beekhof@gmail.com>
Andrew Beekhof <andrew@beekhof.net>
Andrew Beekhof <abeekhof@novell.com>
Fingerprint=E5F5 BEFC 781F 3637 774F C1F8 EC35 84EF D449 E59A
Но если заглянуть в детали ключа, можно увидеть, что адреса в Novell/SuSE в данное время отмечены красными символами revok.
pub 1024D/D449E59A 2007-07-20
Fingerprint=E5F5 BEFC 781F 3637 774F C1F8 EC35 84EF D449 E59A
uid Andrew Beekhof <beekhof@mac.com>
sig sig3 D449E59A 2007-07-20 __________ __________ [selfsig]
uid Andrew Beekhof <abeekhof@suse.de>
sig sig3 D449E59A 2007-07-20 __________ __________ [selfsig]
sig revok D449E59A 2013-06-24 __________ __________ [selfsig]
...
Таким образом другие люди, имеющие копию gpg, узнают, что больше не нужно использовать этот адрес. Вот почему важно периодически обновлять свои ключи.
В реальности вы вряд ли захотите, чтобы люди, использующие старые и потенциально взломанные ключи, продолжали слать вам деликатные сообщения. Поэтому лучше отозвать весь ключ.
Поскольку ключи не могут быть удалены после того, как были загружены на сервер, на самом деле мы обновим существующую запись. Чтобы сделать это, нам понадобится исходный секретный ключ - поэтому держите его в безопасном месте!
Некоторые люди советуют заранее создать отзыв ключа, однако лично мне это кажется просто ещё одной сущностью, за которой нужно постоянно следить.
Осиротевшие ключи, которые не могут быть отозваны, продолжают оставаться действующими для любого, кто захочет отправить вам защищённое сообщение - хорошая причина задать более раннюю дату окончания действия ключа!
Вот как выглядит один из моих старых отозванных ключей:
pub 1024D/DABA170E 2004-10-11 *** KEY REVOKED *** [not verified]
Andrew Beekhof (SuSE VPN Access) <andrew@beekhof.net>
Fingerprint=9A53 9DBB CF73 AB8F B57B 730A 3279 4AE9 DABA 170E
Мой новый ключ:
pub 4096R/4C644D83 2013-06-24 Andrew Beekhof <andrew@beekhof.net>
Andrew Beekhof <beekhof@mac.com>
Andrew Beekhof <abeekhof@redhat.com>
Fingerprint=C503 7BA2 D013 6342 44C0 122C 7267 2420 4C64 4D83
Я не специалист по этой теме, поэтому буду очень признателен, если вы сообщите мне о любых возможных ошибках в этой статье.