Недостатки OTR


Всем привет.
Один человек навязчиво предлагает использовать OTR вместо GPG для джаббера или аськи.
Я доверяю GPG, это общепринятый серьезный стандарт в мире линукс (им подписываются репозитории, пакеты, его используют всяческие джаббер-клиенты и т.д.). Т.е. я настолько в нем уверен, что даже и никогда не приходило в голову использовать что-то ещё. Неужели OTR лучше GPG для безопасной переписки?
В чем недостатки OTR перед GPG?
Есть ли какие решающие преимущества у GPG, позволяющие наотрез отказаться от использования OTR? Причем, сделать это аргументированно.

Спасибо

Комментарии
— unknown (28/04/2014 16:42)   
Поищите в форуме, горячие обсуждения достоинств OTR уже были. Также как и недостатков PGP[link1].
Гость (29/04/2014 02:57)   

Не надо отказываться ни от того, ни от другого. Рекомендую использовать их совместно, т.е., шифровать канал связи как через OTR, так и через PGP. Современные джаббер-клиенты это позволяют.
— unknown (29/04/2014 10:00, исправлен 29/04/2014 10:01)   

Основная фича OTR следует из его названия, «незаписываемость», точнее отрицаемая аутентификация. Некому Бобу некая Алиса может доказать, что это именно она с ним связывается, но Боб это не может доказать окружающим.


А в OpenPGP/GnuPG аутентификация строится только на подписях, т.к. изначально он предназначен не для интерактивных протоколов, а для почты. Т.е. Алиса и Боб подписывают все свои сообщения и злонамеренный Боб может втянуть Алису в компрометтирующую беседу, раскрыть её расшифрованный текст и показать, что текст подписан ключом Алисы. Также может сделать и Алиса по отношению к Бобу — доказательно слить его переписку.


Мессаджинг позволяет выполнить совместный интерактивный протокол, когда обе стороны одновременно на связи и можно отвязать подписи от аутентификации.



Это имеет такой недостаток, как уничтожение отрицаемости и наперёд заданной секретности OTR (если стороны не сохраняют переписку, то после принудительной выдачи или похищения ключей её невозможно расшифровать по перехваченному и записанному шифрованному трафику, что неверно для OpenPGP). Недостаток очевиден, а в чём достоинства совместного использования?

— SATtva (29/04/2014 10:13, исправлен 29/04/2014 10:15)   
А в OpenPGP/GnuPG аутентификация строится только на подписях, т.к. изначально он предназначен не для интерактивных протоколов, а для почты.

Месяц-полтора назад в OpenPGP WG обсуждался[link2] черновик спецификации кольцевых подписей[link3] для OpenPGP. Идея довольно проста: отправитель шифрованного сообщения указывает получателя, и OpenPGP-приложение генерирует кольцевую подпись на основании их ключей. В итоге получатель имеет аутентифицированное сообщение, но доказать третьей стороне, что его отправителем действительно был реальный отправитель (а не сам получатель), не может. Аналогично механизм расширяется и на группу получателей.


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

— unknown (29/04/2014 10:59)   
Мы тут тоже утонули в обсуждениях[link4] как достичь одновременно отрицаемости и незаписываемости (отрицаемой аутентификации) в оффлайновой переписке. Участник gegel[link5] пытался рассмотреть возможность реализации такой схемы, но у меня после совместного с ним перелопачивания ссылок на исследования в этой области сложилось мнение, что это нерешённая теоретическая задача.

А кольцевые подписи — хорошее дело, но как верно замечено, половинчатое. OTR возник как замена кольцевых подписей в интерактивном протоколе.
— mark2000 (29/04/2014 12:18)   
Вопрос простой – для джаббера что лучше-то? GPG или OTR?
mcabber будет работать с OTR?
— SATtva (29/04/2014 12:27, исправлен 29/04/2014 12:27)   

Для IM-переписки OTR предпочтительнее за счёт отрицаемости и PFS.



Да.

— unknown (29/04/2014 15:30, исправлен 29/04/2014 15:41)   

