Если вы хотя бы раз задумывались о приватности переписки, а использование популярных мессенджеров (Telegram, WhatsApp, Signal, TeleGuard и др) вызывает вопросы, - этот материал для вас. 

Компании зачастую собирают слишком много информации, а после взломов/сливов/иных причин она оказывается в руках мошенников, снижая уровень личной безопасности. Из–за этого, например, вы часто можете получать назойливые звонки на свой телефон или спам на почту. Да, в этом виноваты сервисы, которые собирают всю возможную о вас информацию, и ненадежно ее защищают. 

Сегодня рассказываем про анонимный мессенджер SimpleX, который написан на Haskell и позволяет, в том числе, использовать сеть Tor для общения.  

Что такое SimpleX 

​​SimpleX – не только один из немногих мессенджеров, который не собирает данные пользователей, но и единственный на сегодняшний день мессенджер, который не использует идентификаторы для профилей пользователей, даже случайные числа. Также он полностью open source, и каждый может принять участие в его разработке.

Как он работает

Для доставки сообщений вместо идентификаторов пользователей SimpleX имеет идентификаторы очередей сообщений, отдельные для каждого из контактов. В текущей версии приложения каждая очередь используется до тех пор, пока контакт не будет удален или пока адрес получения сообщений не будет изменен пользователем вручную. Позже команда проекта планирует автоматизировать этот процесс, а также добавить ротацию очередей в клиентский протокол, чтобы даже разговоры не имели долгосрочных идентификаторов, видимых в сети. Такая конструкция предотвращает утечку метаданных пользователей на уровне приложения.

Вы, как пользователь мессенджера, можете самостоятельно определить, какой сервер(ы) использовать для получения сообщений, а ваши контакты – серверы, которые вы используете для отправки им сообщений. Это означает, что в каждом разговоре, будут использоваться два разных сервера – по одному для каждого направления сообщений.

Только клиентские устройства хранят профили пользователей, контакты, группы и сообщения, отправленные с двухуровневым сквозным шифрованием.

Итак, разработчики SimpleX создали свой протокол для передачи сообщений: 

  • SimpleX Messaging Protocol (SMP) – это протокол для отправки сообщений в одном направлении получателю, используя промежуточный сервер. Сообщения доставляются через однонаправленные очереди, создаваемые получателями.

  • SMP работает через транспортный протокол, который обеспечивает целостность, аутентификацию сервера, конфиденциальность и привязку транспортного канала.

  • Сервер SimpleX – это один из таких серверов.

  • Сеть SimpleX – это термин, используемый для обозначения группы серверов SimpleX, которые способствуют работе SMP.

  • Библиотеки SimpleX Client говорят на языке SMP с SimpleX Servers и предоставляют низкоуровневый API, не предназначенный для использования приложениями.

Таблица сравнений с другими протоколами передачи информации
Таблица сравнений с другими протоколами передачи информации

С помощью функции Netzwerk & Server SimpleX можно настроить мессенджер таким образом, чтобы все коммуникации направлялись через сеть Tor. В сочетании с отсутствующим (уникальным) идентификатором и протоколом Simplex Messaging Protocol (SMP) возможно анонимное использование, что затрудняет или делает невозможным определить, кто с кем контактирует по метаданным. И еще: в отличие от Briar, например, контакт или устройство не обязательно должны быть постоянно онлайн, чтобы иметь возможность получить сообщение. Они временно хранятся на серверах ретрансляции SimpleX до тех пор, пока не будут получены. 

Как работает сеть SimpleX

Сеть SimpleX по своей структуре напоминает P2P–сети, но в отличие от большинства P2P–сетей она состоит из клиентов и серверов, не зависящих от какого–либо централизованного компонента. По сравнению с более традиционными приложениями для обмена сообщениями (например, WhatsApp, Signal, Telegram) ключевыми отличиями сети SimpleX являются:

  • Участникам не нужно иметь глобально уникальные адреса для общения, вместо этого они используют избыточные однонаправленные (симплексные) очереди обмена сообщениями, с отдельным набором очередей для каждого контакта.

  • Запросы на соединение передаются вне сети, не обязательно защищая обмен ключами от атаки MITM (человек посередине).

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

  • Серверы не хранят никакой пользовательской информации (ни профилей пользователей, ни контактов, ни сообщений после их доставки), и в основном используют персистентность в памяти.

  • Пользователи могут менять серверы с минимальными перебоями – даже после исчезновения используемого сервера, просто изменив конфигурацию, на каких серверах создаются новые очереди.

