Концепция идеального мессенджера


    Привет, %username%!
    Этот пост стоило написать года три назад, когда появилась идея опенсорсного защищенного P2P мессенджера. Но я все это время надеялся, что хватит сил запилить проект в одного. К сожалению, время шло, а проект так и не ожил. Единственное, что я успел сделать — разработать детальную концепцию, подобие протокола и накодить всяких криптоштук, которые пригодились бы при написании этого мессенджера. А теперь, когда на сцене есть bitmessage, очень похожий на мою идею BitTorrent Chat и ненавистный всем Telegram, вижу, что поезд ушел и я при всем желании на него не успею.
    Поэтому вашему вниманию предлагается концепция защищенного, анонимного P2P мессенджера с околонулевым порогом вхождения. Я ему даже название придумал:

    Итак, это пост о том, каким бы мог стать ParanoIM, если бы я довел его до ума.

    Судя по тому, что выложили о своем проекте товарищи их BitTorrent Chat, некоторые моменты у меня с ними очень похожи. С них и начнем.

    1. DHT


    Без этой штуки никуда. Если вы не в курсе, что это такое, Kademlia для вас — это пустой звук, то стоит почитать об этом в соответствующих статьях. Здесь я лишь расскажу кто является нодами и что лежит в самой таблице.

    Нода

    Физический узел. Каждая нода при запуске генерирует новую ключевую пару ECC, её идентификатором будет являться хэш открытого ключа. При обмене информацией с другими нодами происходит обмен открытыми ключами, таким образом появляется возможность установить защищенное соединение между нодами. Конечно, тут возможна атака MITM, но нам это не сильно страшно, потому что ноды сами по себе не обмениваются какой либо ценной незашифрованной информацией друг с другом во время построения сети.

    Абонент

    Или просто пользователь мессенджера. Человек, который генерирует себе перманентную ключевую пару ECC, хэш от публичного ключа которой будет его уникальным постоянным адресом. Этот хэш он всем раздает, публикует и всячески распространяет. Конечно, не очень удобно диктовать бабуле 512битный хэш, но тут ничего не поделать. Есть способ обойти это неудобство, но об этом позже.

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

    1. Выбирает еще несколько proxy нод (или не выбирает), которые будут отдавать команды этим нодам
    2. Каждой из выбранных нод сам или через прокси ноды посылает команду «Принимай сообщение для Id такого то и передавай ноде такой то»


    Логично, что последней нодой «такой то» будет нода самого абонента, но остальные об этом знать не будут. Всё, что известно остальным нодам — это то, что зашифрованное сообщение для абонента X надо передать ноде Y. А уж чего она с ним там дальше будет делать, это нам не ведомо. Может дальше передаст, а может сама расшифрует.

    После того, как все выбранные ноды ответили согласием, абонент публикует в DHT (так же, через цепочку прокси нод, или напрямую) подписанную своим закрытым ключом пару «Id абонента — Id ноды, принимающей для него сообщения». Принимающих нод может быть несколько, для большей отказоустойчивости.

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

    Когда сообщение попадает к ноде абонента, он его никуда не пересылает, а расшифровывает и собсно читает. (похоже на i2p)

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

    Как видите, тут исключена возможность MITM между абонентами, т.к. они изначально знают именно открытые ключи друг друга, а не какие то другие идентификаторы. Всё, что может сделать атакующий — попытаться раскрыть анонимность, но при большом количестве нод ему будет это очень сложно сделать.

    2. Offline сообщения


    Тут всё просто, их можно хранить в BitMessage-подобном хранилище, оно идеально для этого подойдет.

    3. А где же нулевой порог вхождения?


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

    Моей идеей было сделать jabber сервер, к которому локально цеплялся бы абонент любым jabber клиентом, к которому он привык, и который сам был бы клиентом для сети ParanoIM. Генерацию ключевых пар\адресов можно было бы сделать в простом web интерфайсе, который бы запускался локально.

    4. Что с длинными адресами?


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

    Так вот, можно было бы продавать обычные человекочитаемые имена/уины, привязывая их к хэшам публичных ключей абонентов. А потом списки этих пар подписывать закрытым ключом и рассылать всем нодам апдейтом. Что, конечно, не мешало бы обращаться к этим абонентам по их обычному хэшу.

    Но, можно было бы обойтись и более цивильной вещью вроде NameCoin. Тогда бы вообще отпала необходимость в какой либо централизации.

    Вот собсно и всё, таким я хотел бы видеть свой утопичный IM, и надеюсь, BitTorrent Chat будет очень на него похож.
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 17

      +3
      можно было бы продавать обычные человекочитаемые имена/уины, привязывая их к хэшам публичных ключей абонентов.

      На этом — паранойа_mode_off. Защищенность мессенджера не только в криптографии, но и в анонимности пользователей. Ваша система просто предлагает пользователям заявить во весь голос: «Я, Иванов Иван Иванович, шифрую свою переписку и мне есть что скрывать». Как только мессенджер с подобной системой обретает популярность, к разработчикам (а они ведь известны, да?) приходит официальная бумага (или человек с официальной бумагой) от соответствующих органов с требованием передать данные о пользователях (они ведь тоже известны, т.к. оплачивали UIN) этим самым органам, плюс передать все данные по системе шифрования, сделать дыру в следующем обновлении и многое другое, сводящее на нет всю защищенность мессенджера. Естественно, все под предлогом борьбы с терроризмом и СР.
        0
        1) Попросить сделать дыру могут и без иван иванычей, тут повода особого не надо. На то он и опен сорц
        2) Наличие короткого имени влияет лишь на возможность быстро найти этого юзера. Оплату принимать можно биткоинами и ничья анонимность не нарушится. С таким же успехом товарищи фсбшники могут прийти и попросить дать все данные по хэшу такому-то (хэши то никто не прячет).
          0
          1. И попросят. Только, если Вы зарабатываете на этом продукте, то вынуждены будете выполнить «просьбу». Или сделают так, что Вы перестанете на своем продукте зарабатывать. Это совсем не проблема. В лучшем случает. В худшем случае, Вы получите еще и кучу неприятностей за отказ от «выполнения законных требований». Если Вы не зарабатываете на приложении, то рычагов давления на Вас гораздо меньше. Фактически, количество законных рычагов становится не сильно отличающимся от нуля.
          2. Биткоин еще не настолько популярен, как платежное средство, чтобы делать ставку только на него. Во всех остальных случаях Вы получаете личные данные тех, кто перевел Вам деньги. Как государство может использовать эти данные? Например, Вы предоставили список людей, которые заплатили Вам за красивый юин. Органы тут же ставят трафик этих людей под усиленный контроль. А в некоторых особо параноидальных странах — возможно, не только трафик. Кому из целевой аудитории Вашего мессенджера такое надо?
            0
            Биткоины не признаны у нас как деньги, так что я в терминах законе ничего не зарабатываю. А по другому я это делать не планировал. К тому же, это планировалось как приятный бонус к разработке, а не основной источник дохода.

            А если фсбшники решат следить за трафиком какого то конкретного человека, то тут короткие имена ни причем. Хэш можно выдернуть и из форума\личной страницы и так же забить его в фильтры.
        0
        А в чем его идеальность?
          0
          Нет серверов, коммуникации защищены и анонимны, опен сорс, чего еще желать?
            0
            А трояны в операционках, кейлоггеры, бэкдоры в алгоритмах и операционках?
            Тут за последние полгода уж слишком много сообщений про то, как куда угодно вставляют бэкдоры, даже в микросхемные генераторы псевдослучайных чисел.
              0
              вам мессенджер с антивирусом нужен? я не понял наезда
                0
                Слово «идеальный» смущает. К остальному претензий нет.
                  0
                  Следуя вашей логике, идеальный это если дубиной бьет по голове подсматривающему.
                    0
                    Идеальный, это когда подсматривающий рвет на себе волосы и кусает локти от бессилья, а не выбирает, по какому из бэкдоров получать данные с троянов.
                0
                Тогда остается только делать полностью открытое аппаратное решение на очень простом процессоре общего назначения с ПЛИС собственного производства. Только кто на это пойдет?
                  0
                  Так и надо делать. Все своё. Никаких произведений третьих лиц. Кто на это пойдет — это уже второй вопрос. Для серьезной переписки нужны серьезные решения.
            0
            Мне нравилась идея, по которой сообщение шифруется открытым ключом получателя, а затем поступает в p2p-сеть и копируется на все компьютеры сети. Естественно, расшифровать его может только получатель. Таким образом, узнать, кому поступило сообщение становится принципиально невозможно: все сообщения получают все пользователи. Своего рода аналог alt.anonymous.messages юзнета. Но, наверное, трафик будет слишком большим для мобильных (да и не только) клиентов.
              0
              Пардон, BitMessage так и работает:

              "… Система рассылает все сообщения на компьютеры всех других доступных участников сети, тем самым перемешивая зашифрованные исходящие сообщения данного пользователя с зашифрованными исходящими сообщениями всех других пользователей сети..."
                0
                Т.е. отправил товарищу файл с фильмом и положил всю сеть?
                0
                трафик будет слишком большим

                1. Можно синхронизировать только базу метаданных, включающую ID сообщения и 2-байтный хеш от (ID получателя + ID сообщения), зашифрованный публичным ключом получателя. Базу разделить по дням, чтобы не хранить слишком долгую историю. Тогда получатель попробует расшифровать хеш и сравнить со своим ID. Если совпадает — скачать сообщение (и ещё 100-500 чужих, чтобы не выдавать, какое сообщение его заинтересовало). Такой подход усложнит взлом перебором. Ведь получатель знает, с чем сравнивать (свой ID), а атакующий должен будет сравнивать со всеми известными ID в сети, прохешенными с ID конкретного сообщения (т.е. эффективный словарь не получится сделать). Короткий хеш — 16 бит — даст много коллизий, и сообщение можно будет адресовать нескольким пользователям, но расшифровать его сможет только получатель.

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

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

              Самое читаемое