Шифрование метаданных в мессенджере: HMAC-SHA256 анонимные пары, timing obfuscation и отравление собственных логов

[ImagineTables]

Подписался на вас, чтобы узнать, когда можно будет протестировать готовую .apk'шку.

[K0Jlya9]

Для того чтобы сервер не знал кто когда и с кем через него общается, надо избавиться от сервера. Зачем он нужен в анонимном мессенджере с е2е шифрованием?

Серверов должно быть много независимых, и они должны выполнять какую-то другую функцию, например поддерживать виртуальную IPv6 сеть для прямого соединения клиентов, не только для мессенджинга, но и вообще для любой полезной цели — RDP и т.п.

[Yuri__M]

Можно сделать систему, похожую на ТОР - где входящий сервер знает лишь, кто отправляет, но не кому, промежуточные - знают лишь о соседних, а конечный - знает кому, но не кто. И только сам получатель видит, кто и что ему отправил.

И добавить для больших сообщений (файлы etc) дробление на кусочки и передачу их разными цепочками, в духе i2p.

[Svortex]

Юрий, по сути вы описали onion routing (Tor) + garlic routing (I2P). И да, это сильнее, чем что-либо на уровне приложения — я об этом честно написал в разделе 11.

Идея с дроблением файлов по разным цепочкам вообще красивая — убирает корреляцию по размеру пакетов. Взял на заметку, спасибо.

Но вот почему я пока пошёл другим путём: в Tor каждый hop — это +1–5 секунд задержки. В мессенджере, где человек видит «печатает...» и ждёт ответ через секунду, это больно. I2P ещё медленнее. Плюс для реальной анонимности нужно много независимых узлов — если их мало, вся схема рассыпается. А телефон relay-узлом быть не может — батарея и мобильный трафик не позволят.

Metadata Guard — это то, что реально работает сегодня в рамках клиент-серверной модели, без внешних зависимостей. Onion routing — следующая ступень, но это отдельный большой проект. Пока в roadmap'е — федерация (шаг в эту сторону).

[Yuri__M]

Ну да, скорость страдает. Я подобную "луковично-чесночную" схему использовал, когда 10 лет назад интереса ради делал шифрованный-анонимный аналог email, а не мессенжер - в архивах моего гитхаба код лежит, "paranoid mail". Может, когда-нибудь руки таки дойдут переписать сие безобразие на qt/c++ и добавить постквантовый обмен ключами в дополнение к обычному ecdh.

[Svortex]

Согласен, в идеальном мире — P2P mesh (типа Yggdrasil/CJDNS) и никакого центрального сервера. Но три практические проблемы:

1. Оффлайн-доставка — получатель спит, кто хранит сообщение? Нужен store-and-forward узел, а это по сути сервер (Session/Lokinet так и делает через Service Nodes)

2. Мобильники — NAT, sleep через 30 сек, push только через FCM/APNs = третья сторона всё равно

3. Группы — 200 человек через mesh = O(n²) соединений или relay-узел

В roadmap'е есть федеративный протокол — шаг в эту сторону. Полный P2P — следующий, но с честным компромиссом: «сообщение доставится, когда получатель онлайн».

Как бы вы решали оффлайн-доставку без доверенных узлов?

[MrExpen]

Как-то не очень получилось. Учитывая что у нас по любому есть табличка со всеми пользователями откуда можно взять их id. А sender_tag генерируется по алгоритму HMAC-SHA256(pair_hash, sender_id)[0:16]

То мы можем по pair_hash подбирать все sender_id пока вычисленный хэш не совпадает. Так можно проделать с обоими и раскрыть кто же скрывается за парами.

[Svortex]

Всё верно, и это описано в статье — ограничения 12.1 и 12.2. Если атакующий получил полный дамп БД (включая global_salt из admin_settings), он перебирает C(n,2) пар и раскрывает весь граф. При 1000 пользователях — ~500k попыток, на современном железе это секунды.

Pair_hash защищает не от этого сценария. Он защищает от ситуации, когда утекла часть данных — бэкап anonymous_messages без admin_settings, лог-файлы, реплика read-only. Или когда доступ к БД есть, а к таблице с солью — нет (разные схемы/роли в PostgreSQL).

Правильное решение — вынести соль в HSM (HashiCorp Vault, AWS KMS) так, чтобы компрометация PostgreSQL не давала ключ для раскрутки хешей. Это в планах, но честно — пока не реализовано.

Спасибо, что проверяете — именно для этого код открыт.