id: Гость   вход   регистрация
текущее время 12:41 28/03/2024
Автор темы: YuriW, тема открыта 13/12/2007 20:17 Печать
Категории: софт, gnupg, инфобезопасность, защита im
http://www.pgpru.com/Форум/РасширенияИДополнения/PidginGPG-ЕстьЛиПлагинДляСовместнойРаботы
создать
просмотр
ссылки

Pidgin + GPG – есть ли плагин для совместной работы?


Работаю в линукс. Пользуюсь Pidgin 2.3, протоколы ICQ и Jabber. Появилась необходимость приватных бесед. Есть ли возможность прицепить GPG к Pidginу? Плагин какой-нибудь? Сам пытался найти, пусто. Есть какой то заменитель со своей реализацией RSA, но это не подходит из-за ограниченности подхода. Кто нибудь сталкивался? Какие предложения могут быть?


 
На страницу: 1, 2, 3, 4, 5, 6 След.
Комментарии
— unknown (24/06/2013 16:00)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Речь шла об OpenPGP, затем стали говорить о сертификатах, надо полагать для стандарта S/MIME. А в OTR используется симметричная аутентификация вместо подписей, поскольку канал реального времени.
— Гость (24/06/2013 23:02)   <#>
Да там пароль используется для сессии.
— Гость (24/06/2013 23:14)   <#>
Предполагал, что при использовании OTR сообщения im переписки не могут быть прочитаны третьей стороной, и подделаны. Но получается это не так, можно mitmom влезать в зашифрованный диалог и подделывать сообщения?

