id: Гость   вход   регистрация
текущее время 21:41 30/03/2020
Владелец: unknown (создано 29/09/2013 19:19), редакция от 29/09/2013 22:48 (автор: spinore) Печать
Категории: софт, pgp, gnupg, openpgp, tor, стандарты
создать
просмотр
редакции
ссылки

Почему сети доверия PGP беспомощны



"Почему сети доверия так беспомощны",
© 2013 Mike Perry.
Перевод © 2013 unknown

В форуме PGPru.com неоднократно поднимались вопросы, касающиеся недостатков сетей доверия OpenPGP. В частности, звучали мнения о необходимости отказаться от их использования и сверять ключи только по отпечаткам из-за ненадёжности этой схемы аутентификации. Помимо этого, участие в сетях доверия приводит к утечке массы метаданных о личности пользователя, социальных связях, круге его текущих контактов, что подрывает его анонимность. Ради этого некоторые пользователи создают анонимные ключи, а также не обмениваются ключами через открыто доступные серверы ключей. Схожие проблемы начали волновать одного из ведущих разработчиков Tor-браузера. Когда Майк Перри сделал объявление о смене своего PGP-ключа, он отметил своё негативное мнение о сетях доверия. Позднее, он дал разъяснение своей позиции по этому вопросу, перевод которого1 имеет смысл привести полностью.



Сети доверия имеют три основные проблемы:


  1. Они приводят к утечке информации.

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

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

    Поскольку по умолчанию GPG использует кратчайший взвешенный путь установления доверия к ключу и кроме этого ничто не аутентифицирует полный граф сети доверия, то это приводит к тому, что каждый участник прочного набора выступает в роле сертификационного или удостоверяющего центра (Certification Authority — CA), особенно для ключей, которые лишь слабо связаны с прочным набором. Стоит вам скомпрометировать хотя бы один из этих ключей, как вы сможете использовать его для заверения любого ключа на любое выбранное вами имя.

    Чтобы понять в какой мере и почему это является проблемой, пройдёмся по типичному сценария взаимодействия в сети доверия.

    Предположим, существует GPG-пользователь Эдвард2, который хочет отправить шифрованное сообщение журналисту, с которым он никогда не встречался ранее, по поводу злоупотреблений гигантского масштаба, творящихся по месту его работы. Назовём этого журналиста, допустим, Гленн3. Ради нашего примера представим, что было бы, если бы они активно участвовали в сети доверия.

    Эдвард также знает, что системные администраторы с его работы очень изощрённы и перехватывают все его шифрованные коммуникации с целью атаки подмены «человеком посредине» (MITM) и получения таким образом доступа к содержимому сообщений. Эдвард решает загрузить ключ Глена с сервера subkeys.pgp.net и предоставляет gpg-клиенту возможность определить уровень доверия к ключу Глена.

    Но системные администраторы сетей на его рабочем месте4 уже предусмотрели это. На этот случай у них заготовлены скомпрометированные сертификаты HTTPS от центров аутентификации (CA), также как и скомпрометирована некоторая часть высокодоверяемых ключей из сети доверия5. Назовём один из этих GPG-ключей именем Роджер6.

    Теперь, как только Эдвард начинает загружать ключ для связи с Гленом, сисадмины подменяют его на подложный ключ, сгенерированный на лету. Сисадмины также подписывают подложный ключ скомпрометированным ключом Роджера. Они также блокируют загрузку для Эдварда подлинного ключа Глена.

    GPG-клиент Эдварда доверяет некоторым ключам. Он определяет, что один из его доверяемых ключей, с именем Брюс7, имеет полное доверие к ключу Роджера (к его скомпрометированному варианту).

    Затем GPG-клиент Эдварда вычисляет полностью доверяемый путь от Брюса до Роджера и от Роджера до фальшивого Глена, что позволит системному администратору незамедлительно читать всю переписку.

    Для Эдварда игра окончена :/.

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

  1. Сети доверия плохо масштабируются на сценарий глобальной популяции.

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

Что делать вместо этого?


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


Есть множество способов использования многопутевой аутентификации, не страдающих от недостатков сетей доверия*.


