id: Гость   вход   регистрация
текущее время 12:17 28/03/2024
Автор темы: Гость, тема открыта 28/02/2007 04:54 Печать
https://www.pgpru.com/Форум/РаботаСGnuPG/РедактированиеЗакрытогоКлюча
создать
просмотр
ссылки

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


Я могу изменить на uid`ах порядок предпочтения алгоритмов, указать предпочитаемый key-server, сменить primary uid, переподписать заново собственный uid (=> сменится дата подписи) и ещё кучу всего, но (!) если после я экспортирую свой _закрытый_ ключ – в нём всех этих изменений не будет – там все пакеты самоподписей uid`ов (а, как я понял, именно в них хранится всё вышеперечисленное) будут _самого первого_ издания (проверяется хоть импортом _только_ закрытого ключа на пустую связку и листанием его, хоть --list-packets на экспортированный закрытый ключ).


Это баг или фича? (или я что-то не так сделал?)


P. S. Если не выйдет повторить вышеописанное или я слишком мутно изложил – тупо распишу здесь последовательность команд, демонстрирующих этот эффект.


 
На страницу: 1, 2 След.
Комментарии
— ПэГусев (28/02/2007 06:37)   профиль/связь   <#>
комментариев: 112   документов: 8   редакций: 15
Да, интересно. Предпочтения почему-то хранятся только на связке открытых ключей.
— SATtva (28/02/2007 10:20)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Ничего удивительного. Предпочтения (прежде всего это приоритетность алгоритмов, любимый сервер ключей и т.п.) в основном нужны отправителю сообщения, чтобы знать, где искать обновлённую копию ключа получателя и чем шифровать письмо для него. Так какой смысл хранить все эти данные с закрытым ключом, который никогда не должен покидать Вашей связки? Меня здесь больше удивляет то, что GPG хранит с закрытым ключом довольно много избыточной информации (сертификат открытого ключа в первой редацкии), в которой особой потребности я не вижу.
— ПэГусев (28/02/2007 10:46)   профиль/связь   <#>
комментариев: 112   документов: 8   редакций: 15
То и удивительно, что изменяется только одна редакция открытого ключа. А особенной нужды, действительно, в этой избыточной информации нет.
— Erelen (28/02/2007 14:37)   <#>
Ещё у этого есть такой эффект: есть у меня вполне себе настроенный (предпочтения алгоритмов, сервера etc) ключ. Экспортирую отдельно открытую и закрытую его части, потом их же импортирую на другую связку. На новой связке у каждого uid`а будет по две подписи ("настроенная" от открытого ключа и "первоизданная" от закрытого).
— SATtva (28/02/2007 15:16)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
И в этом нет ничего удивительного. Любые изменения, которые Вы вносите в сертификат ключа, заверяются закрытым ключом в пакете автоподписи (self-signature, чтобы гарантировать, что Вы эти изменения санкционировали; собственно, в этом пакете предпочтения и фиксируются). Так вот эти пакеты накапливаются на ключе на связке и на серверах ключей. Это "фича" протокола, и уж точно не баг. Просто любая OpenPGP-совместимая программа будет использовать именно те предпочтения, которые заверены самой новой подписью. Всё это позволяет, к примеру, продлевать срок действия ключа (expiry date), даже если он был жёстко установлен при его генерации.
— cooshoo (01/10/2007 21:27)   профиль/связь   <#>
комментариев: 83   документов: 4   редакций: 4
Наверное вопрос сюда. Если открытый ключ содержит несколько подключей шифрования, можно ли в GPG выбрать, каким подключом зашифровать сообщение? Я пробовал указывать получателя через -u [четырехбайтовый индикатор ключа], получатель определялся верно, но для шифрования всегда использовался последний сгенерированый подключ. А где-то в форуме было сказано, что если на связке несколько подключей, то можно осуществлять их ротацию. Или это было благое пожелание к разработчикам?
— serzh (02/10/2007 00:39)   профиль/связь   <#>
комментариев: 232   документов: 17   редакций: 99
Если открытый ключ содержит несколько подключей шифрования, можно ли в GPG выбрать, каким подключом зашифровать сообщение?

В нормальных условиях нельзя. В шифровании используется только последний подключ, а при расшифровке любой из подключей (выбирается автоматически).
Смена ключей шифрования существует для снижения ущерба в случае компроментации подключа (тайну потеряет только часть переписки).
— SATtva (02/10/2007 09:55)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Если открытый ключ содержит несколько подключей шифрования, можно ли в GPG выбрать, каким подключом зашифровать сообщение?

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



Обратите внимание на восклицательный знак в конце (а может быть он должен быть в начале, перед ID? Не помню, попробуйте, если не сработает, как указал).
— unknown (02/10/2007 10:32, исправлен 02/10/2007 10:32)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
У меня сработало только через -r, но не с -u
— SATtva (02/10/2007 10:40)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Да, разумеется, cooshoo ведь говорил о шифровании, а не о подписи данных, а я тупо повторил параметр из его сообщения (у него тоже ошибка).
— cooshoo (02/10/2007 19:35)   профиль/связь   <#>
комментариев: 83   документов: 4   редакций: 4
(у него тоже ошибка)
Есть такая буква... :)
Большое спасибо за ответ.
— unknown (08/10/2007 09:32)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
В связи с требованием выдачи в Англии ключей шифрования, нельзя ли использовать такую возможность для PFS (Perfect Forward Secrecy)?

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

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

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

В GnuPG же можно использовать компромисный вариант, чтобы не запутаться с номерами подключей: "подключ на текущий день", "подключ на текущую неделю"
— SATtva (08/10/2007 13:49)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Путаницу с подключами (или сертификатами X.509) можно решить с помощью периодов действия: скажем, первый подключ действует с начала этой недели до её конца, второй – с начала следующей до её конце, третий – с начала последующей до её конца и так далее. Главное, чтобы периоды не накладывались друг на друга.

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

Кстати, в чём-то подобную схему предлагает Ben Laurie (из OpenSSL) в качестве PFS-расширения к OpenPGP. Только оно появится не раньше, чем начнётся разработка формата ключей OpenPGP v5.
— cooshoo (08/10/2007 15:03, исправлен 08/10/2007 15:05)   профиль/связь   <#>
комментариев: 83   документов: 4   редакций: 4
даже при использовании 1024-битовых подключей спустя короткое время весь пакет ключа раздуется непомерно
Можно генерировать каждую неделю новые ключевые пары, подписывая их мастер-ключом. А старые отзывать. Или они, даже отозванные, все равно остаются и засоряют кейсервер?
— unknown (08/10/2007 15:10, исправлен 08/10/2007 15:31)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Или они, даже отозванные, все равно остаются и засоряют кейсервер?

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

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

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

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

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

В некоторые поля ключа можно засунуть большие файлы (например mp3) и получить таким образом бесплатное хранилище, да еще и самокопирующееся среди множества серверов. В итоге, можно использовать сеть серверов ключей и как файлохранилище и как почту и как много чего ещё.
На страницу: 1, 2 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3