Как gpg обрабатывает несколько ключей в паре ключей?

3375
jrdioko

Насколько я понимаю, пары ключей, используемые с gpg, обычно имеют более одного связанного ключа: один для подписи и один для шифрования. Как управляются эти несколько ключей при использовании gpg (для передачи на сервер ключей, получения чужого ключа, шифрования или подписи)? Будет ли он автоматически использовать правильный ключ для правильного действия или это то, что пользователь должен указать? Как определяется цель каждого ключа в ключевой паре?

2

1 ответ на вопрос

5
grawity

То, что часто называют «ключом GPG», больше похоже на сертификат . Как и в X.509, сертификат содержит гораздо больше информации, чем просто ключ (и): «первичная» пара ключей и несколько «подключевых» пар ключей, а также флаги их использования и даты истечения срока действия, а также несколько идентификаторов пользователей. и удостоверения личности с фотографией вместе с их подписями.

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

По умолчанию для шифрования данных создан хотя бы один подраздел «Шифрование». Вы можете иметь несколько таких подразделов - например, с разными датами истечения. Я не смог найти хорошего источника, но, похоже, для шифрования будет выбран самый новый действительный (после даты начала и не истек / отозван) подраздел. При расшифровке данных все подключы будут опробованы.

(Возможно, вы заметили, что gpg -kперечислены идентификаторы ключей как для ключей, так и для подразделов. Когда вам нужно принудительно использовать определенный ключ или подраздел, вы можете указать (идентификатор (ID) ключа с последующим восклицательным знаком), чтобы обойти все вычисления какой подраздел лучше.)keyid!

При желании вы можете добавить подключи, помеченные как разрешенные, в «Authenticate», которые затем можно использовать в таких протоколах, как SSH (через gpg-agent, путем извлечения необработанной пары ключей RSA) или SSL (реализованных GnuTLS в качестве альтернативы X.509). Какие подключи используются, зависит от конкретной реализации.

Вы можете увидеть полную структуру сертификата PGP, используя:

  • gpg --export mykey | gpg -vvv
  • gpg --export mykey | pgpdump
  • gpg --export mykey | certtool --pgp-certificate-info
Это дает хорошее понимание практических причин, лежащих в основе структуры группировки мастер-подраздел. Тем не менее, я все еще озадачен следующими ограничениями: Все отдельные ключи в одном сертификате master & subkey keyset | обязаны использовать один пароль. Это ужасно неудобно, так как использование каждого ключа отличается, и для всех них становится угрозой безопасности использовать один и тот же пароль. Для некоторых ключей предпочтительно не использовать пароль, как насчет этого случая? Craig Hicks 5 лет назад 0
Нет, технически это никогда не было правдой и больше не применяется в GnuPG 2.1 (из-за переноса секрета в gpg-agent, который даже не знает о связях ключ / подраздел). Вы можете использовать команду агента `PASSWD` для шифрования каждой отдельной пары ключей, хранящейся там, любым паролем, который вам нравится. grawity 5 лет назад 0
Кроме того, GnuPG (даже 1.x) всегда поддерживал «обрыв» определенных подразделов, обычно главного (сертификационного ключа), и хранение их на смарт-карте (Gnuk) или вообще нигде. Таким образом, вы можете очень легко иметь устройства, которые могут расшифровывать, но не сертифицировать. grawity 5 лет назад 0
Спасибо за указатель на ПАРОЛЬ gpg-connect-agent ' Пока я не знал, и это может быть полезно. Я знаю, что «технически» возможно даже в gpg1.x установить индивидуальный пароль для подключа: lists.gnupg.org/pipermail/gnupg-users/2013-July/047174.html. Тем не менее, при рассмотрении использования «технических» обходных функций с использованием внутренних методов, тестирование может быть скудным, а совместимость в будущем находится под угрозой. Без документации даже разработчики gnupg.org могут запутаться, если какое-то поведение является функцией или ошибкой: https://dev.gnupg.org/T1848. Craig Hicks 5 лет назад 0
Насколько я могу судить, в gpg2.1.11 пытаюсь отредактировать любой пароль с помощью --edit-key ! / passwd приводит к тому, что все сертифицированные пароли меняются на новые. Так что не совсем правильно говорить, что унифицированные пароли больше не применяются. Как минимум, должна присутствовать документация и предупреждение во время выполнения. Опять же, я ценю ваш ответ. Craig Hicks 5 лет назад 0
«все пароли сертификатов» -> «пароли каждого (под) ключа в соответствующем сертификате» Craig Hicks 5 лет назад 0

Похожие вопросы