Pidgin + GPG – есть ли плагин для совместной работы?
Работаю в линукс. Пользуюсь Pidgin 2.3, протоколы ICQ и Jabber. Появилась необходимость приватных бесед. Есть ли возможность прицепить GPG к Pidginу? Плагин какой-нибудь? Сам пытался найти, пусто. Есть какой то заменитель со своей реализацией RSA, но это не подходит из-за ограниченности подхода. Кто нибудь сталкивался? Какие предложения могут быть?
комментариев: 9796 документов: 488 редакций: 5664
Всё смешалось. :-(
Это мимолётом обсуждавшийся отход от стандартой модели PGP. Он лишь частично помогает, но не реашет проблему. Не важно, знает атакующий ваши ключи или нет, если он сидит на канале, кто ему запретит посылать повторно уже вами посланные сообщения? Кто ему запретит их перехватывать, не доставляя адресату?
*Правда, стоит понимать, что сам адресат, владеющий своим приватным ключом, может как угодно подделывать метку времени, от этого защититься нельзя.
комментариев: 1060 документов: 16 редакций: 32
Запретить никто не сможет, такой вопрос криптография не решает. А вот обнаруживать потерю промежуточных сообщений, например, путём вставки счётчика в каждое сообщение, вполне можно. Это и от повторной пересылки также защищает. Вообще, всё это нужно сделать для XMPP в виде нового XEP, нынешний XEP-0027 – наколенная поделка.
ущербныйнебезопасный протокол. Когда хочется, чтобы в канале связи было «всё включено», PGP играет роль (макро)криптопримитива, а вот как на основе его создать протокол, где всё было бы безопасно (защита от вбросов, переотправок, от потерянных сообщений и т.д.) — это уже другой вопрос.Может, неудачно выразился, хотя стараюсь быть предельно внятным, но да, именно это и имелось в виду: обнаруживать атаку вовремя.
1. Есть ли необходимость сверять отпечатки, если обмен ключами производился из рук в руки или создан одной стороной для обеих сторон?
2. Как сверить отпечаток в OTR, если там используется парольная фраза?
– Как получатель произведет проверку подписи?
– Если сообщение подписывается не открытым ключом, сможет ли противник вбрасывать ложные сообщения?
И чем тут примитивная нумерация поможет?
Нет.
Если после создания вы вынуждены передать ключ по недоверенному каналу, как мы можете быть уверенны в том, что ваше сообщение не было подменено? В этом случае сверять отпечатки нужно, да.
Не во всех реализациях так. Подозреваю, что вы говорите о том случае, когда обе стороны кладут каждый себе один и тот же «предрасшаренный» секрет. Если они убедились в его идентичности, то ничего дополнительно подтверждать не надо. Убедиться в его идентичности можно, если абоненты обменяются копиями этого секрета, переданными друг другу с помощью PGP-зашифрованных и подписанных сообщений.
Если у получателя уже есть ваш публичный ключ, то командой gpg -d message (в выводе будет писаться в т.ч. и о наличии подписи) или gpg --verify message.
Сообщение всегда подписывается приватным ключом, иначе бы понятие подписи не имело смысла: любой из ваших абонентов, имеющий ваш публичный ключ, мог бы подписать ваше сообщение и выдать себя за вас. На уровне реализованных стандартов подписать сообщение открытым ключом невозможно.
Исходя из написанного, противник не может вбросить заведомо ложную инфу в случае, если в переписке принято подписывать сообщения.
Правильно считать ЭТУ для генерации сертификата.
Так вы предлагаете номера проставлять в том тексте, который будет шифроваться? Ну так это другое. The Bat эти номера не увидит, нужно будет писать собственные обвязки вокруг мейлера, чтобы эти номера автоматически выуживались из содержимого писем и как-то отображались в интерфейсе (ну, либо каждый раз анализировать их вручную).
Может. Никто ему не запретит перепослать сообщение в любой момент. Если перепосылка будет совершена быстро, в рамках дозволенного времени, вы даже не заметите, что что-то не так по метке времени. Всегда могут быть ситуации, когда это сработает, потому что невозможно вычислить точное время, которое должно пройти между подписью сообщения и его доставкой по сети получателю.
Да простит меня SATtva, сейчас покажу на практие, что имелось в виду, следующим сообщением (а то до кого-то упорно не доходит):
Говорить о надёжном протоколе шифрования, наверное, не слишком осмысленно, если вспомнить про такой факт, как отсутствие в XMPP куда более элементарной вещи: подтверждения доставки сообщений. При проблемах со связью джаббер часто теряет сообщения, и отправитель никогда не знает заранее, что дошло до адресата, а что нет, потому, что случись, каждый раз приходится это уточнять, пересылая друг другу логи.
комментариев: 1060 документов: 16 редакций: 32
XEP-0022, XEP-0085, XEP-0184 описывают это. 22 – устаревший, 85 и 184 – актуальный. И судя по внешнему поведению некоторых клиентов, что-то из этого даже используется.