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

Question

Я несколько озадачен поведением, которое я вижу в GnuPG 2.0.30.

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

pub  4096R/0xDEADBEEF0000F00D  created: 2000-01-01  expires: never       usage: C
                               trust: ultimate      validity: ultimate
sub  4096R/0xFEEDFEEDFEEDF00D  created: 2000-01-01  expires: never       usage: E

Как видите, ни у основного, ни у подключа не было включено использование S

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

Это работало нормально, и, конечно же, я теперь видел SC как использование для первичного ключа.

pub  4096R/0xDEADBEEF0000F00D  created: 2000-01-01  expires: never       usage: SC
                               trust: ultimate      validity: ultimate
sub  4096R/0xFEEDFEEDFEEDF00D  created: 2000-01-01  expires: never       usage: E

Однако каждый раз, когда я обновляю открытый ключ с сервера ключей (я использую eu.pool.sks-keyservers.net), я в конечном итоге получаю использование S из моего первичного ключа.

Итак, вот вопрос: как я могу снова включить использование S (подписи) для первичного ключа.

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

Answer 1

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

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

Но как ключ может "потерять" уже установленную возможность подписи только потому, что вы получили обновление из сети сервера ключей? Сообщения OpenPGP, а также файлы ключей создаются из более мелких объектов, пакетов OpenPGP. Ключ, например, состоит из пакетов, определяющих фактические ключи (номера которых определяется ключ), вместе с идентификаторами пользователей, сертификатами и уже упомянутыми специальными сигнатурами конфигурации. Когда вы обновляете ключ, эти отдельные пакеты объединяются вместе. В случае конфликтов (например, разные сигнатуры конфигурации) побеждает самая новая.

В вашем случае я подозреваю, что в сети сервера ключей у вас есть пакет конфигурации с более новой отметкой времени, а на вашем компьютере - более старая. Должно быть, это было сгенерировано кем-то, имеющим доступ к вашему секретному ключу, поэтому, скорее всего (и, надеюсь, это), это был вы. Вы можете проверить мои предположения, запустив gpg --export <key-id> | gpg --list-packets до и после получения обновлений и поиска строк, содержащих определения key flags . Это битовое поле, определенное в OpenPGP, RFC 4880, 5.2.3.21.Ключевые флаги . Например, мой собственный ключ имеет флаг ключа 3 (двоичный код 11), что означает, что он имеет возможность сертификации (двоичный код 01) и подписи (двоичный код 10).

0x01 - This key may be used to certify other keys.
0x02 - This key may be used to sign data.
0x04 - This key may be used to encrypt communications.
[snip]

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