id: Гость   вход   регистрация
текущее время 16:14 28/03/2024
Автор темы: Гость, тема открыта 17/12/2010 17:00 Печать
Категории: анонимность, инфобезопасность, политика
https://www.pgpru.com/Форум/РаботаСGnuPG/GPGВНедружественнойСреде
создать
просмотр
ссылки

GPG в недружественной среде

Здравствуйте!
Вопрос: Имеет ли возможность отправитель данных узнать сессионный ключ в самом банальном случае
gpg -e -r someoneelse somedata
с целью уличить получателя gpg сообщения в нечестности, если он "отказывается" расшифровывать ваше сообщение, под предлогом "испорченности сообщения".
Спасибо!


 
На страницу: 1, 2, 3, 4, 5 След.
Комментарии
— Гость (29/11/2012 08:19)   <#>
Есть несколько вопросов на примерно ту же тему:

  1. Может ли посторонний (тот, кто не адерсат сообщения) сказать, каким ключом подписан текст, зашифрованный как gpg --no-emit-version -es или gpg --no-emit-version -es?
  2. Тот же вопрос, что и в п.1, при условии дополнительной опции --hidden-recipient.
  3. Тот же вопрос, что и в п.2, но при условии нескольких адресатов (часть публичные, а часть — скрытые).
  4. Если адресатов несколько, можно ли сделать так, чтобы подпись на сообщении была видна только некоторым (публичным и/или скрытым) из них? Если да, то как?
  5. В man gpg говорится
    This option helps to hide the receiver of the message and is a limited countermeasure against traffic analysis.
    Какие подводные камни скрыты за словами "limited countermeasure"?

В faq написано, что есть следующие три опции для целей неразглашения:

--throw-keyids

--no-throw-keyids

Do not put the recipient key IDs into encrypted messages. This helps to hide the receivers of the message and is a limited countermeasure against traffic analysis. ([Using a little social engineering anyone who is able to decrypt the message can check whether one of the other recip‐ ients is the one he suspects.]) On the receiving side, it may slow down the decryption process because all available secret keys must be tried. --no-throw-keyids disables this option. This option is essentially the same as using --hidden-recipient for all recipients.

--hidden-recipient name

-R

Encrypt for user ID name, but hide the key ID of this user's key. This option helps to hide the receiver of the message and is a limited countermeasure against traffic analysis. If this option or --recipient is not specified, GnuPG asks for the user ID unless --default-recipient is given.

--hidden-encrypt-to name

Same as --hidden-recipient but this one is intended for use in the options file and may be used with your own user-id as a hidden "encrypt-to-self". These keys are only used when there are other recipients given either by use of --recipient or by the asked user id. No trust checking is performed for these user ids and even disabled keys can be used.

Отличия и тонкости этих опций мне не совсем понятны. Оговорка
Using a little social engineering anyone who is able to decrypt the message can check whether one of the other recipients is the one he suspects.
поидее должна относиться ко всем трём опциям, но написана только в одной, как пояснение к "limited countermeasure". Стоит ли что-то ещё за словами "limited countermeasure", какие-то криптографические уязвимости? Как я понял из цитаты
The --hidden-recipient (or -R) command encrypts to a user, but hides the identity of that user. This is the same functionality as --throw-keyid, but can be used on a per-user basis.
--throw-keyid идентично указанию hidden-recipient для всех, никаких других отличий нет.

Описание разницы между опциями --hidden-recipient и --hidden-encrypt-to ещё более туманно. Что они хотели сказать в
intended for use in the options file?
Ну не настолько же они глупы, чтобы вводить новое имя для одной и той же опции, только чтобы прописать её в gpg.conf, тем более, что вроде как все(?) именования опций идентичны вне зависимости от того, где используются (в командной строке или как опция в gpg.conf).

may be used with your own user-id as a hidden "encrypt-to-self".
А чем была плоха опция --hidden-recipient для тех же целей? Её же тоже можно применить для своего собственного ключа(?).

