Редактирование закрытого ключа
Я могу изменить на uid`ах порядок предпочтения алгоритмов, указать предпочитаемый key-server, сменить primary uid, переподписать заново собственный uid (=> сменится дата подписи) и ещё кучу всего, но (!) если после я экспортирую свой _закрытый_ ключ – в нём всех этих изменений не будет – там все пакеты самоподписей uid`ов (а, как я понял, именно в них хранится всё вышеперечисленное) будут _самого первого_ издания (проверяется хоть импортом _только_ закрытого ключа на пустую связку и листанием его, хоть --list-packets на экспортированный закрытый ключ).
Это баг или фича? (или я что-то не так сделал?)
P. S. Если не выйдет повторить вышеописанное или я слишком мутно изложил – тупо распишу здесь последовательность команд, демонстрирующих этот эффект.
комментариев: 112 документов: 8 редакций: 15
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 112 документов: 8 редакций: 15
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 83 документов: 4 редакций: 4
комментариев: 232 документов: 17 редакций: 99
В нормальных условиях нельзя. В шифровании используется только последний подключ, а при расшифровке любой из подключей (выбирается автоматически).
Смена ключей шифрования существует для снижения ущерба в случае компроментации подключа (тайну потеряет только часть переписки).
комментариев: 11558 документов: 1036 редакций: 4118
Делается так:
Обратите внимание на восклицательный знак в конце (а может быть он должен быть в начале, перед ID? Не помню, попробуйте, если не сработает, как указал).
комментариев: 9796 документов: 488 редакций: 5664
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 83 документов: 4 редакций: 4
Большое спасибо за ответ.
комментариев: 9796 документов: 488 редакций: 5664
Пользователь генерирует ключ с большим числом одноразовых подключей и публикует на сервере. После того как ему написали письмо он его расшифровывает текущим подключём, затем в зависимости от его важности, аннулирует этот подключ, помечает какой номер подключа должен использоваться для следующего сообщения и публикует обновлённую версию публичного ключа на сервере.
На связке секретных ключей, использованные подключи он удаляет.
Т.о. при перехвате секретного ключа им можно будет прочитать только текущее и все последующие сообщения (но не предыдущие).
Посольку этот вариант подойдёт только для индивидуальной (немассовой) переписки, а также для облегчения генерации и стирания ключей проще конечно прислать адресату список OpenSSL ключей (сертификатов) – они не в связке, а в отдельных файлах, их легко стирать и генерировать скриптами.
В GnuPG же можно использовать компромисный вариант, чтобы не запутаться с номерами подключей: "подключ на текущий день", "подключ на текущую неделю"
комментариев: 11558 документов: 1036 редакций: 4118
Для ключей OpenPGP вижу только одну существенную проблему: даже при использовании 1024-битовых подключей спустя короткое время весь пакет ключа раздуется непомерно. Если бы ещё допозитарии умели отбрасывать подключи, аннулированные некоторое время назад...
Кстати, в чём-то подобную схему предлагает Ben Laurie (из OpenSSL) в качестве PFS-расширения к OpenPGP. Только оно появится не раньше, чем начнётся разработка формата ключей OpenPGP v5.
комментариев: 83 документов: 4 редакций: 4
комментариев: 9796 документов: 488 редакций: 5664
Да и отозванные и с истёкшим сроком действия.
...или бы оставляли на связке хотя бы только хэш-значения аннулированных подключей, помеченные флагом "аннулировано".
Кстати, может быть стоит использовать особый формат аннулированных ключей, где вместо самого ключа оставлен только хэш и комментарии от полей UID?
Вот интересная работа на тему переполнения серверов.
В некоторые поля ключа можно засунуть большие файлы (например mp3) и получить таким образом бесплатное хранилище, да еще и самокопирующееся среди множества серверов. В итоге, можно использовать сеть серверов ключей и как файлохранилище и как почту и как много чего ещё.