id: Гость   вход   регистрация
текущее время 21:43 09/12/2019
Автор темы: Гость, тема открыта 17/04/2006 13:13 Печать
https://www.pgpru.com/Форум/РаботаСGnuPG/НоваяСтабильнаяВерсияGnuPG143полезныеНовинки
создать
просмотр
ссылки

Новая стабильная версия GnuPG 1.4.3 (полезные новинки)


Вернер Кох две недели назад обьявил о выходе новой стабильной версии 1.4.3.
Много вниманя в новой версии уделяется подключам и управлению ими. Также реализована обоюдная сертификация подключей для подписи из новейшей редакции стандарта OpenPGP.
С удовольствием отвечу на вопросы о новой версии в этой теме. Всем пользователям GPG рекомендую обновить.
Back-port для стабильного дистрибутива Debian у меня есть, если кому-то лень этим заниматься и доверяет мне.


 
Комментарии
— Вий (19/04/2006 17:02)   профиль/связь   <#>
комментариев: 510   документов: 110   редакций: 75
Daniel, здравствуйте!
Расскажите пожалуйста немного подробнее об обоюдной сертификации подключей для подписи. Что это значит?
— SATtva (20/04/2006 22:48)   профиль/связь   <#>
комментариев: 11543   документов: 1036   редакций: 4092
Раз Дэниэл пока занят, дам краткий ответ.

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

Насколько я понимаю, перекрёстная сертификация командой cross-certify полезна только людям, использующим подключи для цифровых подписей. Если ключ не содержит таких подключей, команда ничего не даст, поскольку подписывать главный ключ будет нечем.

Применительно к подключам Эльгамаля это действительно так, но как поведут себя подключи RSA? Полагаю, должны быть учтены флаги применений, и если это Encrypt-only-подключ, он не издаст обратную подпись в принципе.

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

Если же оппонент захотел бы добавить собственный шифровальный подключ к ключу корреспондента в рассчёте на то, что пользователь зашифрует с его помощью сообщение, то ему бы это не удалось, поскольку такой подключ не был бы заверен главным сертифицирующим ключом и признан действительным.
— Вий (22/04/2006 08:09)   профиль/связь   <#>
комментариев: 510   документов: 110   редакций: 75
SATtva, здравствуйте!
Я понял так. Поправьте пожалуйста, если не верно.
Есть человек А (это я например), у меня ключ как раз с подключом подписания.
Есть человек Б, это по Вашему описанию оппонент. Человек Б разместил на своем ключе открытую часть моего подключа подписания и отправил такой свой (скрещенный) ключ человеку В.
Теперь я (А), пользуясь своим подключом подписания, посылаю человеку В подписанное письмо. Человек В сверяет подпись и видит, что оно подписано человеком Б? Но тогда у человека В подпись моего сообщения должна быть верной и от меня, (если на его связке присутствует и обладает соответствуюшим доверием и мой ключ).

Если я подписал свой главный ключ подключом подписания то такая ситуация становится невозможной поскольку моя подпись будет указывать лишь на мой главный ключ?
— Вий (22/04/2006 08:33)   профиль/связь   <#>
комментариев: 510   документов: 110   редакций: 75
Кроме того по видимому этот принцип (обоюдного подписания) Д. Надь использовал для сбора сертифицирующих подписей от других пользователей на своем главном ключе, хранимом отдельно от компьютера?
— Гость (22/04/2006 13:24)   <#>
Вий:
Я понял так. Поправьте пожалуйста, если не верно.

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

обозначения
K(x) – подпись ключем K сообщения x, A – главный ключ, B – подключ подписи
— Гость (22/04/2006 13:37)   <#>
Вий:
Кроме того по видимому этот принцип (обоюдного подписания) Д. Надь использовал для сбора сертифицирующих подписей от других пользователей на своем главном ключе, хранимом отдельно от компьютера?

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

Для того, чтобы сертифицировать мой главный ключ, его секретная часть не нужна (именно потому, что нет перекрестной сертификации). Для того, чтобы я мог кого-то сертифицировать, надо главный ключ достать из сейфа.