These keys are ... these user ids
К чему относится эти "these" в обоих предложениях? К значениям опции --hidden-encrypt-to?

These keys are only used when there are other recipients given
Хотят сказать что-то типа "если мы хотим все свои шифруемые сообщения ещё и параллельно скрыто шифровать для какого-то user id, то есть опция под это дело, её можно статически прописать в gpg.conf". И чем на эту роль не угодила --hidden-recipient? Её нельзя прописать в gpg.conf из-за костыльности архитектуры опций gpg? Или ключевое отличие — всё же
No trust checking is performed for these user ids and even disabled keys can be used?
Что они хотели этой цитатой сказать? В чём подразумеваемая связь умолчального скрытого получателя всех сообщений с тем, что почему-то этот получатель может оказаться с disabled key и прочее? Насчёт "trust checking" тоже не понимаю, что имелось в виду. То, что ключ подписан как доверенный с каким-то уровнем в смысле --ask-cert-level?

Кстати, почему-то собственный ключ не является по умолчанию помеченным, как доверенный с cert-level=3. Gnupg же видит, что есть секретный ключ для заданного, но при проверке подписи всё равно ругается на недоверенность. Так сделано на случай расшаривания секретного ключа между группой людей что ли?
— Гость (29/11/2012 08:31)   <#>
https://www.pgpru.com/Форум/РаботаСGnuPG/GPGВНедружественнойСреде

GPG в недружественной среде

А в последних комментариях этот топик числится под заголовком "(08:19) Вопрос о сессионном ключе". Почему названия не совпадают?
— SATtva (29/11/2012 08:47, исправлен 29/11/2012 08:48)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Может ли посторонний (тот, кто не адерсат сообщения) сказать, каким ключом подписан текст, зашифрованный как gpg --no-emit-version -es или gpg --no-emit-version -es?

Если сообщение зашифровано только ключом адресата (т.е. без Вашего), то не может — подпись находится внутри шифртекста. К слову, --no-emit-version — нерелевантная опция, непонятно, зачем Вы её привели.


Тот же вопрос, что и в п.1, при условии дополнительной опции --hidden-recipient.
Тот же вопрос, что и в п.2, но при условии нескольких адресатов (часть публичные, а часть — скрытые).

Аналогично.


Если адресатов несколько, можно ли сделать так, чтобы подпись на сообщении была видна только некоторым (публичным и/или скрытым) из них? Если да, то как?

Отправить разным группам адресатов разные сообщения: одно с подписью, другое — без.


Какие подводные камни скрыты за словами "limited countermeasure"?

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


Отличия и тонкости этих опций мне не совсем понятны.

--throw-keyids применяется ко всем ключам получателей (не уверен, однако, как она сочетается с --encrypt-to-self), --hidden-recipient — только к указанным ключам, --hidden-encrypt-to — только к ключу отправителя (главный нюанс тут в том, что gpg не проверяет уровень достоверности данного ключа). Сам функционал опций обеспечивается идентично, так что и оговорка в квадратных скобках применима к каждой.


Кстати, почему-то собственный ключ не является по умолчанию помеченным, как доверенный с cert-level=3. Gnupg же видит, что есть секретный ключ для заданного, но при проверке подписи всё равно ругается на недоверенность. Так сделано на случай расшаривания секретного ключа между группой людей что ли?

GnuPG автоматически даёт локально генерируемым ключам уровень доверия "ultimate". Собственный ключ может не иметь установленного уровня доверия, только если был импортирован с другой системы (или если по каким-то причинам был утрачен trustdb.gpg). Наличие или отсутствие закрытого ключа в данном случае роли не играет.

— Гость (29/11/2012 10:03)   <#>
Спасибо за ответ.

Отслеживание самого сообщения

В смысле анонимности его передачи по интернету? Есть же Tor.

