/* В переводе не исключены ошибки Ссылка на оригинал - https://riseup.net/ru/security/message- ... -practices */
Лучшая практика OpenPGP
Содержание:
- Как использовать это руководство.
- Используйте бесплатное программное обеспечение и обновляйте его.
- Выбор сервера ключей и настройка вашего компьютера для обновления вашего брелка.
- Используйте sks пул серверов ключей, вместо одного конкретного сервера с безопасным соединением
- Убедитесь, что все ключи обновлены через выбранный вами сервер ключей.
- Обновляйте свои ключи медленно и по одному.
- Не слепо верьте в ключи, отправленные сервером ключей.
- Не полагайтесь на Key ID.
- Проверьте отпечаток ключа перед импортом.
- Конфигурация ключа.
- Используйте сильный первичный ключ.
- Задайте срок годности менее 2 лет.
- Установите событие календаря, чтобы напомнить себе о дате истечения срока действия
- Создайте сертификат аннулирования.
- Используйте только первичный ключ для сертификации (и, возможно, подписания). Имейте отдельный подключ (subkey) для шифрования.
- Имейте отдельный подключ (subkey) для подписания
- Держите основной ключ исключительно в автономном режиме
- Проверка ключа OpenPGP.
- Удостоверьтесь, что ваш ключ - OpenPGPv4
- Первичными ключами должны быть DSA-2 или RSA (предпочтительнее RSA), в идеале 4096 бит или более
- Самоподписи не должны использовать исключительно MD5
- Самоподписи не должны использовать SHA1
- Сформулированный дайджест алгоритмов предпочтений должен включать, по крайней мере, один член семейства SHA-2 с более высоким приоритетом, чем MD5 и SHA1
- Первичные ключи должны иметь разумную дату истечения срока действия (не более 2 лет в будущем)
- Собираем все воедино.
- Дополнительные советы.
- У вас есть зашифрованная резервная копия вашего секретного ключа?
- Не включайте «Комментарий» в свой идентификатор пользователя.
---------------------------------------------------------------------
1. Как использовать это руководство.
Мы собрали здесь много информации о настройке GnuPG. Здесь есть подробные объяснения для каждого изменения конфигурации. Многие из этих изменений требуют внесения правок в файл конфигурации GnuPG на вашем компьютере, расположенном в
~/.gnupg/gpg.conf
. Для вашего удобства все предложенные преобразования в файле
gpg.conf
собраны в одном месте в нижней части этой страницы. Мы настоятельно рекомендуем вам не слепо копировать файл, а читать документ и понимать, что делают настройки.
2. Используйте бесплатное программное обеспечение и обновляйте его.
Информационная безопасность слишком важна, поэтому не следует использовать проприетарное программное обеспечение. Вы должны использовать бесплатную реализацию OpenPGP и поддерживать ее в актуальном состоянии. Каноническая бесплатная реализация OpenPGP - это
GnuPG, и она доступна для каждой крупной современной операционной системы. Однако недостаточно просто установить GnuPG и забыть. Вы
должны держать пакет в актуальном состоянии, чтобы потенциально возможные уязвимости устаревшей версии были исправлены. У всего программного обеспечения есть ошибки, и GnuPG не является исключением. Если вы работаете на:
GNU / Linux (Debian, Ubuntu, Mint, Fedora и т. Д.)
ваша операционная система автоматически установит GnuPG и сохранит ее в актуальном состоянии для вас.
Windows
Вы можете установить
Gpg4win и
подписаться на gpg4win-announce, чтобы знать, когда нужно обновить программу.
Mac OS
Вы можете установить
GPG-пакет из GPGTools (откуда вы узнаете, когда вам нужно обновлять?).
Создание из исходников для любой другой операционной системы
Вы должны
подписаться на gnupg-announce, чтобы знать, когда нужно обновить программу.
3. Выбор сервера ключей и настройка вашего компьютера для обновления вашего брелка.
Если вы не регулярно обновляете свои открытые ключи, вы не получите очень важной и достойной внимания своевременной информации о истечении их срока действия или аннулирования! Для получения обновлений ключей есть два компонента. Многие пользователи отправляют свои обновления ключей на сервер ключей. Чтобы получать эти обновления, вы должны сначала убедиться, что используете сервер ключей, который функционирует правильно. Затем вы должны настроить свой компьютер для получения обновлений ключей обычным способом.
3.1 Используйте sks пул серверов ключей, вместо одного конкретного сервера с безопасным соединением
Большинство клиентов OpenPGP настраивают только один конкретный сервер ключей. Это нежелательно, потому что если сервер ключей потерпит неудачу (упадет) или, что еще хуже, если он будет работать, но работать не должным образом, вы не сможете получить обновления критических ключей. Мало того, что это единственная точка отказа, она также является основным источником утечки информации о взаимоотношениях между пользователями OpenPGP и, следовательно, целью атаки.
Поэтому мы рекомендуем использовать
sks пул серверов ключей. У машин в этом объединении регулярно проводятся проверки работоспособности, что гарантирует, что они функционируют должным образом. Если сервер работает некорректно, он автоматически удаляется из пула.
Вы также должны убедиться, что вы общаетесь с пулом серверов ключей по зашифрованному каналу, используя протокол hkps. Чтобы использовать hkps, вам сначала нужно установить gnupg-curl:
Затем, чтобы использовать этот пул серверов ключей, вам нужно
загрузить sks-keyservers.net CA и сохранить его где-нибудь на вашем компьютере. Пожалуйста, запомните путь, в который вы сохранили файл! Затем вы должны
проверить подлинность сертификата.
Теперь вам нужно будет использовать следующие параметры в
~/.gnupg/gpg.conf
и указать полный путь, в котором вы сохранили файл .pem выше:
Код: Выделить всё
keyserver hkps://hkps.pool.sks-keyservers.net
keyserver-options ca-cert-file=/path/to/CA/sks-keyservers.netCA.pem
Теперь ваши взаимодействия с сервером ключей будут зашифрованы через hkps, что скроет вашу личность от всех, кто может отслеживать ваш трафик. Например, если вы используете gpg -refresh-keys на сервере ключей (который использует только hkp), тогда кто-либо, отслеживая ваш трафик, увидит каждый ваш одиночный ключ, находящийся в вашей связке ключей (поскольку вы запрашиваете обновления для них). Это довольно интересная информация.
Примечание: hkps://keys.indymedia.org, hkps://keys.mayfirst.org и hkps://keys.riseup.net (хотя рекомендуется использовать пул вместо этого).
3.2. Убедитесь, что все ключи обновлены через выбранный вами сервер ключей.
При создании ключа люди могут назначить конкретный сервер ключей, чтобы использовать его для вытаскивания собственных ключей. Рекомендуется использовать следующий параметр
~/.gnupg/gpg.conf
, который будет игнорировать такие обозначения:
Это полезно, потому что (1) это помешает кому-либо установить небезопасный метод для вытаскивания ключа и (2), если назначенный сервер использует hkps, обновление не будет выполнено, потому что ca-cert будет не соответствовать, поэтому ключи никогда не будут обновлены. Также обратите внимание, что злоумышленник может назначить сервер ключей, который он контролирует, чтобы наблюдать, когда или где вы обновляете свой ключ.
3.3. Обновляйте свои ключи медленно и по одному.
Теперь, когда вы настроили хороший сервер ключей, вам нужно убедиться, что вы регулярно обновляете свои ключи. Лучший способ сделать это на Debian и Ubuntu - использовать parcimonie:
Parcimonie - это демон, который медленно обновляет ваш брелок от сервера ключей через
Tor. Он использует рандомизированное бездействие (сон) и новые цепочки Tor для каждого ключа. Цель состоит в том, чтобы усложнить для атакующего сопоставление обновлений ключей с вашим брелком.
Вам
не следует использовать
gpg -refresh-keys
или пункт меню «Обновить ключи» на вашем почтовом клиенте, потому что вы станете раскрыты для всякого "слушающего" и для оператора сервера ключей будет раскрыт весь набор ключей, которым вы интересуетесь с целью обновления.
3.4. Не слепо верьте в ключи, отправленные сервером ключей.
Любой пользователь может загрузить ключи на сервера ключей, и нет оснований полагать, что любой загружаемый вами ключ действительно принадлежит человеку, указанному в списке ключей. Поэтому вы должны проверить у каждого владельца
полный отпечаток их ключа. Вы должны выполнить эту проверку в реальной жизни или по телефону.
После того, как вы проверили требуемый ключевой отпечаток, вы можете загрузить ключ из пула серверов ключей:
Следующий шаг - это подтверждение того, что вы действительно получили корректный ключ от сервера ключей. Сервер ключей, возможно, дал вам другой ключ, а не тот, который вы только что попросили. Если у вас установлен gpg с версией менее 2.1, после этого вы должны вручную подтвердить отпечаток после того, как вы загрузили ключ (версии 2.1 и более поздние будут отказываться принимать неправильные ключи с сервера ключей).
Вы можете подтвердить ключевой отпечаток одним из двух способов:
Вариант 1. Проверьте, что отпечаток ключа теперь находится в вашем брелке:
Вариант 2. Попытайтесь (локально) подписать ключ с этим отпечатком:
Если вы уверены, что имеете правильный отпечаток от владельца ключа, тогда более предпочтительным методом является 2-й вариант. Если вы хотите публично афишировать свое подключение к человеку, которому принадлежит ключ, вы можете сделать его публично экспортируемым
--sign-key
.
Обратите внимание на одиночные кавычки выше ('), они должны окружать ваш полный отпечаток ключа и необходимы, чтобы эта команда работала. Двойные кавычки (") также работают.
3.5. Не полагайтесь на Key ID.
Короткие ID ключей OpenPGP, например 0×2861A790, имеют длину 32 бит. Они на опыте
показали, что могут быть легко подменены другим ключом с тем же ID. Длинные ID ключей OpenPGP (например, 0xA1E6148633874A3D) имеют длину 64 бит. Они
тривиально подделываются, что
также является потенциально серьезной проблемой.
Если вы хотите иметь криптографически-сильный ID ключа, вы должны использовать полный отпечаток. Вы никогда
не должны полагаться на короткий или даже длинный ID.
Вероятно, вы должны, как минимум, установить
keyid-format 0xlong
и
with-fingerprint
параметры gpg (вставьте их в
~/.gnupg/gpg.conf
), чтобы увеличить размер отображаемого ID до 64-бит при регулярном использовании и чтобы всегда отображать отпечаток.
Обратите внимание, что обнаружен
баг в enigmail, который исправлен в версии 1.7.0: если вы добавите параметр ‘with-fingerprint’ для отображения полных отпечатков, когда составляется список ключей, отпечаток ключа, отображаемый в окне управления ключами enigmail, будет являться подключом (subkey), а не отпечатком первичного ключа. Вы всегда можете найти отпечаток своего первичного ключа (например, если вы хотите отдать свой отпечаток кому-либо для проверки подписи ключа?). Чтобы отобразить отпечатки всех ваших секретных ключей, выполните:
3.6. Проверьте отпечаток ключа перед импортом.
Перед импортом любых полученных или загруженных ключей в свой брелок, вы можете и должны проверить их с помощью отпечатка, это защитит вас от скомпрометированных ключей и позволит не поломать ваш собственный:
4. Конфигурация ключа.
Теперь, когда вы знаете, как получать регулярные обновления ключей с хорошо проверенных серверов ключей, вы должны убедиться, что ваш ключ OpenPGP настроен оптимально. Многие из этих изменений могут потребовать от вас создания нового ключа.
4.1. Используйте сильный первичный ключ.
У некоторых людей все еще есть 1024-битные ключи DSA. Вам действительно нужно перейти на более сильную бит-длину и хэширование. В 2011 году правительство США установило, что NIST
осуждает DSA-1024, с 2013 года он даже
запрещен.
Рекомендуется сделать 4096-битный ключ RSA с помощью хэширующего алгоритма sha512, сделав
инструкцию перехода, подписанную обеими ключами, а затем сообщив людям. Также посмотрите на этот
хороший документ, в котором
подробно описаны шаги, необходимые для создания такого ключа, чтобы убедиться, что вы получаете правильный алгоритм хэширования (это может быть немного сложно, если вы используете версии GnuPG менее 1.4.10).
Переход может быть болезненным, но он того стоит, и это хорошая возможность попрактиковаться с инструментарием!
4.2. Задайте срок годности менее 2 лет.
Многие люди хотят, чтобы срок годности их ключей не истекал никогда, поэтому
делают их бессрочными. Зачем, это бессмысленно?
Вы всегда можете продлить срок действия, даже после того, как он истек! Это «истечение» на самом деле представляет собой скорее предохранительный клапан или «выключатель мертвой души», который автоматически срабатывает в какой-то момент. Смысл данной настройки - отключить ваш ключ, если вы потеряете к нему доступ (и не имеете сертификата аннулирования). Если у вас есть физический доступ к секретному ключу, вы можете его разблокировать.
Установка даты истечения срока означает, что вам нужно будет продлить эту дату в будущем. Это небольшая задача, которую вам нужно будет запомнить (см. Следующий пункт о настройке напоминания).
Вы можете думать, что это будет вас раздражать и что вы не хотите каждый раз обновлять дату, но на самом деле хорошо делать это на регулярной основе, чтобы ваши навыки OpenPGP были свежими. Это покажет пользователям, что ключ все еще активен, и что владелец ключа использует его. Кроме того, многие люди не будут подписывать ключ, который не имеет срока годности!
Если вы уже создали ключ без истечения срока действия, вы можете изменить дату истечения срока действия своего ключа, выполнив следующие действия:
Теперь выберите подключ (subkey), для которого вы хотите установить дату истечения срока действия (например, первый), или none (никакой?), чтобы установить срок действия вашего первичного ключа, а затем выполните команду ‘expire’:
Затем установите дату в пределах разумного, сохраните ключ и выйдите (например, 2 года):
Затем вы можете отправить свой ключ на сервер ключей, чтобы опубликовать это изменение:
4.3. Установите событие календаря, чтобы напомнить себе о дате истечения срока действия
Вы, скорее всего, забудете, поэтому лучше создать напоминание. Установите напоминание за месяц или раньше, чтобы вы могли внести изменения вовремя.
Помните: вы всегда можете продлить срок действия (даже после истечения срока его действия!), Поэтому вам не нужно создавать новый ключ, вам просто нужно продлить срок действия до более позднего времени. Делать это на регулярной основе полезно для тренировки OpenPGP знаний, иначе вы забудете что-либо.
4.4. Создайте сертификат аннулирования.
Если вы забудете свою кодовую фразу или если ваш закрытый ключ взломан или потерян, вы можете либо дождаться окончания срока действия ключа (это нехорошее решение), либо активировать ваш сертификат отзыва, опубликовав его на серверах ключей. Выполнение последнего будет уведомлять других о том, что этот ключ отменен.
Отключенный ключ все еще может быть использован для проверки старых подписей или дешифрования данных (если у вас все еще есть доступ к закрытому ключу), но он не может использоваться для шифрования новых сообщений.
Код: Выделить всё
gpg --output revoke.asc --gen-revoke '<fingerprint>'
Это создаст файл с именем revoke.asc. Вы можете распечатать бумажную копию сертификата для хранения в безопасном месте (передав его маме или поместив в резервные копии на внешнем сервере). Если кто-то получит доступ к сертификату, он сможет отменить ваш ключ, что очень неловко, но если он также имеет доступ к вашему закрытому ключу, то это именно то, чего вы не хотите.
4.5. Используйте только первичный ключ для сертификации (и, возможно, подписания). Имейте отдельный подключ (subkey) для шифрования.
Это делается по умолчанию в GnuPG 1.4.18 (и, возможно, раньше) и в более высоких версиях. Если вы создали свой ключ со старыми реализациями OpenPGP, вам может понадобиться создать новые подключи (subkey), используя те же инструкции, что и для подписания, см. ниже.
4.6. Имейте отдельный подключ (subkey) для подписания
По умолчанию GnuPG использует тот же подключ (subkey) для подписания (например, подписание сообщения электронной почты) и удостоверения (например, подписание другого ключа). Полезно отделить эти цели, поскольку один из них более важен, чем другой.
В этом случае ваш первичный ключ используется только для сертификатов, которые происходят нечасто.
Создать новый подключ (subkey) можно в диалоговом окне
--edit-key
, используя команду
addkey
. Во время диалога вы можете выбрать “capability” (умение) ключа ...
4.7. Держите основной ключ исключительно в автономном режиме
Это сложно сделать, но это поможет защитить очень важный первичный ключ. Если ваш первичный ключ украден, злоумышленник может создавать новые личности, отзывать существующие и полностью олицетворять вас. Таким образом, сохранение ключей «в автономном режиме» - хороший способ защиты от таких атак.
Перед тем, как это сделать, убедитесь, что вы создали отдельный ключ подписи, иначе вы не сможете подписывать электронные письма без вашего автономного ключа.
Извлечение первичного ключа является сложным, но это должно вам помочь :
Код: Выделить всё
# Извлекаем первичный ключ
gpg -a --export-secret-key john.doe@example.com > secret_key
# Извлекаем subkeys, который мы будем импортировать позже
gpg -a --export-secret-subkeys john.doe@example.com > secret_subkeys.gpg
# *удаляем* секретный ключ из брелка, поэтому остаются только subkeys
$ gpg --delete-secret-keys john.doe@example.com
Delete this key from the keyring? (y/N) y
This is a secret key! - really delete? (y/N) y
# Повторно импортируем subkeys
$ gpg --import secret_subkeys.gpg
# Проверяем все ли в порядке
$ gpg --list-secret-keys
# Удаляем subkeys
$ rm secret_subkeys.gpg
Затем вам нужно поместить файл
secret_key
в автономный режим, возможно, на флэш-накопитель, который вы всегда носите с собой, или в охраняемом сейфе. Другие будут использовать смарт-карты для хранения ключа и сохранения их с помощью физического брелка. Безопасность этого устройства будет защитой вашего ключа.
Опять же, убедитесь, что у вас есть сертификат аннулирования.
Вы можете убедиться, что данные о секретном ключе отсутствует, запустив
--list-secret-keys
, который cделает "потерянные" данные с
sec#
вместо вместо
sec
(???).
Примечание: в некоторых экзотических ситуациях
--delete-secret-keys
может не полностью удалить данные секретного ключа, а
--list-secret-keys
будет показывать
sec
вместо
sec#
. В этом случае вы можете переместить каталог
.gnupg
из директории, а не запускать
--delete-secret-keys
. Вам, конечно, нужно будет повторно импортировать ваши trustdb (базы данных доверия) и открытые ключи, которые будут выглядеть примерно так:
Код: Выделить всё
Вместо gpg --delete-secret-keys john.doe@example.com, сделайте следующее:
$ mv .gnupg .gnupg.bak
# повторно импортируйте subkeys
$ gpg --import secret_subkeys.gpg
# проверьте все ли в порядке
$ gpg --list-secret-keys
# удалите subkeys с диска
$ rm secret_subkeys.gpg
# повторно импортируйте открытый брелок
$ gpg --homedir .gnupg.bak --export | gpg --import
# повторно импортируйте trust db (базы данных доверия)
$ gpg --homedir .gnupg.bak --export-ownertrust | gpg --import-ownertrust
# удалите резервный каталог GPG для того, чтобы очистить *все* секретные ключи
$ rm -rf .gnupg.bak
Наконец, обратите внимание, что в приведенных выше манипуляциях данные о секретном ключе хранятся в открытом доступе на диске. Вы можете безопасно удалить эти файлы (используя, например,
nwipe
) вместо использования простой
rm
, для удаления данных закрытого ключа. Учтите, что современные диски, такие как SSD, поддерживают расширенную прошивку, которая может не подчиняться таким командам, оставив следы данных секретного ключа на диске. В этом случае лучшей защитой является использование полного шифрования диска.
Обратите внимание, что эти процедуры могут изменяться с версии на версию. См.
это обсуждение или
эту статью, или
это руководство, разработанное для GnuPG 2.x и выше.
4.8. Проверка ключа OpenPGP.
Существует удобный инструмент, который будет выполнять проверку ключей в дальнейшем для вас. Вы можете получить его из
источников, или если вы используете Debian или Ubuntu, вы можете установить пакет напрямую, выполнив:
Чтобы запустить эти тесты с помощью данного инструмента, вы можете сделать следующее:
Код: Выделить всё
hkt export-pubkeys '<fingerprint>' | hokey lint
В выходных данных любые проблемы с вашим ключом будут отмечены красным цветом. Если все зеленое, ваш ключ проходит каждый из приведенных критериев. В противном случае, ваш ключ не прошел один из перечисленных ниже тестов, и вы должны исправить его или сгенерировать новый ключ после проверки того, что ваш
gpg.conf
настроен в соответствии с рекомендациями.
4.8.1. Удостоверьтесь, что ваш ключ - OpenPGPv4
Согласно
RFC4880: «Ключи V3 устарели. Они содержат три недостатка. Во-первых, относительно легко создать ключ V3, который имеет тот же идентификатор ключа, что и любой другой ключ, потому что идентификатор ключа содержит все 64 бита общего модуля. Во-вторых, поскольку отпечаток ключа V3 хэширует ключевой материал, но не его длину, появляется возможность наступления противоречий с отпечатками. В-третьих, в алгоритме хеша MD5 есть недостатки, которые заставляют разработчиков отдать предпочтение другим алгоритмам. См. ниже подробное обсуждение ключевых идентификаторов и отпечатков ключей "
Чтобы определить, является ли ваш ключ ключом V3, вы можете сделать следующее:
Код: Выделить всё
gpg --export-options export-minimal --export '<fingerprint>' | gpg --list-packets |grep version
4.8.2. Первичными ключами должны быть DSA-2 или RSA (предпочтительнее RSA), в идеале 4096 бит или более
Чтобы проверить, используете ли вы DSA-2 или RSA, вы можете сделать следующее:
Код: Выделить всё
gpg --export-options export-minimal --export '<fingerprint>' | gpg --list-packets | grep -A2 '^:public key packet:$' | grep algo
Если результат равен 1, вы используете RSA. Если это 17, то это DSA, и вам нужно будет подтвердить, что размер, указанный в следующей проверке, сообщает размер ключа бит длины больше 1024, в противном случае вы не используете DSA-2.
Если зарегистрированный алгоритм равен 19, вы используете ECDSA, если это 18, вы используете ECC, а проверка определения длины бит ключа ниже не является подходящим критерием для этих типов ключей, так как размеры ключей значительно уменьшатся.
Чтобы проверить длину бит первичного ключа, вы можете сделать это:
Код: Выделить всё
gpg --export-options export-minimal --export '<fingerprint>' | gpg --list-packets | grep -A2 'public key' | grep 'pkey\[0\]:'
4.8.3. Самоподписи не должны использовать исключительно MD5
Вы можете проверить это, выполнив:
Код: Выделить всё
gpg --export-options export-minimal --export '<fingerprint>' | gpg --list-packets | grep -A 2 signature | grep 'digest algo'
Если вы видите, что результаты ‘digest algo 1’ напечатаны, тогда у вас есть собственные подписи, которые используют MD5, так как digest algo 1 - MD5. См.
OpenPGP RFC 4880, раздел 9.4 для таблицы, которая отображает алгоритмы хеширования для чисел.
Чтобы исправить это, во-первых, вы должны установить следующее в своем
~/.gnupg/gpg.conf
:
Во-вторых, вы должны создать новую собственную подпись на вашем ключе (например,
изменив дату истечения срока действия ключа).
4.8.4. Самоподписи не должны использовать SHA1
Вы можете проверить это, выполнив:
Код: Выделить всё
gpg --export-options export-minimal --export '<fingerprint>' | gpg --list-packets | grep -A 2 signature | grep 'digest algo 2,'
Если отобразились любые результаты ‘digest algo 2’, тогда у вас есть собственные подписи, которые используют SHA1, так как digest algo 2 - это SHA1. См.
OpenPGP RFC 4880, раздел 9.4 для таблицы, которая отображает алгоритмы хеширования для чисел.
Чтобы исправить это, вы можете создать новую собственную подпись на своем ключе (например,
изменив дату истечения срока действия ключа) после установки в своем
~/.gnupg/gpg.conf
:
4.8.5. Сформулированный дайджест алгоритмов предпочтений должен включать, по крайней мере, один член семейства SHA-2 с более высоким приоритетом, чем MD5 и SHA1
Вы можете проверить это, выполнив:
Код: Выделить всё
gpg --export-options export-minimal --export '<fingerprint>' | gpg --list-packets | grep 'pref-hash-algos'
а затем проверив результаты. Порядок предпочтений основан на том, какое число приходит первым слева направо. Если вы лицезреете цифры ‘3’, ‘2’, или ‘1’, прежде чем вы увидите ‘11’, ‘10’, ‘9’ или ‘8‘, вы указали свои предпочтения в пользу ослабленного алгоритма дайджеста
Чтобы исправить это, сначала установите следующее в своем
~/.gnupg/gpg.conf
:
Код: Выделить всё
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed
затем задайте настройки на своем ключе следующим образом:
Код: Выделить всё
$ gpg --edit-key '<fingerprint>'
gpg> setpref
...
gpg> save
4.8.6. Первичные ключи должны иметь разумную дату истечения срока действия (не более 2 лет в будущем)
Вы можете проверить, каковы даты истечения срока действия, выполнив следующие действия:
Код: Выделить всё
gpg --export-options export-minimal --export '<fingerprint>' | gpg --list-packets | grep 'key expires after'
Затем визуально проверьте, какие результаты подтвердят это - указанная дата будет относиться к созданию ключа, хотя это может быть трудно интерпретировать.
Еще один способ проверить срок действия:
Который должен показывать даты создания и истечения срока действия первичного ключа и каждого связанного подключа. Если вы не видите ничего, что говорит «истекает» в этом выходных данных, то вы не установили срок годности должным образом.
Чтобы исправить это, вы можете сделать следующее:
Код: Выделить всё
$ gpg --edit-key '<fingerprint>'
gpg> expire
...
gpg> save
5. Собираем все воедино.
Все рекомендованные настройки, описанные в этом руководстве, были объединены в один конфиг
daraconf от Jacob Appelbaum «Сборник закаленных файлов конфигурации». Вы можете
щелкнуть правой кнопкой мыши по этой ссылке и сохранить gpg.conf в
~/.gnupg/gpg.conf
(Linux и MacOS). Для пользователей Windows файл gpg.conf должен быть сохранен в
AppData\GnuPG\
.
mkdir ~/.gnupg/
nano ~/.gnupg/gpg.conf
Код: Выделить всё
#
# Это реализация Лучшей практики OpenPGP от сайта Riseup
# https://help.riseup.net/en/security/message-security/openpgp/best-practices
#
#-----------------------------
# default key (ключ по умолчанию)
#-----------------------------
# Дефолтный ключ для подписания. Если эта опция не используется, ключ по умолчанию
# это первый ключ, обнаруженный в секретной связке
#default-key 0xD8692123C4065DEA5E0F3AB5249B39D24F25E3B6
#-----------------------------
# behavior (поведение)
#-----------------------------
# Отключить добавление строки с версией в ASCII защищенном выводе
no-emit-version
# Отключить строку комментария в текстовых подписях and ASCII защищеных сообщениях
no-comments
# Отображать ID длинных ключей
keyid-format 0xlong
# Перечислять все ключи (или только указанные) вместе с их отпечатками
with-fingerprint
# Отображать вычисленную достоверность ID пользователей во время
# перечесления (составления списка) ключей
list-options show-uid-validity
verify-options show-uid-validity
# Попробуйте использовать GnuPG-Agent. С помощью этой опции, GnuPG сначала попытается
# подключиться к агенту, прежде чем он попросит ввести ключевую (парольную) фразу.
use-agent
#-----------------------------
# keyserver (сервер ключей)
#-----------------------------
# Это сервер, с которым будет осуществляться связь при использовании
# --recv-keys, --send-keys, и --search-keys
# чтобы получать, отправлять и искать ключи
keyserver hkps://hkps.pool.sks-keyservers.net
# Предоставить хранилище сертификатов для переопределения системного значения по умолчанию
# Получать из https://sks-keyservers.net/sks-keyservers.netCA.pem
keyserver-options ca-cert-file=/usr/local/etc/ssl/certs/hkps.pool.sks-keyservers.net.pem
# Установить прокси для использования HTTP и HKP-серверов ключей - по умолчанию используется
# стандартный локальный прокси-сервер Tor socks
# Рекомендуется использовать Tor для улучшения анонимности. Предпочтительно использовать либо
# выделенный SOCKSPort для GnuPG и/или включенный IsolateDestPort и
# IsolateDestAddr
#keyserver-options http-proxy=socks5-hostname://127.0.0.1:9050
# Не допустить утечки DNS, когда используем Tor
# см. https://trac.torproject.org/projects/tor/ticket/2846
keyserver-options no-try-dns-srv
# При использовании --refresh-keys, если у соответствующего ключа есть предпочтительный
# URL-адрес сервера ключей, отключить использование этого предпочтительного
# keyserver-а для обновления ключа
keyserver-options no-honor-keyserver-url
# При поиске ключа с помощью --search-keys, включать ключи, отмеченные
# на сервере как отмененные (revoked)
keyserver-options include-revoked
#-----------------------------
# algorithm and ciphers (алгоритм и шифры)
#-----------------------------
# список личных настроек дайджеста. Когда несколько дайджестов поддерживаются
# всеми получателями, выберите самый сильный
personal-cipher-preferences AES256 AES192 AES CAST5
# список личных настроек дайджеста. Когда множественные шифры поддерживаются
# всеми получателями, выберите самый сильный
personal-digest-preferences SHA512 SHA384 SHA256 SHA224
# алгоритм дайджеста сообщений, используемый при подписании ключа
cert-digest-algo SHA512
# Этот список предпочтений используется для новых ключей и становится
# значением по умолчанию для "setpref" в меню редактирования
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed
Вам необходимо будет раскомментировать и/или настроить следующие параметры для ваших личных предпочтений:
default-key
,
keyserver-options ca-cert-file
и
keyserver-options http-proxy
.
6. Дополнительные советы.
6.1. У вас есть зашифрованная резервная копия вашего секретного ключа?
Дважды проверьте его.
6.2. Не включайте «Комментарий» в свой идентификатор пользователя.
Если вы считаете, что вам нужно поле «Комментарий» в вашем ID пользователя OpenPGP,
подумайте долго и упорно еще раз, прежде чем принимать решение, что это действительно так. Вам, вероятно, это не нужно, а также наличие поля комментариев затрудняет людям понимание того, что они утверждены.