Кстати, я дописал subkeys в вики, а она рухула. Скорее всего, мой труд пропал. :(
— Вий (22/04/2006 18:48)   профиль/связь   <#>
комментариев: 510   документов: 110   редакций: 75
Daniel, тогда не совсем ясно, как Ваш главный ключ становится хранителем всех сертифицирующих подписей Ваших абонентов, с последующим их переносом на вновь созданные (если это потребуется) подключи. Какой смысл Вы вкладываете во фразу
человек удостоверившийся в моей личности имеет возможность показать свое удостоверение мне. Таким образом, мы на основе взаимности сертифицируем ключи друг-друга.

?
— SATtva (22/04/2006 22:41)   профиль/связь   <#>
комментариев: 11543   документов: 1036   редакций: 4092
Кстати, я дописал subkeys в вики, а она рухула. Скорее всего, мой труд пропал. Sad

Я восстановил базу, но, боюсь, Ваших изменений там действительно нет. Может осталась копия где-нибудь на диске или в кэше браузера, например?
— хость (16/07/2007 01:20)   <#>
Извините, что поднимаю старую тему, но думаю будет лучше, если все в одной ветке, чем десять веток.
Вобщем, я прочитав эту тему и попробовав на практике, окончательно запутался.
Во-первых, я не понял смысла злоумышленнику вешать саб-ключ-подписи на свой – на нем же стоит моя подпись, сделанная моим главным ключом с моим id'ом, или тут имеется ввиду, что он берет только сам ключ, вместо генерации нового, а дальше все как обычно, т.е. подписывает его своим главным ключом?
Но даже если и так, что это ему дает? Не могу придумать выгодную ситуацию, видимо по причине не понимания.
Далее, прочитал в мане про cross-certify, сделал и получил ответ:
subkey 0xMAIN does not sign and so does not need to be cross-certified
signing subkey 0xSUB#1 is already cross-certified
Хм, т.е. это уже сделано по умолчанию? Это хорошо, но почему я не вижу еще одной подписи на главном ключе? Это сделано специально, для удобства?
Но, опять же, допустим он там есть, а я просто не знаю как его увидеть, тогда опять вопрос: а что это изменило, если злоумышленник так же берет только сам ключ? Только вот в ветке упомянули, что подпись будет указывать (некий пакет?) лишь (лишь? А как мы узнаем каким именно сабом была сделана подпись?) на главный ключ, а не на саб-ключ-подписи.
Помогите прояснить, ибо делаю 'gpg -b file' и после 'gpg --verify file.sig' получаю:
gpg: Signature made 07/16/07 23:01:04
gpg: using RSA key 0xSUB#1
gpg: Good signature from "me" [ultimate]
т.е. указывает прямо на саб-ключ?

И между делом:
не могу содать подпись главным ключом 'gpg -u 0xMAIN -b file' – спрашивает пароль все для того же 0xSUB#1 и им же делает подпись :( Как я понял, я таким образом (-u) выбираю среди "главных ключей", которые уже сами решают чем делать подпись (т.е. имея саб им и подписывается). А как же тогда это сделать? Мне банально захотелось сравнить объемы сигнатур от главного ключа и подключа (у них разные размеры), не содавая временных лишних.
— SATtva (16/07/2007 10:43, исправлен 16/07/2007 10:54)   профиль/связь   <#>
комментариев: 11543   документов: 1036   редакций: 4092
Во-первых, я не понял смысла злоумышленнику вешать саб-ключ-подписи на свой – на нем же стоит моя подпись, сделанная моим главным ключом с моим id'ом, или тут имеется ввиду, что он берет только сам ключ, вместо генерации нового, а дальше все как обычно, т.е. подписывает его своим главным ключом?

Именно так он и поступает. А другие пользователи, получив подписанное Вашим подключом сообщение, решат, что подпись поставил злоумышленник (конечно, генерировать подписи за Вас он не сможет, но вводить других в заблуждение — легко; фактически же это равносильно подделке ЭЦП).

Хм, т.е. это уже сделано по умолчанию? Это хорошо, но почему я не вижу еще одной подписи на главном ключе? Это сделано специально, для удобства?

Да, перекрёстная сертификация выполняется автоматически при добавлении подключа. Но сама subkey binding signature нигде не отображается, ибо в этом нет никакого смысла. Уведеть такую подпись (sigclass 0x18) можно только при декодировке ключа.

не могу содать подпись главным ключом 'gpg -u 0xMAIN -b file' – спрашивает пароль все для того же 0xSUB#1 и им же делает подпись

Если GPG видит подключ подписи, то именно его использует для подписания данных; главный ключ используется только для сертификации других ключей. Чтобы явно указать ключ или подключ, которым следует подписать или зашифровать сообщение, дабавьте восклицательный знак после ID. Вот так: gpg -u 0xMAIN! -b file.

gpg: Signature made 07/16/07 23:01:04
gpg: using RSA key 0xSUB#1
gpg: Good signature from "me" [ultimate]
т.е. указывает прямо на саб-ключ?

Добавьте --verbose к команде и Вы увидите примерно следующее:

— SATtva (16/07/2007 10:58)   профиль/связь   <#>
комментариев: 11543   документов: 1036   редакций: 4092
Но сама subkey binding signature нигде не отображается

Наврал. Можно вот так: gpg -v --with-colons --list-sigs 0xMAIN. Если в предпоследнем столбце значится 18x — это subkey binding sig.
— хость (16/07/2007 15:39)   <#>
SATtva, спасибо огромное за подробное разъяснение.
— SATtva (16/07/2007 16:01)   профиль/связь   <#>
комментариев: 11543   документов: 1036   редакций: 4092
Всегда пожалуйста.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3