Особенности SimpleX

  • Сквозное шифрование в каждой очереди сообщений с использованием NaCl cryptobox. Это добавлено для обеспечения избыточности в будущем (прохождение каждого сообщения через несколько серверов), чтобы избежать наличия одного и того же шифротекста в разных очередях (который будет виден злоумышленнику только в случае компрометации TLS). Ключи шифрования, используемые для этого шифрования, не вращаются, вместо этого мы планируем вращать очереди. Для согласования ключей используются ключи Curve25519.

  • Начиная с версии 2 протокола SMP (текущая версия – v4) все метаданные сообщения, включая время получения сообщения сервером (с округлением до секунды), отправляются получателям в зашифрованном виде

  •  Для соединений клиент–сервер разрешены только TLS 1.2/1.3, ограниченные криптографические алгоритмы: CHACHA20POLY1305_SHA256, Ed25519/Ed448, Curve25519/Curve448.

  • Для защиты от атак повторного воспроизведения серверы SimpleX требуют привязки канала tlsunique в качестве идентификатора сессии в каждой клиентской команде, подписанной эфемерным ключом per–queue.

  • Для защиты вашего IP–адреса все клиенты SimpleX Chat поддерживают доступ к серверам обмена сообщениями через Tor.

  • Шифрование локальной базы данных с помощью парольной фразы – ваши контакты, группы и все отправленные и полученные сообщения хранятся в зашифрованном виде. Если вы использовали SimpleX Chat до версии 4.0, вам необходимо включить шифрование в настройках приложения.

О безопасности 

У проекта растет число энтузиастов, использующих SimpleX Chat, а пользователи, которым наиболеее важен вопрос своей безопасности, терпеливо ждали, пока некоторые независимые эксперты проверят кодовую базу проекта.

Поэтому команда разработчиков обратилась к Trail of Bits для проведения аудита. В центре внимания аудита ответы на вопросы:

  • Является ли реализация уязвимой для известных криптографических атак?

  • Хранится ли и обрабатывается ли ключевой материал таким образом, чтобы его раскрывали как можно меньше?

  • Соответствуют ли кодовые базы лучшим практикам программирования на Haskell?

Были выявлены две проблемы средней и две низкой степени серьезности, все из которых требуют высокой сложности для атаки при использовании – злоумышленник должен иметь привилегированный доступ к системе, знать сложные технические детали или должен обнаружить другие слабые места для их эксплуатации. Три из четырех проблем уже исправлены в версии 4.2.

В ходе аудита компания Trail of Bits оценила зрелость библиотеки simplexmq по восьми категориям и признала пять из них сильными или удовлетворительными. Большинство выявленных благодаря аудиту проблем исправлены или в процессе решения. Полный обзор безопасности доступен в публикации Trail of Bits.

Подводим итоги

SimpleX Chat - молодой продукт на площадке мессенджеров, но он уже успел превзойти альтернативные продукты, которые называют себя приватными и анонимными. 

Данное решение не даст посторонним лицам анализировать ваши сообщения или манипулировать аккаунтами. Вы сможете быть уверены в том, что ваша переписка в безопасности. SimpleX уделяет большое внимание конфиденциальности, о чем ясно свидетельствует раздел «Конфиденциальность: технические детали и ограничения». Разработчики нацелены на развитие и масштабирование проекта, и у них еще остался достаточно большой Roadmap, которые они хотят реализовать. 

Из самых свежих обновлений на момент публикации статьи – выпущена версия 4.3 — с мгновенными голосовыми сообщениями, необратимым удалением отправленных сообщений и улучшенной конфигурацией сервера.

За успехами проекта вы можете следить в блоге на сайте и в аккаунте reddit

SimpleX можно получить в App Store, Google Play, прямо со страницы проекта GitHub или в main f-droid repo

