Децентрализованные мессенджеры: сравнение протоколов для защиты конфиденциальной связи
Выбор децентрализованного мессенджера обычно ломают на первом же шаге. Пользователь видит маркировку E2EE, слово «децентрализованный» и делает неверный вывод: содержимое защищено, цензура невозможна, IP скрыт, группы безопасны.
Ни один из этих выводов не следует из другого.
Сквозное шифрование закрывает полезную нагрузку. Оно не обязано скрывать, кто с кем общается, когда отправляется сообщение, откуда клиент подключился и каков размер пакета. Федерация не равна анонимности. P2P не равно устойчивой офлайн-доставке. А блокчейн в этой задаче чаще вообще лишний: публичный реестр для переписки — архитектурная ошибка, а не усиление приватности.
Децентрализованные мессенджеры с шифрованием и выбор протокола нужно рассматривать по трём независимым осям: транспорт и маршрутизация, криптографическая модель групп, утечки метаданных. Matrix, XMPP с OMEMO, Session, SimpleX, Briar и MLS решают разные части этой задачи. Ставить их в один рейтинг «самых безопасных» технически бессмысленно.
Архитектура доставки: федерация, P2P и relay-сеть решают разные проблемы
Первый вопрос к мессенджеру не «есть ли шифрование», а «где лежит сообщение, пока получатель офлайн, и кто видит сетевой маршрут».
У федеративной архитектуры есть серверы, но нет единой обязательной точки контроля. У P2P-системы сообщения идут между устройствами, иногда через анонимизирующую сеть. У relay-сети сообщение ставится в очередь на промежуточном сервере, который должен доставить его дальше, не имея единого глобального аккаунта пользователя. Это три разных класса систем.
| Система / подход | Архитектура доставки | Что происходит с офлайн-получателем | Базовый компромисс |
|---|---|---|---|
| Matrix | Федерация homeserver-ов | Сервер хранит и синхронизирует события комнаты | Хорошая асинхронность, но серверы и федеративный граф видят метаданные |
| XMPP + OMEMO | Федерация XMPP-серверов | Сообщение проходит через серверную инфраструктуру к устройствам адресата | Зрелая транспортная модель, но безопасность зависит от клиента, сервера и верификации устройств |
| Session | Сеть с onion routing | Доставка опирается на узлы сети и асинхронную инфраструктуру | Скрытие IP даёт сетевой оверхед и более медленные TCP-соединения |
| SimpleX | Клиент-серверная сеть с однонаправленными очередями relay | Relay временно хранит сообщение до получения | Нет глобального идентификатора, но это не P2P и не магическая невидимость трафика |
| Briar | Прямая синхронизация устройств | Нужна одновременная доступность либо Briar Mailbox | Минимум центральной инфраструктуры, но хуже универсальная доставка |
| MLS | Не транспорт, а криптографический слой | Не определяет доставку | Требует отдельной сети, идентификации и политики группы |
Matrix: федерация с тяжелой операционной поверхностью
Протокол Matrix устроен вокруг homeserver-ов и комнат. Клиент не обязан доверять единому центральному оператору: можно развернуть свой сервер, участвовать в федерации, реплицировать события комнаты между доменами. Это отвечает на вопрос устойчивости к блокировке одного сервиса. Но не превращает Matrix в анонимную сеть.
Homeserver участвует в маршрутизации и хранении событий. Даже при E2EE он остаётся наблюдателем таймингов, объёмов, идентификаторов комнат и части служебной информации. Конкретный профиль утечек зависит от конфигурации, клиента, федеративного окружения и включённых функций, но базовый факт не меняется: шифрование тела сообщения не отменяет метаданные транспорта.
Для рабочих сообществ, технических DAO и команд с саморазвёртыванием Matrix рационален. У него есть понятная асинхронная модель, многопользовательские комнаты и нормальная эксплуатационная история. Но администратор, который называет федеративный чат «анонимным», не понимает собственный стек.
XMPP и OMEMO: федерация старше текущего хайпа
XMPP — не Web3-продукт и не «новый интернет». Это расширяемый федеративный транспорт, вокруг которого существует множество серверов и клиентов. OMEMO добавляет к нему модель сквозного шифрования, ориентированную в том числе на несколько устройств одного аккаунта.
Практически это выглядит так: для устройств контакта поддерживаются отдельные долгоживущие сессии Double Ratchet. Для каждого отправляемого сообщения создаётся новый ключ полезной нагрузки; затем этот ключ доставляется адресным устройствам через их сессии. Подход рабочий. Он хорошо ложится на модель «у одного человека ноутбук, телефон и резервный клиент».
Но в этой схеме много состояний, устройств и доверительных решений. Пользователь добавил новый клиент, не сверил ключи, проигнорировал предупреждение о fingerprint — и криптография превращается в красивую наклейку. XEP-0384 OMEMO версии 0.9.1 имеет статус Experimental. Это не приговор протоколу. Но это достаточная причина не описывать OMEMO как окончательно зафиксированный стабильный стандарт.
SimpleX: отсутствие глобального ID — полезное свойство, не индульгенция
SimpleX строится не вокруг публичного имени пользователя или постоянного глобального идентификатора. Его модель — клиент-серверная сеть с однонаправленными очередями и relay-серверами. Сообщение временно хранится на relay до момента получения, а данные о контактах и группах остаются на устройствах клиентов.
Это архитектурно интереснее многих «анонимных» приложений с централизованным каталогом пользователей. Наличие общей учётной записи почти всегда создаёт удобный индекс социальных связей. SimpleX этот индекс намеренно не формирует.
Но SimpleX не является чистой P2P-сетью. Relay существует, транспорт существует, сетевой наблюдатель существует. Защищённое клиент-серверное соединение с TLS 1.2 или TLS 1.3 не уничтожает анализ размеров сообщений и таймингов как класс атак. Более того, метка времени приёма сервером, по документации проекта, помещается в зашифрованный конверт с округлением до секунды. Это снижает доступность данных для relay, но не отменяет того, что сам факт сетевого обмена остаётся наблюдаемым на других уровнях.
Briar: если интернет исчез, модель связи меняется
Briar радикальнее в вопросе инфраструктуры. Он не опирается на центральный сервер: устройства синхронизируют сообщения напрямую. Когда интернета нет, могут использоваться Bluetooth, Wi‑Fi и даже карты памяти. При доступном интернете применяется Tor. Для асинхронной доставки предусмотрен Briar Mailbox.
Это не универсальная замена обычному корпоративному чату. Это инженерный ответ на более жёсткую модель угроз: сеть нестабильна, инфраструктура недоступна или нежелательна, а контактам нужна локальная синхронизация. Цена очевидна — доступность и UX. Если участники не бывают онлайн одновременно, прямой обмен превращается в проблему доставки. Mailbox закрывает часть проблемы, но добавляет отдельный инфраструктурный слой.
Чем меньше система знает о пользователях, тем больше она требует от их устройств, доступности сети и дисциплины верификации.
Session: IP скрывается не самим E2EE
Session использует Onion Requests для сокрытия IP-адреса. Это существенное отличие от систем, где E2EE работает поверх обычного клиент-серверного подключения. Если сервер мессенджера или наблюдатель на пути видит исходный IP пользователя, он получает очень сильный метаданный: связь между сетевым адресом, временем и активностью аккаунта.
Onion routing разрывает эту прямую привязку. Но за неё платят задержкой, нестабильностью и TCP-оверхедом. Скрытие маршрута — не бесплатная галочка в UI. Пакет проходит через дополнительные узлы, соединение становится тяжелее, а диагностика сетевых сбоев — хуже.
Для сценария «не давать сервису и собеседнику прямой IP-адрес» Session логичнее типичного федеративного чата. Для высокочастотной командной переписки с десятками активных потоков он может оказаться менее удобным именно из-за транспортной модели. Это не недостаток реализации. Это стоимость выбранной защиты.
Групповые ключи: где заканчивается маркетинг E2EE
Личные сообщения относительно понятны: есть два набора устройств, между ними устанавливаются ratchet-сессии, ключи регулярно меняются. Группы сложнее. Нужно добавлять и исключать участников, переживать офлайн-устройства, не переиспользовать ключевой материал, восстанавливаться после компрометации и не превращать каждое сообщение в N отдельных шифротекстов для N получателей.
Здесь обычно вспоминают три модели: Megolm в Matrix, OMEMO поверх XMPP и MLS как отдельный стандарт групповой криптографии.
Megolm: быстрый групповой ratchet с известной ценой
Matrix использует Olm для парного шифрования и Megolm для групповых комнат. Megolm удобен в эксплуатации: вместо шифрования полезной нагрузки отдельно для каждого участника группа использует общую сессию отправителя. Это снижает вычислительный оверхед и делает большие комнаты практичнее.
Но Megolm нельзя продавать как полноценную post-compromise security. Если атакующий получает ключевое состояние сессии, он может расшифровывать сообщения, зашифрованные от скомпрометированного значения ratchet и далее по цепочке. Спецификация прямо указывает, что для обновления защиты необходимо периодически создавать новую сессию с новыми ключами.
У Megolm также частичная forward secrecy. Сохранённое состояние ratchet у получателя позволяет читать сообщения после соответствующей точки сессии. И нет гарантии единого согласованного транскрипта для всех участников комнаты. Последний пункт часто игнорируют, потому что он плохо помещается в рекламную карточку приложения. Для аудита групповой истории и разбора спорных событий это не мелочь.
OMEMO: устройство как отдельный криптографический субъект
OMEMO строится иначе. Для каждого устройства контакта существует собственная сессия Double Ratchet, а ключ полезной нагрузки сообщения доставляется всем целевым устройствам. В обмен на лучшую адресность и понятную модель восстановления после компрометации система получает рост числа криптографических операций и сообщений управления.
В небольших группах это разумный обмен. В группе на сотни устройств — уже тяжёлый. Особенно если участники постоянно подключают и отключают клиенты, а приложение пытается честно поддерживать историю сессий, prekeys и верификацию.
Формат OMEMO использует AES-256-CBC, HMAC-SHA-256 и HKDF-SHA-256; HMAC в описанном формате полезной нагрузки усекается до 128 бит. Сами примитивы здесь не повод для тревоги. Уязвимость обычно возникает не в названии алгоритма, а в lifecycle ключей: как создаётся устройство, как пользователь видит смену идентичности, что происходит при потере локального хранилища, как клиент чистит устаревшие сессии.
MLS: стандартная модель для асинхронных групп
Messaging Layer Security, MLS, опубликован как RFC 9420, — наиболее формализованный из рассматриваемых подходов именно для асинхронных групп. Его область применения — от двух участников до тысяч. MLS проектировался вокруг прямой секретности и post-compromise security: группа способна восстанавливать криптографическую устойчивость после компрометации, когда честный участник снова вносит свежий секретный материал в состояние группы.
Ключевой механизм — sender ratchet для каждого отправителя. Одна пара ключ/nonce может использоваться не более чем для одного сообщения. Использованные секретные значения должны удаляться. Это не декоративная деталь спецификации: повтор nonce с тем же ключом — прямой путь к криптографической аварии, а хранение старых секретов ломает смысл forward secrecy.
MLS не является мессенджером. У него нет собственного ответа на вопросы:
1. Как участник получает приглашение в группу и как проверяется его идентичность.
2. Где хранятся сообщения для офлайн-клиента.
3. Кто доставляет commit-сообщения при изменении состава группы.
4. Как участник синхронизируется после пропуска эпохи.
5. Какие метаданные видит транспорт.
6. Как устроена модерация и отзыв доступа в прикладном слое.
Именно тут многие Web3-команды совершают типовую ошибку: берут сильный криптографический стандарт и считают, что этим закрыли архитектуру приложения. Нет. MLS закрывает значимый, но ограниченный слой.
| Свойство | Matrix Megolm | XMPP + OMEMO | MLS |
|---|---|---|---|
| Основная модель | Групповой sender ratchet | Парные Double Ratchet-сессии между устройствами | Формализованное управление состоянием группы и эпохами |
| Масштабирование групп | Практично за счёт общей групповой сессии | Оверхед растёт с числом устройств получателей | Проектируется для групп от 2 до тысяч участников |
| Forward secrecy | Частичная, с ограничениями состояния ratchet | Зависит от корректной работы парных сессий | Заложена в протокол при корректном удалении секретов |
| Post-compromise security | Не обеспечивается Megolm сам по себе | Связана с обновлением Double Ratchet-сессий | Явная цель архитектуры |
| Статус в экосистеме | Реально используется в Matrix | XEP-0384 0.9.1 — Experimental | RFC 9420, но не готовое приложение |
| Главный риск внедрения | Длинная жизнь сессии и компрометация состояния | Неверифицированные устройства, множество сессий | Ошибки в транспорте, идентификации и управлении группой |
E2EE без ротации ключей и верификации устройств — не защита, а отсроченная уязвимость с хорошим интерфейсом.
Метаданные: шифртекст не скрывает социальный граф
В защищённом чате есть минимум четыре разных наблюдателя:
- сервер или relay, через который проходит сообщение;
- интернет-провайдер или оператор сети пользователя;
- глобальный или локальный пассивный наблюдатель трафика;
- злоумышленник, получивший доступ к разблокированному устройству или локальной базе.
E2EE в первую очередь ограничивает сервер и промежуточные узлы в чтении содержимого. Оно не делает бессмысленными остальные три модели.
MLS, например, шифрует данные отправителя в сообщении. Но транспортный наблюдатель всё ещё может видеть сведения о состоянии группы, включая потенциально её состав. Поэтому стандарт рекомендует переносить MLS-сообщения по защищённому транспорту, например TLS или QUIC. Это базовая санитария канала. Она не превращает TLS в систему защиты социального графа.
OMEMO прямо не заявляет защиты от анализа метаданных и трафика. Matrix также не следует оценивать только через Olm и Megolm: нужно смотреть, какие события остаются на сервере, как устроена федерация, какие идентификаторы комнат используются, кто администрирует homeserver и какие резервные копии включены.
Session выделяется именно защитой IP через onion routing. Briar использует Tor при интернет-соединении и локальные каналы без интернета. SimpleX минимизирует привязку к глобальному ID через очереди и relay-модель. Но ни один из этих подходов не даёт «полной анонимности» в вакууме.
Анализ трафика работает по корреляции. Если в 10:03 один клиент отправил 4 КБ, а в 10:03 другой получил 4 КБ, шифрование содержимого не отменяет статистику. Padding, смешивание потоков, задержки, многоскачковая маршрутизация и cover traffic могут снижать сигнал. Но каждый из этих механизмов увеличивает задержку, расход трафика, вычислительный оверхед или сложность эксплуатации.
Для анонимных мессенджеров для DAO это особенно неприятно. DAO часто публикует управление, голосования, роли и казначейские адреса. Если один и тот же участник использует рабочий чат, публичный ENS-идентификатор, форум и кошелёк без разделения контекстов, мессенджер не исправит операционную небрежность. Криптография не лечит correlation by user behavior.
Почему «защищённые чаты на блокчейне» почти всегда плохая формулировка
Блокчейн полезен там, где нужна проверяемая общая история состояния без доверенного оператора. Сообщения требуют другого: конфиденциальности, дешёвой доставки, отзывов ключей, удаления локального состояния, контроля метаданных и низкой задержки.
Публиковать сообщения или их содержательные метаданные в публичной сети — значит создавать вечный журнал. Шифрование не делает такой журнал безопасным на бесконечном горизонте: криптостойкость деградирует, ключи утекут, реализации будут сломаны, а корреляция данных улучшится. Хэш от сообщения тоже не нейтрален, если исходное сообщение короткое или предсказуемое: его можно перебрать.
Блокчейн может быть внешним компонентом идентичности, реестра ключей или механизма управления доступом. Но даже в этих ролях он требует осторожности. Публичная привязка DID, ключа и адреса кошелька часто ухудшает приватность сильнее, чем упрощает онбординг.
Web3-мессенджеры без цензуры должны доказывать не наличие токена и не интеграцию кошелька, а более прозаичные вещи:
- какие данные видит relay, homeserver или push-провайдер;
- можно ли использовать систему без постоянного публичного идентификатора;
- как устроена верификация новых устройств;
- что происходит при компрометации ключа группы;
- кто контролирует обновления клиента и серверной инфраструктуры;
- как система ведёт себя при частичной блокировке сети;
- можно ли воспроизвести криптографический и сетевой threat model по документации, а не по лендингу.
Если на эти вопросы отвечают словом «blockchain», перед вами не архитектура, а маркетинговая заглушка.
Что выбирать для конкретной модели угроз
Единого победителя нет. Есть набор технических соответствий между задачей и протоколом.
1. Для устойчивого командного чата с собственным сервером и комнатами подходит Matrix, если организация принимает федеративные метаданные и умеет администрировать homeserver. Шифрование комнат не отменяет необходимость контролировать участников, бэкапы и жизненный цикл Megolm-сессий.
2. Для федеративной переписки с несколькими устройствами на пользователя рационален XMPP с качественной реализацией OMEMO. Ключевое слово здесь — качественной. Клиент должен ясно показывать состояние верификации, изменения ключей и список устройств. Без этого многодевайсная модель становится источником неопределённости.
3. Для сценария, где скрытие IP важнее скорости соединения, уместнее Session. Onion routing закрывает конкретную утечку, которую обычное E2EE обычно не закрывает. Платой будет производительность и сетевой оверхед.
4. Для минимизации глобальной идентифицируемости в асинхронных личных и групповых контактах интересен SimpleX. Его relay-очереди и отсутствие общего user ID — осмысленная архитектурная ставка. Но называть это P2P нельзя, а считать транспортный анализ устранённым — тем более.
5. Для связи в условиях нестабильной или недоступной интернет-инфраструктуры Briar выделяется прямой синхронизацией, Tor и локальными каналами. Это специализированный инструмент, не замена Slack или Matrix для любой организации.
6. Для нового группового приложения, где требуется современная криптографическая модель на сотни или тысячи участников, MLS выглядит предпочтительным фундаментом. Но команде всё равно придётся реализовать транспорт, управление членством, доставку, синхронизацию и защиту метаданных. Именно в этих слоях чаще всего и появляется уязвимость.
Вердикт: сначала модель угроз, потом приложение
Сравнение протоколов децентрализованных мессенджеров нельзя завершить словами «этот безопаснее». Matrix лучше решает федеративную эксплуатацию. OMEMO естественно работает с множеством устройств, но остаётся Experimental-спецификацией и требует дисциплины верификации. Session заметно сильнее по защите IP, расплачиваясь скоростью. SimpleX сокращает идентификационный след, не становясь P2P. Briar полезен там, где обычная сеть перестаёт быть надёжной. MLS даёт наиболее строгую криптографическую базу для асинхронных групп, но не заменяет приложение.
Финальный тест простой. Если продукт обещает конфиденциальность, спросите, какой именно слой он защищает: содержимое, ключи группы, IP, социальный граф, офлайн-доставку или устойчивость к блокировке. Ответ «всё, потому что децентрализация» означает, что архитектуру никто не анализировал.
Технический вердикт жёсткий: выбирайте не мессенджер с самым громким ярлыком, а систему, чьи утечки совпадают с теми рисками, которые вы действительно готовы принять.
