id: Гость   вход   регистрация
текущее время 15:09 29/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 След.
Комментарии
— SATtva (02/12/2012 12:48)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Вот как раз это и вызывает вопрос (почему так сделали?).

sentaus только что ведь исчерпывающе ответил:
Всё это позволяет вычислять достоверности ключей без доступа к закрытым ключам. Например, связка с закрытыми ключами может вообще лежать на не подключеной в данный момент флешке, а рассчитать достоверность ключа адресата всё равно можно.
— Гость (03/12/2012 05:18)   <#>
sentaus только что ведь исчерпывающе ответил

В принципе, понятно. Я имел в виду, что логика могла бы быть и более сложной, типа такой:
IF приватный ключ есть
THEN делаем ключевую пару trust=5
ELSE проверяем значение trust для имеющегося публичного ключа
END
Тогда, если приватного ключа нет, всё работало бы как и сейчас, а если есть, trust автоматически апдейтился бы до 5ти. Чем это плохо? Наверное, есть какие-то side-эффекты в случаях с нетривиальным использованием PGP-ключей, но при типичном использовании было бы больше удобства.
— SATtva (03/12/2012 16:15)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Пишите Вернеру в gnupg-users. Вряд ли Вам тут кто-то подскажет, какой логикой он руководствовался, вводя именно такое поведение, со свечкой не стояли.
— unknown (03/12/2012 16:37)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Может быть приватный ключ украден (скопирован без ведома автора), публично распостранён, но не отозван как скомпрометированный. Его можно скачать и поэкспериментировать с ним. Но доверия к его подписям и шифровкам нет уже никакого.

Могут быть и другие варианты разной степени умозрительности. GnuPG ведь предназначен не только для переписки, но и для разных сценариев использования.
— Гость (03/12/2012 22:33)   <#>
Может быть приватный ключ украден (скопирован без ведома автора), публично распостранён, но не отозван как скомпрометированный. Его можно скачать и поэкспериментировать с ним. Но доверия к его подписям и шифровкам нет уже никакого.

Да, это реалистичный сценарий, спасибо. Вопрос снят.
— Ajaja (22/12/2012 16:13)   <#>
Имеет ли возможность отправитель данных узнать сессионный ключ в самом банальном случае
gpg -e -r someoneelse somedata


Может. С опцией --debug=4 будет виден сессионный ключ.
— SATtva (22/12/2012 16:16)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
--show-session-key
— Ajaja (22/12/2012 16:19)   <#>
Я имел в виду кри кодировании :
gpg --debug=4 -e -r someoneelse somedata
Будет виден, какой сессионный ключ используется.
— Гость (23/09/2013 20:55)   <#>

Возвращаясь к обсуждению опции throw-keyids: хотелось бы иметь такую опцию в gpg.conf, но чтобы она применялась не ко всем ключам, а только к некоторым (если вдруг ширфуем для заданных абонентов, то они всегда должны идти, как hidden-recipient). Можно ли так сделать? Если встроенными средствами не сделать, но есть кривые костыли для реализации, то было бы тоже интересно о них услышать.
— SATtva (24/09/2013 12:30)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
GnuPG не поддерживает скриптование конфига. В рассылке несколько раз об этом просили, но разработчикам такой функционал неинтересен. В принципе, оно и понятно: по-хорошему (чтобы выдержать принципы GNU), надо написать собственный скрипт-обвязку, который будет разбирать опции -r и добавлять нужные параметры, если получатель входит в заданный список. Не вижу в этом ничего костыльного.
— Гость (24/09/2013 21:19)   <#>

Jabber-клиент сам по ему одному ведомым законам вызывает gpg для шифрования сообщений. Однако, системные настройки gpg.conf применяются. Как можно заскриптовать тот функционал, который жёстко засунут в сам код программ? Тем более, мне хочется иметь единую политику для контактов, т.е. если я знаю, что у данного абонента нет проблем с throw-keyids, я ему всегда так шифрую: хоть через джаббер, хоть напрямую.

Известно, что некоторые джаббер-клиенты дружат с throw-keyids, другие — нет. Это тоже характеристика, которая принуждает к дополнительным действиям.
— SATtva (25/09/2013 10:08)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Jabber-клиент сам по ему одному ведомым законам вызывает gpg для шифрования сообщений.

Подозреваю, что он просто вызывает gpg, так что выполнено будет то, что лежит в системном PATH. Замените бинарник gpg (предварительно переименовав) своим скриптом или добавьте путь со скриптом-обвязкой выше в PATH, короче, сделайте так, чтобы при вызове gpg запускался скрипт, который далее будет запускать gpg с нужными параметрами. Это уже костыль, но других вариантов не знаю.
— Гость (25/09/2013 20:02)   <#>

Непонятно, как такой костыль сделать. Опция -R (hidden-recipient) принуждает не только опускать keyid получателя, но и шифровать его ключом. Её указание по умолчанию будет означать, что сообщения, адресованные каким-то третьим лицам, будут всегда шифроваться ещё и ключами всех скрытых получателей; требуется же, чтобы опция применялась, только если шифруется для конкретного получателя. Соответственно, механическая замена самого gpg не поможет — надо ещё парсить и распознавать опции, с которыми gpg запускается jabber-клиентом, а я вообще без понятия, каковы эти опции.

В качестве костыля можно сделать вот что: разбить jabber-аккаунт на 2 таких, чтобы в одном были только скрытые получатели, а в другом — нескрытые. Jabber-клиент понимает переменную $HOME и опции GnuPG берёт именно из $HOME/.gnupg (проверено), поэтому указав разные $HOME разным jabber-профилям, где в каждом $HOME/.gnupg будут лежать свои настройки GnuPG, проблему можно решить.
— Беня (25/09/2013 21:28)   <#>

Подменить бинарник gpg на свой скрипт или батник если винда. Код внутри которого выведет на экран командную строку. Т.е. все те аргументы с которыми жабба-клиент пытался вызвать gpg при отправке шифрованного сообщения.
Учитесь слушать, что вам говорят, вместо того, чтобы недостаток своих навыков компенсировать изобретением "обходных маневров".
— SATtva (25/09/2013 21:35)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Соответственно, механическая замена самого gpg не поможет — надо ещё парсить и распознавать опции, с которыми gpg запускается jabber-клиентом, а я вообще без понятия, каковы эти опции.

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