Несколько примеров:


  1. Каждый раз, когда вы загружаете ключ GPG, сделайте несколько контрольных перезагрузок через сеть Tor с разными цепочками этой сети — это поможет вам убедиться, что каждый раз вы получаете одинаковый ключ.
  2. Каждый раз я проверяю подпись на присылаемом мне по почте сообщении. Если сообщение приходит на адрес, который не является моим (например через общедоступные списки почтовой рассылки), то мой почтовый клиент добавляет немного доверия к этому ключу (поскольку каждое новое открыто опубликованное письмо с электронной подписью по факту своей загрузки отражает наблюдаемую картину ключа через потенциально различные сетевые пути, которые должны быть доступны различным людям, включая самого отправителя).
  3. Каждый раз перед тем как я шифрую почту каким-либо ключом, я проверяю на серверах, что ключ для этого адреса не поменялся (в стиле того, как проверяется в SSH/TOFU).
  4. После загрузки ключа я проверяю, что связь между данным ключом и адресом электронной почты не поменялась на множестве серверов ключей, TLS-сертификаты которых заверены независимо и не зашиты непосредственно в исходники самого пакета GPG (многопутевая криптографическая аутентификация в стиле Perspectives/Notary).

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



Примечания к переводу:


1 "Why the Web of Trust Sucks" в оригинале.
2 Если кто-то ещё не забыл имена этих персонажей, то понятно, на какого Эдварда намекает Майк.
3 Вероятный прототип персонажа для этого примера.
4 Реальный Эдвард не стал бы устраивать переписку со своего рабочего места, но Майк, вероятно, упрощает ситуацию, не уточняя, что работодатель Эдварда может следить за ним повсюду.
5 Не такое уж сильное допущение, если рассматривать модель реалистичного сильного противника.
6 Возможный намёк на другую персону. С учётом того, что все имена и характер их взаимоотношений в этом примере взяты с реальных событий, намёк на компрометацию именно ключа Роджера выглядит несколько вызывающе-ироничным со стороны Майка. Впрочем, как и весь пример в целом.
7 Скорее всего, имя для намёка взято от этой персоны.


 
На страницу: 1, 2, 3, 4 След.
Комментарии [скрыть комментарии/форму]
— Гость (01/10/2013 14:46)   <#>

Я думал, лишние комментарии излишни, т.к. это вопрос к /comment71148, опубликованному на предыдущей странице. Возражений к нему не последовало, но при повторном поднятии вопроса почему-то вы теперь пишете, что никакой проблемы вообще нет.


Допустим, я не доверяю сети доверия PGP, считая её беспомощной, но я всё же хочу знать, какой ключ каким подписан. Есть ли возможность в этом убедиться, если противник может делать коллизии по 16-ричным keyid'ам? Считайте, что у вас есть два PGP-ключа, и один якобы подписал другой. В --list-sigs указан правильный индентификатор. Подписывал ли один ключ другой на самом деле или нет?

Я не очень хорошо представляю, как функционирует сеть доверия, хоть мы это уже и обсуждали в прошлый раз. Когда вы говорите, что формирование цепочек доверия всё равно производится по полным отпечаткам, что вы имеете в виду? Что для выставления доверия каждый владелец ключа проверяет отпечаток лично, прежде чем выставить ключу доверие? Ну, для непосредственно доверяемых ключей так можно считать, но весь смысл сети доверия в том, чтобы установить доврие к ключу, отпечаток которого вы не знаете, и ранее в жизни никогда его не видели. Чему вы при этом будете доверять в параметрах этого нового для вас ключа, кроме как подписям тех, кому вы доверяете? А подписи, получается, несвязываемы однозначно с отпечатками ключей.

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

И вообще, если вы считаете, что подписи и доверие — это разные звери, зачем тогда вообще нужны подписи на ключах?
— sentaus (01/10/2013 15:21)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
Когда вы говорите, что формирование цепочек доверия всё равно производится по полным отпечаткам, что вы имеете в виду?


"Внутри" openpgp-реализации используют полные отпечатки для идентификации ключей.

Что для выставления доверия каждый владелец ключа проверяет отпечаток лично, прежде чем выставить
ключу доверие?


Желательно бы так делать.


что подписи и доверие — это разные звери, зачем тогда вообще нужны подписи на ключах?

Подпись на ключе означает, что подписавший считает подписанный ключ подлинным, т.е. что ключ действительно принадлежит человеку, имя которого указано в UID.
Доверие – это доверие владельцу ключа. Например, у вас есть подлинный ключ Васи, который не подписывает что попало, а проверяет ключи. Тогда ключу Васи можно выставить доверие. А есть подлинный ключ Пети, которые подписывает любой ключ for fun, разумеется не стоит ключу Пети доверие выставлять.
— SATtva (01/10/2013 15:25)   профиль/связь   <#>
комментариев: 11545   документов: 1036   редакций: 4094
Допустим, я не доверяю сети доверия PGP, считая её беспомощной, но я всё же хочу знать, какой ключ каким подписан. Есть ли возможность в этом убедиться, если противник может делать коллизии по 16-ричным keyid'ам? Считайте, что у вас есть два PGP-ключа, и один якобы подписал другой. В --list-sigs указан правильный индентификатор. Подписывал ли один ключ другой на самом деле или нет?

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

