GPG в недружественной среде
Здравствуйте!
Вопрос: Имеет ли возможность отправитель данных узнать сессионный ключ в самом банальном случае
gpg -e -r someoneelse somedata
с целью уличить получателя gpg сообщения в нечестности, если он "отказывается" расшифровывать ваше сообщение, под предлогом "испорченности сообщения".
Спасибо!
В faq написано, что есть следующие три опции для целей неразглашения:
Отличия и тонкости этих опций мне не совсем понятны. Оговорка поидее должна относиться ко всем трём опциям, но написана только в одной, как пояснение к "limited countermeasure". Стоит ли что-то ещё за словами "limited countermeasure", какие-то криптографические уязвимости? Как я понял из цитаты --throw-keyid идентично указанию hidden-recipient для всех, никаких других отличий нет.
Описание разницы между опциями --hidden-recipient и --hidden-encrypt-to ещё более туманно. Что они хотели сказать в Ну не настолько же они глупы, чтобы вводить новое имя для одной и той же опции, только чтобы прописать её в gpg.conf, тем более, что вроде как все(?) именования опций идентичны вне зависимости от того, где используются (в командной строке или как опция в gpg.conf).
А чем была плоха опция --hidden-recipient для тех же целей? Её же тоже можно применить для своего собственного ключа(?).
К чему относится эти "these" в обоих предложениях? К значениям опции --hidden-encrypt-to?
Хотят сказать что-то типа "если мы хотим все свои шифруемые сообщения ещё и параллельно скрыто шифровать для какого-то user id, то есть опция под это дело, её можно статически прописать в gpg.conf". И чем на эту роль не угодила --hidden-recipient? Её нельзя прописать в gpg.conf из-за костыльности архитектуры опций gpg? Или ключевое отличие — всё же Что они хотели этой цитатой сказать? В чём подразумеваемая связь умолчального скрытого получателя всех сообщений с тем, что почему-то этот получатель может оказаться с disabled key и прочее? Насчёт "trust checking" тоже не понимаю, что имелось в виду. То, что ключ подписан как доверенный с каким-то уровнем в смысле --ask-cert-level?
Кстати, почему-то собственный ключ не является по умолчанию помеченным, как доверенный с cert-level=3. Gnupg же видит, что есть секретный ключ для заданного, но при проверке подписи всё равно ругается на недоверенность. Так сделано на случай расшаривания секретного ключа между группой людей что ли?
А в последних комментариях этот топик числится под заголовком "(08:19) Вопрос о сессионном ключе". Почему названия не совпадают?
комментариев: 11558 документов: 1036 редакций: 4118
Если сообщение зашифровано только ключом адресата (т.е. без Вашего), то не может — подпись находится внутри шифртекста. К слову, --no-emit-version — нерелевантная опция, непонятно, зачем Вы её привели.
Аналогично.
Отправить разным группам адресатов разные сообщения: одно с подписью, другое — без.
Отслеживание самого сообщения, например, плюс то, что приводится в описании опции в квадратных скобках. Смысл в том, чтобы пользователь не полагался на эту опцию как на полноценное средство защиты от анализа трафика.
--throw-keyids применяется ко всем ключам получателей (не уверен, однако, как она сочетается с --encrypt-to-self), --hidden-recipient — только к указанным ключам, --hidden-encrypt-to — только к ключу отправителя (главный нюанс тут в том, что gpg не проверяет уровень достоверности данного ключа). Сам функционал опций обеспечивается идентично, так что и оговорка в квадратных скобках применима к каждой.
GnuPG автоматически даёт локально генерируемым ключам уровень доверия "ultimate". Собственный ключ может не иметь установленного уровня доверия, только если был импортирован с другой системы (или если по каким-то причинам был утрачен trustdb.gpg). Наличие или отсутствие закрытого ключа в данном случае роли не играет.
В смысле анонимности его передачи по интернету? Есть же Tor.
Раз доверие строится на подписях, а они импортируются, то в чём отличие импортированного приватного ключа от сгенерённого?
Если добавить строку throw-keyids в gpg.conf, то опция будет применяться по умолчанию ко всем шифровальным операциям, так? Как оно подружится с PGP в jabber? Джабберовское PGP вряд ли будет переопределять умолчания при шифровании, потому вопрос только в том, как сторона получателя отреагирует. Вроде бы есть какие-то тонкости/отличия при работе работе с PGP в разных jabber-клиентах.
комментариев: 11558 документов: 1036 редакций: 4118
Это забота пользователя.
Достоверность распространяется через подписи. Доверие — свойство ключа, которое gpg хранит в файле trustdb.
По логике, да.
Отбрасывание keyid не входит в стандарт OpenPGP, так что джаббер-клиенты могут как послать пользователя с такими выкрутасами, так и нормально работать. Проверяйте. Не забывайте, что джаббер-сессия подписывается прозрачным образом.
комментариев: 9796 документов: 488 редакций: 5664
Предположим, оба адресата посылают сообщения через Tor, но пользуются даже не общим почтовым сервисом (наподобие гуглопочты), а общим файлообменником для выкладывания шифрованных файлов.
При сокрытии ID-ключа владелец файлообменника не должен определить — это несколько раз обменивались файлами два одинаковых анонима (т.е. фактически псевдонимы) или каждый раз были разные анонимы.
Можно придумать и какой-нибудь другой сценарий, где отличие будет важным.
throw-keyids защищает анонимов от владельца файлообменника? Не понял, к чему именно был приведён этот пример. Может быть, это пример, когда необходимо
комментариев: 1060 документов: 16 редакций: 32
Доверие – уверенность в том, что ключи, подписанные данной персоной, являются достоверными. Почитайте /biblioteka/osnovy/setjdoverija, там это расписано.
Да. Если пакет был зашифрован с этим параметром, то в него не будут добавлены идентификаторы открытых ключей, которые использовались для шифрования. Как следствие, сторонний наблюдатель не сможет установить, какими ключами можно осуществить расшифровку.
Минус тут только один – при расшифровке надо пытаться расшифровывать каждым своим закрытым ключом каждую копию сеансового ключа из пакета, но gpg это делает абсолютно прозрачно.
Я различаю 2 вещи:
Где здесь доверие и где здесь достоверность?
комментариев: 1060 документов: 16 редакций: 32
Ваше определение достоверности(validity) вполне вменяемо:
Достоверность – это свойство ключа.
Доверие(trust) – уверенность в том, что ключи, подписанные данной персоной, являются достоверными. Это характеристика личности, владеющей соответствующим ключом, с ВАШЕЙ точки зрения.
Например:
1)У меня есть достоверный ключ Васи. Я доверяю Васе, следовательно все ключи, которые подпишет Вася, будут для меня достоверными автоматически.
2)У меня есть достоверный ключ Пети. Но я не доверяю Пете, я знаю, что он подписывает все подряд ключи, и выставляю ему untrusted, и поэтому его подписи на ключах третьих лиц не будут делать эти ключи достоверными.
комментариев: 1060 документов: 16 редакций: 32
Тут есть только достоверность. Предполагается, что вы ключ проверили и считаете его достоверным.
В терминах доверия и достоверности лучше сформулировать так: вы считаете импортированный ключ достоверным на основе того, что он подписан ключом, владельцу которого вы доверяете.
Вот ключевая фраза. Спасибо, теперь понятно. Получается, доверие к некоторому ключу — это степень трансляционности достоверности этого ключа на достоверность других ключей, им подписанных (при использовании сети доверия).
Возвращаясь к вопросу меня всё же удивляет, при чём здесь доверие, если я никогда не участвовал в сети доверия. Имеется в виду, что какая-то умолчальная сеть доверия функционально есть всегда и участие в ней включено по умолчанию?
Наверное, там как-то так: если собственный ключ (к которому имеется и закрытый) не помечен, как доверенный, то его подпись на его же открытом ключе не расценивается, как влекущая за собой достоверность этого (открытого) ключа. Какая-то метаморфоза сознания прям. Даже не могу понять: логично такое поведение или алогично, что из этого следует, и зачем так сделали.
И как мне сделать собственный ключ доверенным, если он был импортирован c другой системы?
комментариев: 1060 документов: 16 редакций: 32
Да всё так. Своему собственному ключу нужно выставить ultimate доверие – он при этом автоматически станет достоверным, и всё, что им подписано, признаётся достоверным. ultimate можно выставить и на открытый ключ без закрытого, только смысла это особого не имеет, если только этот открытый ключ не ваш (а закрытого вдруг по каким-то причинам нет). В общем, его нужно ставить только на свои ключи. :)
Нет, от наличия/отсутствия закрытого ключа ничего не зависит, только от выставленного ultimate доверия. Всё это позволяет вычислять достоверности ключей без доступа к закрытым ключам. Например, связка с закрытыми ключами может вообще лежать на не подключеной в данный момент флешке, а рассчитать достоверность ключа адресата всё равно можно.
Вот как раз это и вызывает вопрос (почему так сделали?). Раз закрытый ключ уже есть на связке, то почему бы не привязаться к этому факту и не сделать его доверенным автоматически? Ну, наверно, есть какие-то use-cases, когда такая привязка внесёт только неразбериху (например, один и тот же закрытый ключ есть у многих участников).
Спасибо, так и сделал. gpg --edit-key 0xXXXXXXXX, uid 1, trust u, 5, save. Надеюсь, всё правильно.