GPG в недружественной среде
Здравствуйте!
Вопрос: Имеет ли возможность отправитель данных узнать сессионный ключ в самом банальном случае
gpg -e -r someoneelse somedata
с целью уличить получателя gpg сообщения в нечестности, если он "отказывается" расшифровывать ваше сообщение, под предлогом "испорченности сообщения".
Спасибо!
комментариев: 11558 документов: 1036 редакций: 4118
sentaus только что ведь исчерпывающе ответил:
В принципе, понятно. Я имел в виду, что логика могла бы быть и более сложной, типа такой:
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 9796 документов: 488 редакций: 5664
Могут быть и другие варианты разной степени умозрительности. GnuPG ведь предназначен не только для переписки, но и для разных сценариев использования.
Да, это реалистичный сценарий, спасибо. Вопрос снят.
Может. С опцией --debug=4 будет виден сессионный ключ.
комментариев: 11558 документов: 1036 редакций: 4118
gpg --debug=4 -e -r someoneelse somedata
Будет виден, какой сессионный ключ используется.
Возвращаясь к обсуждению опции throw-keyids: хотелось бы иметь такую опцию в gpg.conf, но чтобы она применялась не ко всем ключам, а только к некоторым (если вдруг ширфуем для заданных абонентов, то они всегда должны идти, как hidden-recipient). Можно ли так сделать? Если встроенными средствами не сделать, но есть кривые костыли для реализации, то было бы тоже интересно о них услышать.
комментариев: 11558 документов: 1036 редакций: 4118
Jabber-клиент сам по ему одному ведомым законам вызывает gpg для шифрования сообщений. Однако, системные настройки gpg.conf применяются. Как можно заскриптовать тот функционал, который жёстко засунут в сам код программ? Тем более, мне хочется иметь единую политику для контактов, т.е. если я знаю, что у данного абонента нет проблем с throw-keyids, я ему всегда так шифрую: хоть через джаббер, хоть напрямую.
Известно, что некоторые джаббер-клиенты дружат с throw-keyids, другие — нет. Это тоже характеристика, которая принуждает к дополнительным действиям.
комментариев: 11558 документов: 1036 редакций: 4118
Подозреваю, что он просто вызывает gpg, так что выполнено будет то, что лежит в системном PATH. Замените бинарник gpg (предварительно переименовав) своим скриптом или добавьте путь со скриптом-обвязкой выше в PATH, короче, сделайте так, чтобы при вызове gpg запускался скрипт, который далее будет запускать gpg с нужными параметрами. Это уже костыль, но других вариантов не знаю.
Непонятно, как такой костыль сделать. Опция -R (hidden-recipient) принуждает не только опускать keyid получателя, но и шифровать его ключом. Её указание по умолчанию будет означать, что сообщения, адресованные каким-то третьим лицам, будут всегда шифроваться ещё и ключами всех скрытых получателей; требуется же, чтобы опция применялась, только если шифруется для конкретного получателя. Соответственно, механическая замена самого gpg не поможет — надо ещё парсить и распознавать опции, с которыми gpg запускается jabber-клиентом, а я вообще без понятия, каковы эти опции.
В качестве костыля можно сделать вот что: разбить jabber-аккаунт на 2 таких, чтобы в одном были только скрытые получатели, а в другом — нескрытые. Jabber-клиент понимает переменную $HOME и опции GnuPG берёт именно из $HOME/.gnupg (проверено), поэтому указав разные $HOME разным jabber-профилям, где в каждом $HOME/.gnupg будут лежать свои настройки GnuPG, проблему можно решить.
Подменить бинарник gpg на свой скрипт или батник если винда. Код внутри которого выведет на экран командную строку. Т.е. все те аргументы с которыми жабба-клиент пытался вызвать gpg при отправке шифрованного сообщения.
Учитесь слушать, что вам говорят, вместо того, чтобы недостаток своих навыков компенсировать изобретением "обходных маневров".
комментариев: 11558 документов: 1036 редакций: 4118
Беня пояснил, что я предлагал. Никто не говорил, что это лёгкий путь. Скрипт для начала надо заставить просто писать в отдельный файл, с какими параметрами его вызывают внешние программы, оттрейсить таким образом вызовы jabber-клиента, и отталкиваться от этих данных при написании обвязки.