Когда вы говорите, что формирование цепочек доверия всё равно производится по полным отпечаткам, что вы имеете в виду?

Я имею в виду, как эта система работает "под капотом" gpg.

А подписи, получается, несвязываемы однозначно с отпечатками ключей.

Это проблема UI gpg, а не криптографии, используемой в этом процессе. Я уже говорил: пишите багрепорты, разработчики через libastral о Ваших потребностях не узнАют.

И вообще, если вы считаете, что подписи и доверие — это разные звери, зачем тогда вообще нужны подписи на ключах?

/Библиотека/Основы/ВведениеВКрипто/Глава1/ПодлинностьДоверие
— Гость (01/10/2013 16:34)   <#>

Но
$ cat key.asc |gpg --list-packets
тоже не показывает ничего кроме 16-ричных keyid'ов. Может, проблема всё-таки в самом стандарте, а не в GnuPG?


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

Если опошлять и опримитивлять, то вы мне даёте 4M$, и все подписи на всех PGP-ключах более ничего не значат. Ну, или значат, только пользователь об этом никак не узнает. Т.е., программных средств для этого нет, а поэтому каши можно успеть наварить.
— unknown (01/10/2013 16:50, исправлен 01/10/2013 16:52)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Вот оказывается как K.O. отвечает на неочевидные вопросы :)



Может быть, ключ, у которого подобран укороченный отпечаток, вообще не отобразится и не сможет ничего подписать. Но более вероятно, что отобразится, но при этом останется сообщение, что заверяемый ключ не заверен доверяемой подписью. Это при автоматической обработке не должно вызвать нештатной ситуации, а при ручном разборе вызовет дополнительные подозрения: такой же точно отпечаток есть — доверия нет.

— SATtva (01/10/2013 17:00)   профиль/связь   <#>
комментариев: 11545   документов: 1036   редакций: 4094
Может, проблема всё-таки в самом стандарте, а не в GnuPG?

jackychan_meme.jpg. Достоверность ключей определяется по криптографическим подписям. Единственное, для чего могут применяться keyID в этом процессе (кстати, 8-байтовые, раздел 5.2.3.5 спецификации) — это для поиска ключа заверителя на связке. Если произойдёт коллизия, и программа вытащит неверный ключ, сертифицирующая подпись всё равно не будет сверена. Как ещё объяснить эту очевидную вещь, я уже не знаю.
— Гость (01/10/2013 17:17)   <#>

Такое впечатление, что разговариваем на разных языках. :( Что значит «сертифицирующая подпись не будет сверена»? В ответ на --list-sigs будет выдано
sig          ABCD1234 1970-01-01  [User ID not found]
при том, что 0xABCD1234 на связке есть? Т.е. единственная зацепка — «User ID not found», которое будет писаться несмотря на совпадающие keyid'ы (хоть 8-ми, хоть 16-ричные)?


Оно так естественно получилось. :)
— SATtva (01/10/2013 17:53)   профиль/связь   <#>
комментариев: 11545   документов: 1036   редакций: 4094
Такое впечатление, что разговариваем на разных языках.

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

Ручная сверка подписей, по-видимому, никогда не рассматривалась в качестве надёжного и необходимого средства, --list-sigs — это скорее просто рюшечка, не несущая практического смысла. Если Вы попытаетесь зашифровать что-то недостоверным ключом, программа выдаст предупреждение. Чтобы сделать ключ достоверным, его надо либо а) подписать самому (самостоятельно сверив отпечаток у владельца), либо б) получить подпись от другого пользователя, которому Вы доверяете (что всё равно предполагает действия из п. "а", но в отношении ключа заверителя, который выполняет их в отношении целевого ключа). Т.е., так или иначе, сверка отпечатков происходит всегда, и достоверность определяется криптографически через цепочку подписей — keyID тут вообще никаким боком.

Если всё равно считаете, что ручной разбор отпечатков через вывод --list-sigs надёжнее, то, повторяю, пишите багрепорт.
— Гость (02/10/2013 07:00)   <#>

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