Похоже, ничего они с таким настроем делать не будут. Что-то там в рассылке GnuPG преобладают мнения, что отрицаемость не нужна и приводятся больше ссылки на такого рода соображения[link6]:


The most basic argument against OTR's deniability is that courts don't care about cryptographic proof for digital evidence. People are convicted or lose civil cases based on unsigned electronic communications (e.g. normal e-mail, plain chat logs) all the time. OTR's deniability doesn't provide any legal cover stronger than trying to claim you didn't write a given e-mail that appears to have originated from your account. As someone who understands the forgeability of e-mail, i find this overall situation troubling, but it seems to be where we are.

Worse, OTR's deniability doesn't cover whether you had a conversation, just what you said in that conversation. That is, Bob can still cryptographically prove to an adversary (or before a judge or jury) that he had a communication with someone controlling Alice's secret key (which is probably Alice); he just can't prove that Alice herself said any particular part of the conversation he produces.

Похоже, GnuPG разрабатывается по идеологической модели, на которую я ранее указывал[link7]: это идеальное средство для открытых разработчиков открытого ПО. Или каких-то схожих сообществ, которым не нужны ни анонимность, ни отрицаемость, ни долговременная секретность. «Невозможность» откреститься перед непонятливыми пользователями от простановки в чьё-то сообщение с кольцевой подписью их даже раздражает.

— SATtva (29/04/2014 15:55)   
Насколько помню, Вернер не высказывался против идеи, как таковой, у него скорее были замечания в плане реализации. Каллас тоже поддержал.
Гость (29/04/2014 20:18)   

Не может, PGP-подписей там нет[link8] (клиентов, работающие не по стандарту[link9], пока оставим в стороне).


Это зависит от того, что идёт внутри, а что снаружи (OTR или PGP). Если через OTR передаются шифрованные (но неподписанные!) сообщения, то не вижу, чем это хуже в плане отрицаемости.


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


mcabber поддерживает, GPG (XEP-0027), OTR, а также GPG и OTR одновременно.


н[link10]и PGP[link7], ни OTR[link11] не дают юридической отрицаемости.

По мотивам этих обсуждений unknown написал пост[link12], о существовании которого уже не помнит сам:

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

Всё это не новость, в общем. Нормального IM у нас нет. Нормальный IM обязан быть, как минимум, децентрализованным и анонимным по сути своей архитектуры. Пока ближе всего к этому организация IRC-серверов поверх инфраструктуры HS или TorChat, но, мало того, что у него есть свои проблемы[link13], к нему не подцепить интерфейсы привычных IM-клиентов (тот же джаббер), не подцепить для подстраховки PGP или OTR (чтобы, как это было с HeartBleed OpenSSL, не сосать потом лапу)...


Плохо написано. Насколько я знаю, в OTR нету «секретного ключа Алисы», есть «секретный ключ, который общий для Боба и Алисы; он такой же Алисовский, как и Бобовский».
— unknown (30/04/2014 09:55)   

Я в контексте той дискусии, саму её не хочу приводить целиком, кому интересно, может почитать в рассылке. Дело в том, что это там приводится как аргумент, что раз в такой ситуации не помогает, то и вообще не нужно. Т.е. нужно непонятно кому и в каких-то редких ситуациях. И никто особо не возразил. Другие говорят, пусть будет, но чтобы отдельным подключом — кому надо, пусть вешает такой ключ на связке. В то время как автор предложения разумно (на мой взгляд) говорит, что это должно быть реализовано так, чтобы работать со всеми ключами, без каких-либо предварительных действий по согласию включения пользователей в кольцо, иначе предложение в значительной части теряет смысл.