Собственный ключ может не иметь установленного уровня доверия, только если был импортирован с другой системы

Раз доверие строится на подписях, а они импортируются, то в чём отличие импортированного приватного ключа от сгенерённого?

Если добавить строку throw-keyids в gpg.conf, то опция будет применяться по умолчанию ко всем шифровальным операциям, так? Как оно подружится с PGP в jabber? Джабберовское PGP вряд ли будет переопределять умолчания при шифровании, потому вопрос только в том, как сторона получателя отреагирует. Вроде бы есть какие-то тонкости/отличия при работе работе с PGP в разных jabber-клиентах.
— SATtva (29/11/2012 10:25)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
В смысле анонимности его передачи по интернету? Есть же Tor.

Это забота пользователя.

Раз доверие строится на подписях, а они импортируются, то в чём отличие импортированного приватного ключа от сгенерённого?

Достоверность распространяется через подписи. Доверие — свойство ключа, которое gpg хранит в файле trustdb.

Если добавить строку throw-keyids в gpg.conf, то опция будет применяться по умолчанию ко всем шифровальным операциям, так?

По логике, да.

Как оно подружится с PGP в jabber?

Отбрасывание keyid не входит в стандарт OpenPGP, так что джаббер-клиенты могут как послать пользователя с такими выкрутасами, так и нормально работать. Проверяйте. Не забывайте, что джаббер-сессия подписывается прозрачным образом.
— unknown (29/11/2012 14:19)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Отслеживание самого сообщения

В смысле анонимности его передачи по интернету? Есть же Tor.


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

При сокрытии ID-ключа владелец файлообменника не должен определить — это несколько раз обменивались файлами два одинаковых анонима (т.е. фактически псевдонимы) или каждый раз были разные анонимы.

Можно придумать и какой-нибудь другой сценарий, где отличие будет важным.
— Гость (01/12/2012 21:30)   <#>
Достоверность распространяется через подписи. Доверие — свойство ключа, которое gpg хранит в файле trustdb.
Я не уверен, что понял вас правильно. Могли бы вы пояснить отличие между достоверностью и доверенностью? Достоверность — уверенность в том, что ключом с некоторым user id действительно владеет персона, указанная в user id (ФИО, ящик и т.п.), а что такое тогда доверие?

При сокрытии ID-ключа владелец файлообменника не должен определить — это несколько раз обменивались файлами два одинаковых анонима (т.е. фактически псевдонимы) или каждый раз были разные анонимы.
throw-keyids защищает анонимов от владельца файлообменника? Не понял, к чему именно был приведён этот пример. Может быть, это пример, когда необходимо
расшаривание секретного ключа между группой людей?
— sentaus (01/12/2012 21:39, исправлен 02/12/2012 12:44)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
Достоверность — уверенность в том, что ключом с некоторым user id действительно владеет персона, указанная в user id (ФИО, ящик и т.п.), а что такое тогда доверие?

Доверие – уверенность в том, что ключи, подписанные данной персоной, являются достоверными. Почитайте /biblioteka/osnovy/setjdoverija, там это расписано.


throw-keyids защищает анонимов от владельца файлообменника?

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

— Гость (01/12/2012 22:32)   <#>
Достоверность — уверенность в том, что ключом с некоторым user id действительно владеет персона, указанная в user id (ФИО, ящик и т.п.), а что такое тогда доверие?
Доверие – уверенность в том, что ключи, подписанные данной персоной, являются достоверными. Почитайте https://www.pgpru.com/biblioteka/osnovy/setjdoverija, там это расписано.
Читал давно, перечитал сейчас. Вопрос остаётся. Я прекрасно знаю, что такое сеть доверия и прочее. Ответьте мне конкретно и чётко: что есть доверие и что есть достоверность. И в чём ключевое отличие.
— Гость (01/12/2012 22:36)   <#>
Иначе всё, что написано выше, смотрится тавтологией.