Комментарии (48)


  1. atrost
    20.12.2022 16:42
    +5

    Здесь неправильное сравнение (конечно в угоду этому проекту), если и сравнивать его, то не с telegram надо, а с briar.


    1. dafna_with Автор
      20.12.2022 16:43

      про это в статье есть ниже


      1. atrost
        20.12.2022 17:56
        +7

        Это не сравнение, а утверждение что briar должен быть онлайн для получения сообщения. Но несказанно может ли SimpleX работать без сети интернет (в одноранговой сети, какую может строить briar), что важно в условиях нарушения работы сотовой сети.


  1. dmitrybelsky
    20.12.2022 16:49

    threema уже давно есть вроде?


    1. entze
      21.12.2022 17:05

      Есть. В реестре.
      https://roscenzura.com/threads/2527/


  1. titbit
    20.12.2022 17:57
    +13

    Что-то очень много непонятных решений для "безопасного" общения.

    Заменили идентификаторы на избыточные очереди, а в чем смысл? Это также идентифицирует пользователя такой сети, просто усложняя метод идентификации (впрочем в своей статье авторы сами в этом признаются). Только вот искать контактов в таком случае станет сложнее обычным пользователям. Про проблемы мультикаста (сообщение многим адресатам) тоже умолчу.

    Про защиту от MITM - ничего не понял. "Запросы на соединение передаются вне сети" - так если так поступать в других системах это тоже защитит их от этой атаки. Но как это сделано тут? Борьба с MITM это довольно хитрая штука и здесь я не увидел описания защиты.

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

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

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


    1. makkarpov
      20.12.2022 18:11

      Добавлю еще одно - как предполагается защищать эти сервера (которые, судя по всему, должны хостить добровольцы) от злонамеренного использования? Например, чтобы заботливые авторы ботнетов не использовали их как прекрасный децентрализованный командный центр?


      1. xenon
        20.12.2022 18:26
        +8

        А зачем? Можно же координировать ботнет хоть даже через хабр. (Коммент "А зачем*" в сегодняшнем посте дает команду делать X, а коммент "добавлю еще одно*" - команда делать Y. Лишь бы это не убивало, не перегружало саму сеть.

        Иначе и в календаре надо делать защиту, вдруг жена там внесет запись "14:00 подсыпать мужу цианистый калий в обед".



    1. vvzvlad
      21.12.2022 03:16

      «разрешены только TLS 1.2/1.3, ограниченные криптографические алгоритмы» — сомнительное техническое решение, не способствует доверию участников общения. Как обновлять схему при нахождении проблем в текущей (а они обязательно будут)?

      Т.е. разрешить устаревшие протоколы лучше? Будет как с https


      1. domix32
        21.12.2022 12:03
        +1

        Вопрос был как апгрейдиться, когда в текущих версиях найдут какие-то косяки с безопасностью, а не как даунгредиться.


        1. vvzvlad
          21.12.2022 16:49

          В смысле? Ну появится новая версия, добавят в список разрешенных.


    1. epoberezkin
      21.12.2022 20:33
      +1

      Это также идентифицирует пользователя такой сети

      Идентификаторы очереди никак не связаны с каким то пользователем на уровне приложения, только на уровне сессии / транспорта, что отдельно решается.

      "Запросы на соединение передаются вне сети" - так если так поступать в других системах это тоже защитит их от этой атаки. Но как это сделано тут?

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

      Как обновлять схему при нахождении проблем в текущей (а они обязательно будут)?

      В протоколе есть согласование версии, просто добавится поддержка новой версии.

      "Серверы не хранят никакой пользовательской информации" - а что мешает им хранить? 

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

      как я узнаю о появлении нового сервера?

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

      Или как новый сервер узнает о появлении меня с моими очередями?

      никак, на новом сервере будет просто создана новая очередь, и сообщения тому же контакту будут через нее передаваться, переключение прозрачно для пользователя.


      1. titbit
        22.12.2022 10:10

        Идентификаторы очереди никак не связаны с каким то пользователем

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

        Ссылка с адресом соединения и публичными ключами передается вне сети

        Вопрос и был в том как это сделать прозрачно для пользователя? В сравнительной табличке было написано что система противостоит MITM, но передача ключей по стороннему каналу сделает любую систему защищенной от MITM. Тут я не увидел никаких объяснений на этот счет, почему это именно эта система лучше всех остальных.

        у них ни в какой момент времени нет никакой пользовательской информации вообще кроме адресов очередей, анонимных ключей

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

        так же, как вы узнаете о существовании нового email провайдера например

        Это же жутко неудобно и непрозрачно для пользователя. Я что должен следить за серверами при общении? Или где-то есть централизованный список всех доступных серверов (здравствуй полная централизация этой сети)?

        на новом сервере будет просто создана новая очередь, и сообщения тому же контакту будут через нее передаваться

        Можете описать что будет если во время сеанса между А и Б рухнет их общий сервер? "А" полезет выбирать свой другой, "Б" свой другой, как они согласовывать это будут если прямой связи между А и Б больше нет по определению?


  1. shasoftX
    20.12.2022 17:57
    +5

    Поподробнее бы описание процесса обмена сообщениями.

    Не очень понятно, как пользователи находят друг друга для общения если нет никакого ID профиля.

    Т.е. вот я хочу общаться с Васей Петровым. Оба мы подключились. Но как будет выглядеть процесс поиска куда отправлять сообщения вида "отправить Васе Петрову"?


    1. M_AJ
      20.12.2022 18:47

      Насколько я понимаю, для этого вам и Васе нужно встретиться, и добавить друг друга.


      1. shasoftX
        20.12.2022 18:50
        +6

        Вот и непонятно, что именно и как нужно добавить. Т.е. вот у нас установлена эта программа. Мы с вами встретились. По блютуз соединились и "что именно будет добавлено вам и мне"? Какая уникальная информация, которая позволит сообщениям приходить от вас ко мне. Это как-то не понятно. Ведь если это уникально, то это уже подобие ID профиля получается. А если нет - то не ясно как сообщения будут ходить.


        1. smx_ha
          20.12.2022 19:33

          >Какая уникальная информация, которая позволит сообщениям приходить от вас ко мне. 

          id очереди сообщений я так понимаю. В принципе для чатов на несколько человек могло бы и сработать, если действительно нельзя определить по сообщению кто его написал.


          1. shasoftX
            20.12.2022 20:44

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

            Собственно было бы интересно если бы перевели именно протокол работы мессенджера, чтобы было понятно как же именно оно работает. Вместо рекламного текста вида "он работает не так как другие и никто вас не идентифицирует"


            1. Aelliari
              20.12.2022 20:53

              Гипотетическая схема с потолка:

              1. Первоначальный обмен ID

              2. Генерация ключей, согласование сессии закрытой e2e шифрованием

              3. Обмен сообщениями

              4. Устройства генерируют новый ID и проводят регистрацию на сервере, сервер понятия не имеет что это теже самые устройства

              5. Внутри согласованного канала в п.2 происходит ротация ID, серверу этот обмен недоступен ибо зашифровано

              6. Продолжение общения по новым ID, для сервера неотличимо от новой сессии пункта 1, с абсолютно новых устройств. Для клиента - разрыва нити беседы нет


              1. shasoftX
                20.12.2022 21:07

                Пусть мы обменялись с вами этими ID. Мой ID Я, ваш ID ВЫ

                Я отправляю сообщение для ID ВЫ. Что мешает кому то в сети сказать что ОН, это ВЫ? Никто. Т.е. я отправил сообщение вам, а оно ушло кому-то другому. А значит чтобы быть уверенным что сообщение прочитаете только ВЫ, я должен шифровать сообщение. А значит у меня есть ключ. Который и будет ID профиля в данном случае.


                1. Aelliari
                  20.12.2022 21:20

                  И где вот тут вот противоречие написанному мной? И вот этот ID можно поменять

                  Но чтобы сообщения доходили то получается, что нужно либо заново встретится и по блютуз обменяться новыми идентификаторами

                  Суть в том, что не надо встречаться лично для ротации ID/ключей, и это логично. Но это не отменяет необходимости в изначальном установлении доверия, самом первом

                  либо сервер должен сам знать какой был, а какой стал

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


              1. shasoftX
                20.12.2022 21:16

                MITM сразу на пункте 1.

                Мы с вами обмениваемся ID, но посередине находится "третий лишний". Который вам говорит, что это я. А мне, что это вы. Мы генерируем ключи и начинаем общение, но этот третий читает все наши сообщения.

                Как вариант, этот третий - это сервер, через который мы общаемся. Он просто представляется каждому из нас как собеседник и записывает нашу беседу.


                1. Aelliari
                  20.12.2022 21:28

                  MITM сразу на пункте 1.

                  Вернемся к обсуждаемой статье о мессенджере

                  Запросы на соединение передаются вне сети, не обязательно защищая обмен ключами от атаки MITM (человек посередине).

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

                  P.S. опять же, если вернутся к данной статье, автоматическая ротация ID на уровне сети ещё только в планах

                  P.P.S в целом, на уровне данной статьи выглядит достаточно интересно, с учетом e2e (если оно там нормальное), и когда прикрутят ротацию идентификаторов. Но все же проблему доверия к собеседнику оно не решает и скорее всего не взлетит. Telegram/WhatsApp/Signal решают её по средствам "арбитра" в виде сервера, проверяющего номер телефона и имеют низкий порог вхождения. Но претензии к ним, а они есть, я сейчас обсуждать не намерен


                  1. epoberezkin
                    21.12.2022 20:53
                    +1

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


                1. epoberezkin
                  21.12.2022 20:51
                  +1

                  да, такая атака возможна, но это очень сложная атака если например вы показываете qr code в видео звонке. Следующая версия (сегодня/завтра будет бета) добавит возможность проверить security code через другой канал.


            1. smx_ha
              20.12.2022 21:03

              Ну это не id профиля, это как ссылка на веб страницу где любой может что то написать без всякой авторизации. Если ссылка достаточно уникальна и обьяснить ее наличие на телефоне можно как: "я просто смотрел но не писал" то вполне себе интересное решение


            1. epoberezkin
              21.12.2022 20:43
              +1

              Т.е. фактически ID профиля есть. Просто он иногда меняется.

              Нет, у профилей нет никаких идентификаторов, идентификатор есть у Вашего соединения с одним контактом только (pairwise identifier), и он иногда меняется. Наличие ID профиля позволило бы двум контактам установить что они общаются с одним и тем же пользователем, в данном случае это невозможно, потому что два разных контакта не видят никаках общих данных кроме display name (которое во-первых low entropy и не уникальное, то есть его совпадение не доказывает что это тот же самый пользователь, во-вторых можно каждому контакту слать случайное display name - для этого есть incognito mode).

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

              нет, это не так работает. Для переноса коммуникаций с тем же контактом на другой сервер клиент передает адрес новой очереди через зашифрованный канал, прозрачно для пользователей, не надо заново встречаться, это просто часть протокола. При этом старый сервер не знает куда перешли коммуникации, он только видит что очередь удалена, а новый сервер не видит откуда они пришли - для него это просто новое соединение.

              он работает не так как другие 

              это корректное утверждение, SimpleX протокол отличается от всех остальных тем что вместо profile identifiers & user credentials используются temporary pairwise connection identifiers / anonymous credentials. Если вы представите себе ваши коммуникации как граф, где узлы это пользователи, то во всех сетях часть или весь граф пользователя доступен для наблюдения оператором или другим пользователям, в данном случае узлы сети недоступны серверам, серверы только предосталяют односторонние соединения. На сайте (https://simplex.chat) в разделе SimpleX Explained есть картинка которая это объясняет.


        1. KabirK
          21.12.2022 19:51

          я в приложении на своём телефоне нажимаю кнопку «сгенерить QR-код», вы на своём нажимаете «считать QR-код». (как в Briar, собственно.)


          1. epoberezkin
            21.12.2022 20:46
            +1

            разница в том что в Briar этот QR code является идентификатором профиля пользователя - он один и тот же для разных пользователей, в SimpleX этот qr code одноразовый (многоразовый тоже можно сделать) и два разных кода не содержать никакой общей информации (кроме адреса relay где создана очередь для сообщений).


            1. KabirK
              21.12.2022 21:00

              это верно, однако, насколько я понял, не это интересовало shasoftX, который спросил, как пользователи находят друг друга для общения .

              — Не очень понятно, как пользователи находят друг друга для общения если нет никакого ID профиля. Т.е. вот я хочу общаться с Васей Петровым. Оба мы подключились. Но как будет выглядеть процесс поиска куда отправлять сообщения вида "отправить Васе Петрову"?

              — Насколько я понимаю, для этого вам и Васе нужно встретиться, и добавить друг друга.

              — Вот и непонятно, что именно и как нужно добавить. Т.е. вот у нас установлена эта программа. Мы с вами встретились. …и "что именно будет добавлено вам и мне"?

              я этот вопрос истолковал в практической плоскости: что нужно делать. (судя по его более поздним репликам, я ошибся. ну ок.)


              1. epoberezkin
                21.12.2022 21:02
                +1

                да может и я запутался :)


      1. epoberezkin
        21.12.2022 20:55
        +1

        первоначальное приглашение может быть передано через открытый канал, при условии что он не подменяет информацию - там только публичные ключи и одноразовый адрес – это работает похожим образом на PANDA когда только один пользователь может получить доступ к ресурсу.



    1. domix32
      21.12.2022 12:08

      На гитхабе есть гифка с консолями:

      Клиент 1 запускает клиент. Предтсавляется Алисой. Жмет коннект и получает ключ от какой-то очереди на каком-то сервере. Каким-то чудесным образом этот ключ доставляется Клиенту 2.

      Клиент 2 запускает клиент. Представляется Бобом. Жмёт коннект, куда вставляет магическим образом полученный ключ и попадает в ту же самую какую-то очередь на каком-то сервере.


      1. Wesha
        21.12.2022 12:29
        +1

        Каким-то чудесным образом этот ключ доставляется Клиенту 2.

        Не "чудесным образом", а "передаётся каким-то образом в реальном мире". Например, записанным на бумажке. Но показать это средствами гитхаба было сложно.


        1. domix32
          21.12.2022 14:43

          То бишь полезность такой анонимности снижается до некоторого района проживания. В противном случае ключ-приглашение оказывается доступен и свинье. Интесный вопрос ещё насколько такие ключи устойчивы к перебору: запускаешь бота, который генерит какие-нибудь случайные ключи по типу AFL и пытается приконнектиться к ним.


          1. epoberezkin
            21.12.2022 20:49
            +1

            это не совсем так - этот ключ не должен быть защищен от пассивной атаке - его можно передать через любой канал связи, при двух условиях - 1) вы доверяете что канал не подменяет информацию (что достаточно сложно сделать например при видео звонке) 2) вы можете установить личность получателя/отправителя

            то есть можно установить соединение с кем угодно где угодно.

            даже в случае если пункт 1 не выполняется, то с версии 4.4 можно проверить security code через какой то независимый от первого канал - если он совпадает, это доказывает что канал не был перехвачен, то есть это добавляет второй фактор.


          1. Wesha
            22.12.2022 01:01

            В противном случае ключ-приглашение оказывается доступен и свинье.

            Всё гораздо проще. Достаточно ввести фактор времени.

            Отправляю емейл Васе: "Запомни часть A: 23132123234234823"

            Отправляю SMS Васе: "Запомни часть B: 321231687217236"

            В телеграме пишу Васе: "Запомни часть C: 67897646113183354"

            По телефону звоню Васе: — Твой ключ: часть C до цифр 83 включительно + часть A от цифр 231 включительно + часть B до цифр 72 включительно.

            Вася собирает части вместе (а они у него уже на экране), и за 15 секунд соединяется со мной в симплекс-часте. Я ему туда говорю: "новый ключ - 98134423453425322451234554324654234523, а все те три части выкинь".

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


            1. domix32
              22.12.2022 01:22

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


              1. Wesha
                22.12.2022 02:02

                Помножить Васю на 10 и рутина становится довольно громоздкой

                У Вас так много друзей, с которыми Вы обсуждаете такие вещи, которые хорошо бы не показывать тащу майору? И они так часто меняются?

                (Любые наставления, кстати, во первых строках учат, что в ячейке должно быть не более трёх человек.)


                1. domix32
                  22.12.2022 10:00

                  То есть мессенджер изначально позиционируется как инструмент для нелегальных вещей, получается, а не как baseline messenger?


                  1. Wesha
                    22.12.2022 22:07

                    Ложная дихотомия. Мессенджер изначально позиционируется как "настолько защищённый, что по нему можно даже на нелегальные темы общаться".

                    Иными словами, если у Вас в спальне шторы задёрнуты — то это ни в коей мере не значит, что Вы там внутри варите наркотики, а не жарите жену.


                    1. domix32
                      22.12.2022 22:32

                      Telegram, WhatsApp, Signal, TeleGuard и др

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


                      1. Wesha
                        23.12.2022 02:45

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

                        Шторы. В спальне.

                        "Среднечеловеку" повесить шторы в спальне тоже не особо просто — это ж дрель покупать надо, дюбели, карнизы...


  1. atrost
    20.12.2022 18:03
    +12

    В идеале я вижу проект аппаратно-програмный, уровня Meshtastic. Где помимо месседжера на когда все хорошо и есть интернет, есть режим работы с ble устройством на когда все плохо. Лучше чтобы LoRa модемы были встроенны в смартфоны, как экстренный канал связи.


  1. epoberezkin
    21.12.2022 20:25
    +2

    Большое спасибо за статью - пользователь только что прислал ссылку! Сейчас отвечу на вопросы/комментарии!


    1. Aelliari
      21.12.2022 22:55

      Я правильно понимаю, вы автор данного проекта?