Всё смешалось. :-(
  • MITM сделать нельзя ни в PGP, ни в OTR, если отпечатки сверены.
  • Шифрование и подпись (аутентификация) сообщений — совершенно независимые друг от друга параметры.
  • Наличие подписи и аутентификации сообщений (обоих вместе) не защищает от подделывания сообщений атакующим. В тех протоколах, где это слишком критично, защита от подделки достигается протоколом более высокого уровня. Ни в OTR, ни в PGP самих по себе такой защиты нет.
  • Возможность подделки не означает, что атакующий может произвольно менять произвольное сообщение в канале. Это означает лишь то, что он может вслепую (пользуясь сторонней какой-либо информацией) вмешиваться в протокол с тем или иным успехом: не давать некоторым сообщениям дойти, отсылать некоторые из сообщений повторно в любое время и т.д. Частичной мерой защиты от этого является подпись сообщений, содержащая метку времени. Если вы получили от адресата сообщение, подписанное им 10 лет назад, это повод усомниться в его подлинности.* Важно, что подпись (ЭЦП) сама по себе не является защитой от подделок, но повышает планку, которую надо преодолеть атакующему.

Или подразумувается что сами ключи переписки необходимо передавать по другим каналам, или pgp и тогда их просто ну будут знать, и влезть в диалог не смогут, правильно?

Это мимолётом обсуждавшийся отход от стандартой модели PGP. Он лишь частично помогает, но не реашет проблему. Не важно, знает атакующий ваши ключи или нет, если он сидит на канале, кто ему запретит посылать повторно уже вами посланные сообщения? Кто ему запретит их перехватывать, не доставляя адресату?

*Правда, стоит понимать, что сам адресат, владеющий своим приватным ключом, может как угодно подделывать метку времени, от этого защититься нельзя.
— sentaus (24/06/2013 23:22, исправлен 24/06/2013 23:23)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
Кто ему запретит их перехватывать, не доставляя адресату?

Запретить никто не сможет, такой вопрос криптография не решает. А вот обнаруживать потерю промежуточных сообщений, например, путём вставки счётчика в каждое сообщение, вполне можно. Это и от повторной пересылки также защищает. Вообще, всё это нужно сделать для XMPP в виде нового XEP, нынешний XEP-0027 – наколенная поделка.

— Гость (24/06/2013 23:37)   <#>
Вообще, поднятый вопрос глубокий. Так сказать, до публики начинает доходить то, что unknown писал ещё 5 лет назад: есть криптопримитивы и есть протоколы, причём из безопасности криптопримитивов безопасность протоколов не следует. Можно взять кучу безопасных кирпичиков, соединить их бездумно и получить ущербный небезопасный протокол. Когда хочется, чтобы в канале связи было «всё включено», PGP играет роль (макро)криптопримитива, а вот как на основе его создать протокол, где всё было бы безопасно (защита от вбросов, переотправок, от потерянных сообщений и т.д.) — это уже другой вопрос.

Кто ему запретит их перехватывать, не доставляя адресату?
Запретить никто не сможет, такой вопрос криптография не решает. А вот обнаруживать потерю промежуточных сообщений, например, путём вставки счётчика в каждое сообщение, вполне можно.

Может, неудачно выразился, хотя стараюсь быть предельно внятным, но да, именно это и имелось в виду: обнаруживать атаку вовремя.
— Гость (25/06/2013 00:09)   <#>
Почтовые сообщения нумеруются, причем поле Тема не должно иметь намека о теме переписки, а в IM каждое полученное сообщение подтверждается не односложными предложениями-ответами.
— Гость (25/06/2013 00:14)   <#>
MITM сделать нельзя ни в PGP, ни в OTR, если отпечатки сверены.

1. Есть ли необходимость сверять отпечатки, если обмен ключами производился из рук в руки или создан одной стороной для обеих сторон?
2. Как сверить отпечаток в OTR, если там используется парольная фраза?
— Гость (25/06/2013 00:22)   <#>
Наличие подписи и аутентификации сообщений (обоих вместе) не защищает от подделывания сообщений атакующим
Вот тут вопрос. Попробовал я подписать сообщение в Gpg4Usb, так для этого потребовался мой приватный ключ, а не открытый ключ получателя. Собственно сам вопрос:
– Как получатель произведет проверку подписи?
– Если сообщение подписывается не открытым ключом, сможет ли противник вбрасывать ложные сообщения?
— Гость (25/06/2013 01:32)   <#>
Почтовые сообщения нумеруются

И чем тут примитивная нумерация поможет?

Есть ли необходимость сверять отпечатки, если обмен ключами производился из рук в руки

Нет.

или создан одной стороной для обеих сторон?

Если после создания вы вынуждены передать ключ по недоверенному каналу, как мы можете быть уверенны в том, что ваше сообщение не было подменено? В этом случае сверять отпечатки нужно, да.

Как сверить отпечаток в OTR, если там используется парольная фраза?

Не во всех реализациях так. Подозреваю, что вы говорите о том случае, когда обе стороны кладут каждый себе один и тот же «предрасшаренный» секрет. Если они убедились в его идентичности, то ничего дополнительно подтверждать не надо. Убедиться в его идентичности можно, если абоненты обменяются копиями этого секрета, переданными друг другу с помощью PGP-зашифрованных и подписанных сообщений.

Как получатель произведет проверку подписи?

Если у получателя уже есть ваш публичный ключ, то командой gpg -d message (в выводе будет писаться в т.ч. и о наличии подписи) или gpg --verify message.

Если сообщение подписывается не открытым ключом, сможет ли противник вбрасывать ложные сообщения?

Сообщение всегда подписывается приватным ключом, иначе бы понятие подписи не имело смысла: любой из ваших абонентов, имеющий ваш публичный ключ, мог бы подписать ваше сообщение и выдать себя за вас. На уровне реализованных стандартов подписать сообщение открытым ключом невозможно.
— Гость (25/06/2013 02:52)   <#>
И чем тут примитивная нумерация поможет?
Наверно тем, что сообщения не потеряны. Вот так вот примитивно, но действено.

На уровне реализованных стандартов подписать сообщение открытым ключом невозможно.
Исходя из написанного, противник не может вбросить заведомо ложную инфу в случае, если в переписке принято подписывать сообщения.
— Гость (25/06/2013 02:56)   <#>
Прошу прощение. Здесь SSL сертификат неверно указана ссылка на страницу.
Правильно считать ЭТУ для генерации сертификата.
— Гость (25/06/2013 19:42)   <#>
Наверно тем, что сообщения не потеряны. Вот так вот примитивно, но действено.

Так вы предлагаете номера проставлять в том тексте, который будет шифроваться? Ну так это другое. The Bat эти номера не увидит, нужно будет писать собственные обвязки вокруг мейлера, чтобы эти номера автоматически выуживались из содержимого писем и как-то отображались в интерфейсе (ну, либо каждый раз анализировать их вручную).

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

Может. Никто ему не запретит перепослать сообщение в любой момент. Если перепосылка будет совершена быстро, в рамках дозволенного времени, вы даже не заметите, что что-то не так по метке времени. Всегда могут быть ситуации, когда это сработает, потому что невозможно вычислить точное время, которое должно пройти между подписью сообщения и его доставкой по сети получателю.

Да простит меня SATtva, сейчас покажу на практие, что имелось в виду, следующим сообщением (а то до кого-то упорно не доходит):
— SATtra (25/06/2013 19:45)   <#>
Ладно, всем добрых снов, буду к завтрашнему вечеру.
— Гость (27/06/2013 04:27)   <#>
Вообще, всё это нужно сделать для XMPP в виде нового XEP, нынешний XEP-0027 – наколенная поделка.

Говорить о надёжном протоколе шифрования, наверное, не слишком осмысленно, если вспомнить про такой факт, как отсутствие в XMPP куда более элементарной вещи: подтверждения доставки сообщений. При проблемах со связью джаббер часто теряет сообщения, и отправитель никогда не знает заранее, что дошло до адресата, а что нет, потому, что случись, каждый раз приходится это уточнять, пересылая друг другу логи.
— sentaus (27/06/2013 08:24, исправлен 27/06/2013 08:26)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
куда более элементарной вещи: подтверждения доставки сообщений.

XEP-0022, XEP-0085, XEP-0184 описывают это. 22 – устаревший, 85 и 184 – актуальный. И судя по внешнему поведению некоторых клиентов, что-то из этого даже используется.

На страницу: 1, 2, 3, 4, 5, 6 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3