Редактирование закрытого ключа

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

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

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

Ещё у этого есть такой эффект: есть у меня вполне себе настроенный (предпочтения алгоритмов, сервера etc) ключ. Экспортирую отдельно открытую и закрытую его части, потом их же импортирую на другую связку. На новой связке у каждого uid`а будет по две подписи ("настроенная" от открытого ключа и "первоизданная" от закрытого).

И в этом нет ничего удивительного. Любые изменения, которые Вы вносите в сертификат ключа, заверяются закрытым ключом в пакете автоподписи (self-signature, чтобы гарантировать, что Вы эти изменения санкционировали; собственно, в этом пакете предпочтения и фиксируются). Так вот эти пакеты накапливаются на ключе на связке и на серверах ключей. Это "фича" протокола, и уж точно не баг. Просто любая OpenPGP-совместимая программа будет использовать именно те предпочтения, которые заверены самой новой подписью. Всё это позволяет, к примеру, продлевать срок действия ключа (expiry date), даже если он был жёстко установлен при его генерации.

Наверное вопрос сюда. Если открытый ключ содержит несколько подключей шифрования, можно ли в GPG выбрать, каким подключом зашифровать сообщение? Я пробовал указывать получателя через -u [четырехбайтовый индикатор ключа], получатель определялся верно, но для шифрования всегда использовался последний сгенерированый подключ. А где-то в форуме было сказано, что если на связке несколько подключей, то можно осуществлять их ротацию. Или это было благое пожелание к разработчикам?

Если открытый ключ содержит несколько подключей шифрования, можно ли в GPG выбрать, каким подключом зашифровать сообщение?

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

Если открытый ключ содержит несколько подключей шифрования, можно ли в GPG выбрать, каким подключом зашифровать сообщение?

Делается так:

gpg -u [subkeyID]! ...

Обратите внимание на восклицательный знак в конце (а может быть он должен быть в начале, перед ID? Не помню, попробуйте, если не сработает, как указал).

У меня сработало только через -r, но не с -u
echo "aaa" | gpg --armor -e -r [subkeyID]!

Да, разумеется, cooshoo ведь говорил о шифровании, а не о подписи данных, а я тупо повторил параметр из его сообщения (у него тоже ошибка).

(у него тоже ошибка)

Есть такая буква... :)
Большое спасибо за ответ.

В связи с требованием выдачи в Англии ключей шифрования, нельзя ли использовать такую возможность для PFS (Perfect Forward Secrecy)?

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

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

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

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

Путаницу с подключами (или сертификатами X.509) можно решить с помощью периодов действия: скажем, первый подключ действует с начала этой недели до её конца, второй – с начала следующей до её конце, третий – с начала последующей до её конца и так далее. Главное, чтобы периоды не накладывались друг на друга.

Для ключей OpenPGP вижу только одну существенную проблему: даже при использовании 1024-битовых подключей спустя короткое время весь пакет ключа раздуется непомерно. Если бы ещё допозитарии умели отбрасывать подключи, аннулированные некоторое время назад...

Кстати, в чём-то подобную схему предлагает Ben Laurie (из OpenSSL) в качестве PFS-расширения к OpenPGP. Только оно появится не раньше, чем начнётся разработка формата ключей OpenPGP v5.

даже при использовании 1024-битовых подключей спустя короткое время весь пакет ключа раздуется непомерно

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

Или они, даже отозванные, все равно остаются и засоряют кейсервер?

Да и отозванные и с истёкшим сроком действия.

Если бы ещё допозитарии умели отбрасывать подключи, аннулированные некоторое время назад...

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

Кстати, может быть стоит использовать особый формат аннулированных ключей, где вместо самого ключа оставлен только хэш и комментарии от полей UID?

Вот интересная работа на тему переполнения серверов.

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