> Пользователь с другой стороны знает -- отлично. А человек по-середине не должен.

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

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

> В данном случае вы сливаете то что можно будет подобрать (хэш).

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

> Вот на этом и закончим этот тред. DH нужен для установления сессионных
> одноразовых ключей, чтобы при компрометации shared ключа нельзя было дешифровать ранее
> перехваченный трафик.

Ну если 1 раз секретным дуплом можно пользоваться, то наверное можно и 2 раза. Изничтожив старый ключ. Получится PFS с ручным приводом. DH хорош тем что позволяет снизить требования в плане дупел и автоматизирует процесс. Но вот рассуждения про zero knowledge и buzz вокруг оного мне малопонятен. На практике обоим сторонам линка надо знать некий shared secret, что по сути является вариантом на тему секретного дупла. И на практике то как это в OTR сделано - я вообще не очень понимаю как этим можно воспользоваться и чтобы это еще и работало. А код распух изрядно, да и весь протокол.

> Свойство это называется perfect forward secrecy.

Спасибо, Кэп. Я в курсе. Но кажется немного увлекся с утрированием.

> Более того: как вы аутентифицируете противоположную сторону при установлении соединения? Будете просто
> посылать сразу данные, ведь всё-равно их дешифровать не смогут, сливая факты
> возникновения пакетов и их размеры?

Факт возникновения пакетов - всяко будет виден даже пассивному наблюдателю в канале (хоть тому же серверу, который сообщения между пользователями OTR посылал). Если это не нравится - это уже заявка на какую-то стеганографию и серьезное "кондиционирование" траффика. В otr этим никто не заморачивался особо и это уже заявка на более другие подходы, имхо.

Сервер (пассивный сниффер, ...) видят времянки и примерные размеры. И факт что Вася и Петя сообщения кидали (за счет большинства протоколов поверх которых OTR запускался). Хоть и шифрованные OTR (для полного счастья там еще и хидеры характерные долеплены, чтобы никто не сомневался). В результате даже пассивный сниффер получает не так уж и мало информации как могло бы в принципе хотеться Васе и Пете. Так что насчет свойств - истинный параноик всегда будет недоволен :P.

> Без всего этого можно обойтись, но для кого-то тот же PFS штука обязательная.

Ну если очень хотеть - его можно и педально-дупельным методом устроить. Но с DH разумеется практичнее получается. Но той "zero knowledge" проверки это как-то особо не касается. На мой взгляд оно довольно бесполезная хрень, которая только зря все усложняет. В смысле, на что у меня продвинутые знакомые, но эту фиговину применить не вышло, так что практиковалась обычная сверка fingerprint-ов.

> установления сессионного ключа: но зачем когда есть довольно быстрый curve25519 уже?

Ну вот я и думаю что циферпанкам могло бы иметь смысл посмотреть на все это и сделать заново. В 20 раз компактнее и проще и не особо профукав свойства.

> Верно. Но эта возможность остаётся. Тогда как в zero knowledge системах нет.

В случае OTR ремота с которой сессия установлена - видит fingerprint. Хоть там что. А этой ремотой может быть в общем случае кто угодно вплоть до MITM и уповать в таких условиях на то что fingerprint не утечет - довольно странно, чтоли.