Такая ошибочная схема возникает в голове по той причине, что вы держите у себя в уме тот факт, что установить непосредственный контакт вы можете только с очень ограниченным числом лиц. Из этого следует, что большую часть владельцев PGP-ключей вы можете знать только заочно и по подписям каких-то третьих лиц. Соответственно, у вас не может возникнуть какого-то обоснованного мнения по поводу того, стоит ли выставлять доверие (более точно — трасляцию доверия) всей этой массе ключей. Если я знаю Васю только заочно, потому что его ключ подписали Петя и Саша, на каком основании я вдруг стану доверять подписям Васи на чужих ключах? И таких Вась — почти все ключи на связке. Из-за этого возникает мнение, что раз «система доверия в PGP всё-таки работает», то доверие таким Васям должно, тем не менее, выставляться. Ну, и интуитивно на первых порах представляется, что это доверие выставляется автоматически исходя из каких-то подписей одних ключей другими. А, на самом деле, всё не так: доверие надо руками поставить к каждому ключу, автоматически можно установить только достоверность. И пусть ключ хоть 100 раз достоверен и все его подписали, это не значит ничего в плане доверия к этому ключу, т.к. доверие — отдельная опция, и каждый раз вы её выставляете сами. Ну, и по какому-то алгоритму из астрала приходится решать, каким ключам непонятных анонимов выставить доверие, а каким нет. Т.е. трудно поначалу понять, что доверие, по большому счёту, почти никак не связано с достоверностью.

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


В любом случае, раз GnuPG устанавливает достоверность автоматически, оно вынуждено полагаться на сертифицирующие подписи других ключей. Раз так, GnuPG должна точно знать, кто какой ключ подписал. Хорошо, пусть даже в --list-packets вся детальная информация на этот счёт не отображается, но GnuPG же не может её черпать из астрала, так же? Значит, можно написать какую-то программу руками, которая распарсит публичный ключ и выудит оттуда весь имеющийся криптографический материал, свидетельствующий о подписи. Я только не понимаю, что в этом материале будет находиться. Полный отпечаток ключа, которым была сделана подпись или что-то другое?
— SATtva (02/10/2013 09:28, исправлен 02/10/2013 10:12)   профиль/связь   <#>
комментариев: 11545   документов: 1036   редакций: 4094
Новичку трудно привыкнуть к тому, что достоверность не влечёт за собой доверие. Интуитивно схема сразу же рисуется такой: два моих доверенных достоверных абонента подписали ключ третьего, поэтому ключ третьего достоверен и доверен. А раз так, я автоматически на каком-то уровне доверяю подписям, которые проставил третий на ключе четвёртого, пятого и остальных.

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


А, на самом деле, всё не так: доверие надо руками поставить к каждому ключу, автоматически можно установить только достоверность.