Действительно, возможно просто плохо написано. Боб может показать, что у него есть обрывок сеанса, в котором Алиса заверяла параметры согласования общего ключа своим закрытым асимметричным ключом. Формально ничего не доказывает — он мог перехватить такой кусок трафика откуда угодно, но если считать, что на строгие формальные доказательства всем пофиг и все судят по бытовой логике, то вопрос «откуда иначе у Боба кусок трафика Алисы, в котором она начинает сеанс отрицаемого согласования, значит они всё-таки переписывались, ну не АНБ же перехватило сеанс Алисы, например, с Кэрол и выдало кусок трафика Бобу?» эксперты могут представить как убедительное обоснования для неразбирающейся публики.

Похожим образом в рассылке GnuPG обосновывается опасение для кольцевых подписей. Что большинству пользователей это якобы не будет нужно и такая неинтуитивная штука будет их путать, когда их будут включать в кольцо подписантов без их согласия, а им надо будет объяснять, что они ничего не подписывали и разъяснять определение кольцевой подписи тем, кто это не понимает. Особенно в случае какого-то скандала, когда кольцевые подписи используются для публикации утечки секретов из какого-то сообщества.
— gegel (30/04/2014 11:43)   
В принципе, при использовании GPG можно достичь отрицаемой аутентификации, отказавшись от подписей и использовав протокол Abadi (обменяться nonce), но надо четко понимать, что вы делаете, и какие атаки возможны. Для этого просто внимательно прочитать описание протокола[link14] и выполнить его с GPG в ручном режиме.

Что касается отрицаемости вообще, то она обычно рассматривается в такой модели: Алиса и Боб (идентифицируются своими ключами) устанавливают связь, за ними наблюдает информант, задача которого – убедить судью в том, что связь имела место. также есть дезинформант, который хочет убедить судью в факте связи, хотя связи на самом деле не было. Если судья сумеет отличить информанта от дезинформанта, то протокол неотрицаемый. Информантом может быть один из участников, в этом случае важно, на каком этапе он контактирует с судьей – до начала протокла, во время его или после завершения.
Помотрите работу Кравчика[link15] с теорией отрицаемости. Кроме того, выделяют неполную отрицаемость: когда участники не могут отрицать, что выполняли протокол, но могут отрицать, что выполняли его конкретно с конкретной стороной (peer denyability), или конкретно в данное время, а не раньше (time denyability). Вобще, мне кажется, это красивые математические игрушки, не особо вписывающиеся в реальный мир.

Как по мне, то PFS гораздо более важна для практического использования.
Гость (30/05/2014 08:17)   

Опять «плохо написано»? Откуда в OTR появится заверение обрывка сеанса приватным ключом другого абонента? Я так понимаю, если б так было, в обычном онлайновом OTR не было бы никакой отрицаемости.


Интересная классификация.


Реальный мир существует тысячелетия, а возраст криптографии — пол века. Со временем красивые игрушки будут всё лучше приближаться к тому, что нужно в реальном мире. На начальном этапе даже внятная продуманная классификация, систематизация и постановка проблем — уже достижение.
Гость (26/02/2015 17:09)   
Я слышал, что purple, на котором основан otr-плагин для pidgin, очень дырявый.

Ссылки
[link1] https://www.pgpru.com/biblioteka/statji/13reasonsnottostartusingpgp

[link2] http://www.ietf.org/mail-archive/web/openpgp/current/msg07208.html

[link3] https://www.pgpru.com/comment69586

[link4] https://www.pgpru.com/forum/kriptografija/analogpgpsobespecheniemotricaemostiinaperjodzadannojjsekretnostiofflajjn

[link5] https://www.pgpru.com/proekt/poljzovateli?profile=gegel

[link6] https://www.debian-administration.org/users/dkg/weblog/104

[link7] https://www.pgpru.com/comment71894

[link8] https://www.pgpru.com/comment25960

[link9] https://www.pgpru.com/comment41042

[link10] https://www.pgpru.com/comment73484

[link11] https://www.pgpru.com/comment71034

[link12] https://www.pgpru.com/comment73612

[link13] https://www.pgpru.com/comment62824

[link14] http://research.microsoft.com/en-us/um/people/fournet/papers/private-authentication-tcs.pdf

[link15] https://eprint.iacr.org/2006/280