Кабинентный протокол

У тебя все еще батхерт по поводу петросяна? Это к проктологу.

Не очень понимаю схему работы, хорошо бы по пунктикам, а не в одну кучу.
Диффи-Хеллман есть асимметричный криптоалгоритм, одним ключом шифруем – другим расшифровываем.

Полегчало?

Это-то да.

А вот это совсем не так по отношению к DH.

Предыдущее объяснение протокола касалось самой ранней версии. Сейчас там наворотили протокол "социалистических миллионеров" для согласования аутентификации.

Описание протокола по ссылке выше.

Диффи-Хеллман есть асимметричный криптоалгоритм, одним ключом шифруем – другим расшифровываем.

Набрать в Яндексе Диффи-Хэлман не судьба, да.

Revealing MAC keys

Whenever you are about to forget either one of your old D-H key pairs, or one of your correspondent's old D-H public keys, take all of the receiving MAC keys that were generated by that key (note that there are up to two: the receiving MAC keys produced by the pairings of that key with each of two of the other side's keys; but note that you only need to take MAC keys that were actually used to verify a MAC on a message), and put them (as a set of concatenated 20-byte values) into the "Old MAC keys to be revealed" section of the next Data Message you send. This in done to allow the forgeability of OTR transcripts: once the MAC keys are revealed, anyone can modify an OTR message and still have it appear valid. But since we don't reveal the MAC keys until their corresponding pubkeys are being discarded, there is no danger of accepting a message as valid which uses a MAC key which has already been revealed.

Когда все аутентификационные параметры раскрыты, другая сторона (и даже прослушивающая, если я правильно понял), могут подделывать сообщения, которыми якобы обменивались A и B. Есть аутентификация (но только в момент сеанса связи) и отрицаемость (после завершения сеанса — в отличие от электронной подписи).

Я так понял, что после работы DH у 2х собеседников будет общий секретный ключ.

Да, но у собеседника останется открытый ключ оппонента. Если найдется приватный ключ к нему, анонимность пропадет. Можно что-то с этим сделать?

после окончания сеанса переписки каждый из контрагентов может опубликовать MAC-коды в Сети, а раз они опубликованы, то данную беседу мог провести любой.

А вот если известно время опубликования MAC-кодов, то как насчёт всего написанного до этого?

Я так понял, что после работы DH у 2х собеседников будет общий секретный ключ.

Именно. А симметричным ключом вторая сторона уже с момента его вычисления иожет заверять любые тексты. Публикация текста третьей стороне вместе с этим ключом и обрывками DH-параметров ничего не доказывает.

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

Это никак не позволит доказать подпись на сообщениях, так как подписываются не они, а параметры сеанса, а затем происходит отвязка на свойстве симметричной аутентификации: каждый, кто знает симметричный MAC-код аутентификации может подделывать любое сообщение. Плюс сам код совместно выработан сторонами. Нельзя доказать, что он исходил от кого-то конкретно из них.

А вот если известно время опубликования MAC-кодов, то как насчёт всего написанного до этого?

Они там при каждом сообщении кажется сбрасываются. И вообще, даже их публикация в открытую роли не играет. Вторая сторона с момента согласования кодов может подделывать текст. А если передаст третьей стороне — то сможет и третья, доказательности нет.

Протокол несколько раз менялся, есть некоторая путаница с описанием. Например в текущей версии предполагается начать связи с неаутентифицированного DH, проверить подлинность параметров внутри шифрованного туннеля, с помощью MAC отвязаться от подписей и начать передачу сообщений.

Может слайды по старой версии OTR облегчат понимание?

По крайней мере путём комбинирования DH и MAC такой протокол в разных вариантах возможен.

Они там при каждом сообщении кажется сбрасываются.

Вроде да:

In fact, they publish the old MK along
with the next message
– This lets anyone forge messages, but only
past ones
– Provides extra deniability

Вторая сторона с момента согласования кодов может подделывать текст

Подделавать то может, но вот по каналу связи с первой стороной передаются то не эти, а настоящие сообщения, и если эти шифрованные переговоры записываются "оппонентом" в реальном времени (и с отметками реального времени), то как выдать поддельные вместо них?

А потом это ведь как подделать надо, чтобы следователь (а на западе – судья) поверил...

если эти шифрованные переговоры записываются "оппонентом" в реальном времени (и с отметками реального времени), то как выдать поддельные вместо них? ... А потом это ведь как подделать надо, чтобы следователь (а на западе – судья) поверил...

OTR (да и вообще любое шифрование) не защищает от атаки вида "время всех сообщений записано, логи получены с такого-то компьютера и суд их считает достоверными, время получения сообщений адресатом соответствует времени прохождения сообщений через ISP и jabber-сервер". Подробней обсуждалось тут:

К примеру, администратор jabber-сервера может прийти в суд, показать логи и сказать: да, действительно, в такие-то времена с таких-то IP была зарегистрирована переписка того-то с тем-то, зашифрованная ключом таким-то. В свою очередь лица на местах могут подтвердить, что в данных местах за данными PC были действительно означенные лица. В крайнем случае могут назначить автороведческую экспертизу, эксперт по которой может в суде сказать "с высокой вероятностью этот текст действительно принадлежит означенному лицу". В то же время и обычный компьютерный эксперт может сказать "наличие ЭЦП и анализ подписанных ею текстов подтверждает, что приватный ключ действительно принадлежит лицу, в то время как аргументы о внезапной утере ключа несостоятельны, и экспертиза не видит никаких подтверждений этому окромя голословных утверждений со стороны лица". Т.е. суд в конечном счёте хотя и старается процедуру формализовать, но по факту опирается лишь на фактор обычной человеческой убедительности. Достаточность/убедительность тех или иных доказательств/аргументов/экспертиз также оценивается на глазок исходя из риторики стороны обвинения.

/comment39243 и

Поскольку тот же, например, jabber работает в режиме реального времени, то контрагент, с которым ведётся переписка, может назвать точные дата и время всех полученных сообщений. Если в сговор админа джаббер-сервера и контрагента никто не поверит, то получается почти доказательство

/comment31218

Вот ещё полезная информация:

Как уже говорилось ранее, использование OTR-шифрования позволит обезопасить себя от возможных попыток IM-службы/провайдера записать вашу переписку. Однако, провайдер по прежнему будет иметь возможность записать, с кем и как долго вы вели беседу, и, вероятно, время отправки и длину сообщений, которыми вы обменивались.

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

Из параграфа "Мгновенные сообщения".

Стоит обратить внимание на /comment19934 и /comment19953.

Что такое MAC? Это криптостойкая псевдослучайная функция ( PRF ) с симметричным ключом. Если в конкурсе SHA-3 победит идеальный хэш, то MAC ( M, k ) = SHA3-hash ( M || [длина сообщения] || k ) — условно как-то так. Сейчас из-за неидеальности хэшей пока используется более громоздкая конструкция из двух разных хэшей с промежуточными константами и ключом — HMAC. Для простоты понимания её можно представить в том же виде: как если бы к сообщению прибавили секретный ключ и просто посчитали хэш.

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

Стороны согласовались по неаутентифицированному DH (в новой версии вроде так). Т.е. A передала g^x mod (P), B передал g^y mod (P). P и g — публичные, фиксированные, одинаковые для всех в системе OTR параметры, чтобы образовывать нужную группу по Диффи-Хеллману; x и y — случайные секретные числа, генерируемые каждой стороной и выбрасываемые после сеанса. Стороны посчитали ( g^x )^y mod (P) = ( g^y )^x mod (P) = k, получили совместный параметр k, схэшировали его для надёжности (будем конечный результат согласования называть ключом k). Прослушивающая сторона не знает ни x, ни y, а только g^x mod (P) и g^y mod (P), полной информации для возведения в степень у неё нет. Поэтому придётся или заниматься мучительным и безуспешным вычислением дискретных логарифмов или делать подмену, атаку человека посредине (MITM).

Стороны уже имеют канал, шифрованный ключом k, но не уверены в подлинности установленной связи и отсутствии подмены данных (MITM). Внутри этого канала они могут подписать PGP-ключами свои параметры g^x mod (P) и g^y mod (P), чтобы проверить, что MITM не было. Доказывает это что-то? Да, факт того, что между ними был сеанс связи. Доказывает ли что-то метка времени на этих параметрах (если одна из сторон попытается передавать их для "доказательной" записи разговора)? Да, факт того, что сеанс между A и B был до того момента времени, когда его подали на проштамповку времени. А могли подать и с задержкой.

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

Сам OTR-протокол несколько сложнее и вероятно там учтены и более тонкие моменты. Чтобы даже публикация разговора с метками времени параметров ничего не доказывала.

Например, можно производить согласование по вопросам, не привязываясь к OpenPGP ключам:

Последние версии OTR-шифрования позволяют осуществить такое подтверждение с помощью известного вам и вашему собеседнику секретного слова, которое вы с ним должны ввести (например: "Как зовут друга, который нас познакомил?"). В более ранних версиях обоим пользователям было необходимо сверить в своей клиентской программе отпечаток публичного ключа, полученный от другого клиента.

/otr smpq [jid] secret
Initiate the Socialist Millionaires Protocol with the secret and the buddy

Чисто как пример. Интересней узнать не придумали ли они что-нибудь для отсылки сообщений в оффлайн, или это никак не вяжется с отрицаемостью?

Кое-что обсуждалось здесь. Неинтерактивная отрицаемость — более сложная задача.

OTR (да и вообще любое шифрование) не защищает от атаки вида "время всех сообщений записано, логи получены с такого-то компьютера и суд их считает достоверными, время получения сообщений адресатом соответствует времени прохождения сообщений через ISP и jabber-сервер".

Есть несогласные с этим утверждением?

А если OTR + Torchat? Анонимная среда (логи бессмысленны), ключей нет (соцмиллионер). Собственно протокол соцмиллионера предназначен для аутентификации без использования OpenPGP. Обе стороны могут сравнить текущий совместно выработанный симметричный ключ сеанса, "склеенный" с ответом на вопрос — в отсутствии MITM и знании ответа это значение должно совпасть, но не раскрыться прослушивающей стороне при неудачных попытках.