Я различаю 2 вещи:
  1. Я сам подписал для себя чей-то ключ с каким-то уровнем сертификации (--ask-cert-level) от 0 до 3ёх и никому об этом не сообщил. Подпись нужна только для меня лично, когда я работаю со своей связкой ключей.
  2. Я доверяю импортированному ключу на основе того, что он подписан с какими-то уровнем сертификации теми дургими ключами, которым я в какой-то мере доверяю (сеть доверия).

Где здесь доверие и где здесь достоверность?
— sentaus (01/12/2012 22:41, исправлен 01/12/2012 22:42)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32

Ваше определение достоверности(validity) вполне вменяемо:

Достоверность — уверенность в том, что ключом с некоторым user id действительно владеет персона, указанная в user id (ФИО, ящик и т.п.)

Достоверность – это свойство ключа.


Доверие(trust) – уверенность в том, что ключи, подписанные данной персоной, являются достоверными. Это характеристика личности, владеющей соответствующим ключом, с ВАШЕЙ точки зрения.
Например:
1)У меня есть достоверный ключ Васи. Я доверяю Васе, следовательно все ключи, которые подпишет Вася, будут для меня достоверными автоматически.


2)У меня есть достоверный ключ Пети. Но я не доверяю Пете, я знаю, что он подписывает все подряд ключи, и выставляю ему untrusted, и поэтому его подписи на ключах третьих лиц не будут делать эти ключи достоверными.

— sentaus (01/12/2012 22:47, исправлен 01/12/2012 22:48)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
1. Я сам подписал для себя чей-то ключ с каким-то уровнем сертификации (ask-cert-level) от 0 до 3ёх и никому об этом не сообщил. Подпись нужна только для меня лично, когда я работаю со своей связкой ключей.

Тут есть только достоверность. Предполагается, что вы ключ проверили и считаете его достоверным.


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

В терминах доверия и достоверности лучше сформулировать так: вы считаете импортированный ключ достоверным на основе того, что он подписан ключом, владельцу которого вы доверяете.

— Гость (01/12/2012 23:34)   <#>
Доверие(trust) – уверенность в том, что ключи, подписанные данной персоной, являются достоверными.

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

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

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

И как мне сделать собственный ключ доверенным, если он был импортирован c другой системы?
— sentaus (02/12/2012 00:07, исправлен 02/12/2012 00:21)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
Получается, доверие к некоторому ключу — это степень трансляционности достоверности этого ключа на достоверность других ключей, им подписанных (при использовании сети доверия).

И как мне сделать собственный ключ доверенным, если он был импортирован c другой системы?

Да всё так. Своему собственному ключу нужно выставить ultimate доверие – он при этом автоматически станет достоверным, и всё, что им подписано, признаётся достоверным. ultimate можно выставить и на открытый ключ без закрытого, только смысла это особого не имеет, если только этот открытый ключ не ваш (а закрытого вдруг по каким-то причинам нет). В общем, его нужно ставить только на свои ключи. :)


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

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

— Гость (02/12/2012 02:03)   <#>
Нет, от наличия/отсутствия закрытого ключа ничего не зависит, только от выставленного ultimate доверия.

Вот как раз это и вызывает вопрос (почему так сделали?). Раз закрытый ключ уже есть на связке, то почему бы не привязаться к этому факту и не сделать его доверенным автоматически? Ну, наверно, есть какие-то use-cases, когда такая привязка внесёт только неразбериху (например, один и тот же закрытый ключ есть у многих участников).

Своему собственному ключу нужно выставить ultimate доверие – он при этом автоматически станет достоверным, и всё, что им подписано, признаётся достоверным

Спасибо, так и сделал. gpg --edit-key 0xXXXXXXXX, uid 1, trust u, 5, save. Надеюсь, всё правильно.
На страницу: 1, 2, 3, 4, 5 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3