На самом деле, есть особый тип экспортируемой подписи с произвольной глубиной делегирования доверия — т.н. trusted introducer. Если подписываете чужой ключ таким образом, он автоматически наделяется доверием, которое распространяется через N-ное число подписей вглубь (причём можно ограничить их UID'ами с мэйл-адресами из определённого домена). То есть это своего рода ограниченный УЦ.


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

Так делать категорически не следует. Если не ошибаюсь, программа даже не позволит выставить доверие, если ключ не заверен Вашей подписью.


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

Там будет 8-байтовый ID ключа подписи, набор MPI (материала подписи) и всяческие прочие метаданные и заголовки пакетов. При этом ID ключа хранится не в hex-нотации (я тут написал глупость), т.е. там 8 октетов, которые преобразуются в 16-байтовые шестнадцатеричные keyID, которые Вы наблюдаете в выводе --list-sigs. Что должен делать Ваш гипотетический парсер (или gpg, если бы в нём реализовали такой функционал):

  1. Взять с заверенного ключа пакет подписи.
  2. Найти по 16-значному ID ключ заверителя на связке.
  3. Сверить подпись с помощью материала ключа.
  4. Если подпись верна, отобразить полный отпечаток, рассчитанный от материала ключа заверителя.

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

— sentaus (02/10/2013 11:04)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
Новичку трудно привыкнуть к тому, что достоверность не влечёт за собой доверие.

Новичку привыкнуть как раз легче, гораздо труднее, например, тем, кто знаком с X.509. Термины действительно не очень соответствуют друг другу, хотя в openpgp они более соотвествуют реальному миру. Например термин "доверие к ключу" смысла особого не имеет. Ключ – это объект, а доверять в каких-либо вопросах можно только субъекту. "Доверие владельцу ключа" гораздо лучше описывает ситуацию.


На самом деле, есть особый тип экспортируемой подписи с произвольной глубиной делегирования доверия — т.н. trusted introducer.

Да, в PGP это делали для эмуляции древовидных систем PKI. Подписываем ключ meta-introducer, выставляем ему доверие – и все подписанные им ключи становятся достоверными и доверенными.

Если не ошибаюсь, программа даже не позволит выставить доверие, если ключ не заверен Вашей подписью.

GnuPG выставит, это всегда немного раздражало. PGP не позволяла.
— SATtva (02/10/2013 12:55)   профиль/связь   <#>
комментариев: 11545   документов: 1036   редакций: 4094
Да, в PGP это делали для эмуляции древовидных систем PKI. Подписываем ключ meta-introducer, выставляем ему доверие – и все подписанные им ключи становятся достоверными и доверенными.

Это стандартная штука, в gpg она тоже есть, называется там Trust Signature: --edit-key > tsign.
— Гость (06/10/2013 12:24)   <#>

Т.е. не могут отличить коллизию от ситуации, когда один ключ действительно подписал другой?


Шестнадцатеричные, но не 16-байтовые. 16 знаков шестнадцатеричного алфавита — это 8 байт.


А верность подписи каким-то ключом связана с его отпечатком или нет? Наверно, имеется в виду, что нет, т.е., в принципе, гипотетически могут существовать два разных PGP-ключа с тождественно совпадающими отпечатками (40 знаков). И отпечаток (т.е. хэш от ключевого материала) служит лишь для удобства сравнения ключевого материала, но не более того. Т.е., получается, проверка подписи будет в PGP работать правильно, даже если кто-то гипотетически умудрился бы подобрать весь отпечаток ключа. Фактически отпечаток — удобная форма для человека, чтобы проверить, какой ключ он получил, а дальше GnuPG само бы всё сделало и без всяких отпечатков.


Допустим, кто-то сделал 16-знаковую коллизию отпечатка для одного из ключей на вашей связке. Вы сделали --refresh-keys 0x1234567890ABCDEF с серверами ключей, и при этом вместо обновления существующего вы ещё импортировали другой подставной ключ, принадлежащий атакующему. Какой из этих PGP-ключей GnuPG выберет для проверки подписи на нужном ключе? Есть вариант, когда будет выбран ключ атакующего. В этом случае GnuPG вам покажет, что ключ подписи не найден, хотя на связке он есть. Так? Не знаю, какую ещё атаку поизощрённей придумать, хоть резюме в TAO отправляй.


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


Тоже учились на юриста?

Меня путает даже англоязычная терминология. Например, при проверке подписи пишется:
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Я проверил отпечаток ключа после импортирования его на связку. Я точно знаю, что ключ принадлежит моему абоненту. При чём тут «trusted signature», которая ассоциируется с параметром «trust» для ключа, а не со словом «validity»? Trust к чужому ключу — это транслируемость моего доверия мнения о валидности ключей через подписи, сделанные этим чужим ключом. Я бы сказал, что есть валидность и транслируемость валидности (ну, или доверие и транслируемость доверия), но когда слова транслируемость нет, возникает путанница. Последняя усугубляется ещё и тем, что под validity часто имеют в виду, что у ключа ещё не истёк срок действия (expired).


Свой собственный ключ, наверно, тоже можно таким сделать, хотя не вижу в этом смысла: лучше оставить возможность дифференцировать чужие PGP-ключи по типу подписи (0-3, --ask-cert-level).


Есть вопрос про lsign. Если я подпишу какой-то ключ такой подписью, а потом сделаю --export, подпись не будет экспортирована, так? Если да, то как тогда перенести свою связку в другую директорию, сохранив локальные подписи? Только через cp -Rv ~/.gnupg /path/to? Или это тоже нерекомендуемый способ?
— SATtva (06/10/2013 12:47)   профиль/связь   <#>
комментариев: 11545   документов: 1036   редакций: 4094

Да.


Именно так.


В списке рассылки GnuPG такой вопрос когда-то поднимался, но ответа я не помню. Можете погуглить.


Разумеется. Иное было бы абсурдом.


Да.


Самый что ни на есть рекомендуемый.
— Гость (18/10/2013 18:43)   <#>
/comment71147:
В новых версиях GnuPG таких ограничений нет. Недавно генерил ключи в MacGPG, так там можно было выбрать 8192 сразу в интерактивном режиме.
На страницу: 1, 2, 3, 4 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3