Схема интересная, опирается по большей части на безопасность самой криптографической хеш-функции, что хорошо. Но в этом подходе есть также и ряд подводных камней:
Хеш-функции в массе своей итеративны, вследствие этого, номер который дополняет ключ чисто теоретически может дополняться ещё "сверх того". Эта атака может быть применена когда совпадут одновременно два условия: 1) Хеш-функция успешно захешировала блоки в котором находится полный ключ, 2) Номер блока не дополняется до статичной длины. При таких условиях будет осуществима атака удлинения сообщения, где криптоаналитик сможет продолжить шифровать сообщение валидным ключом при этом его не зная. Вследствие этого, лучше использовать не хеш-функцию, а HMAC от этой хеш-функции,
Криптостойкость шифрованного блока ограничена числом N/2 (парадокс дней рождения), где N - длина выходного блока хеш-функции. Иными словами, через N/2 будет возможно взломать один из блоков с вероятностью >50%. Для SHA-256, SHA-512 это приемлемо, но для более малых хеш-функций (например MD5) - это уже будет уязвимостью. Вследствие этого, даже если энтропия ключа будет равна X, где X > N/2, то фактическая безопасность шифра останется всё также равной N/2,
Парольная фраза должна проходить всё же через KDF (например, scrypt, pbkdf2), а не через хеш-функцию. Это не повысит энтропию ключа, но повысит сложность полного перебора. Тем не менее, я бы в данной схеме вообще убрал данный блок, потому что это избыточно. Например, в спецификации AES нет пункта, который бы требовал пропускать ключ через KDF, т.к. предполагается, что ключ уже надёжный. Я бы просто в коде установил, что длина ключа должна быть равна N/2 от длины блока N. В таком случае, мы явно говорим, что безопасность нашего шифра равна N/2 с учётом атаки парадокса дней рождения,
В схеме не хватает дополнительной оказии для сеанса связи. Если шифрование повторится дважды с одним ключом, то это будет крайне плохим событием. Эта проблема уже опирается не на криптографическую хеш-функцию, а на поточную структуру вашего алгоритма. Данная проблема свойственна всем поточным шифрам и режимам шифрования формирующих поточность, как CTR, OFB. Для борьбы с этим либо создают случайный вектор инициализации для каждого шифрованного сообщения, либо уникальный номер для конкретного сеанса связи.
С этим согласен, малая группа всегда становится более уязвимой к репрессивному аппарату, чем большая. И в этом плане QB, EI, DC -сети проигрывают Onion, Proxy -сетям.
Тем не менее в такой концепции существует также ряд тонкостей. Например, анонимные сети с большими группами могут относительно легко делиться на малые подгруппы. Это достигается за счёт:
Конкретной маршрутизации, где из всего множества узлов удаляются непересекающиеся маршруты,
Частоты генерируемого трафика, где долгий период общения может уменьшать группу возможных участников,
Активных атак, где задержка связи или блокировка соединений может приводить к определению более конкретных связей между участниками.
Вследствие этого, большие группы со временем (после ряда проведённых наблюдений) могут делиться на малые подгруппы, каждая из которых уже будет анализироваться проще, чем малая группа такого же размера в QB, EI, DC -сетях.
Этого деления можно было бы избежать, если бы нашлась такая сеть с теоретически доказуемой анонимностью, которая бы при этом могла эффективно масштабироваться. К сожалению, пока такой сети открыто не было.
В сети Hidden Lake каждое сообщение подписывается закрытым ключом отправителя и далее шифруется открытым ключом получателя, с использованием гибридной схемы. В шифрованное сообщение вставляется публичный ключ отправителя, чтобы получатель успешно смог сразу проверить корректность полученной подписи. Более подробно на счёт данного протокола можно почитать здесь.
Если же речь про само доверие к публичному ключу, то здесь ситуация такая, что сеть HL предполагает F2F соединения, где каждый пользователь заранее выставляет свой список друзей (публичных ключей). Предполагается, что обмен ключами осуществляется либо лично, либо с использованием нескольких сервисов, как например описано тут.
Структура шифрованного сообщения, без её сокрытия и доказательства работы, выглядит следующим образом:
Чтобы успешно расшифровать сообщение - впервую очередь необходимо попытаться расшифровать сеансовый ключ (enck) своим приватным ключом. Если таковой успешно расшифровался, то можно будет расшифровать все остальные поля, а также сравнить хеш, подпись пакета.
Как понял, определение DH было взято из википедии. Тогда вот полное определение:
Протокол Ди́ффи — Хе́ллмана (англ.Diffie–Hellman key exchange protocol, DH) — криптографический протокол, позволяющий двум и более сторонам получить общий секретный ключ, используя незащищенный от прослушивания канал связи. Полученный ключ используется для шифрования дальнейшего обмена с помощью алгоритмов симметричного шифрования.
Нигде не сказано, что это протокол симметричного шифрования, это протокол распределения ключей. То, что его результаты используют уже в массе своей симметричные алгоритмы шифрования ничего не говорит о какой-либо симметричной сущности самого DH. Полученный секретный ключ может например использоваться в HMAC, что уже не есть симметричное шифрование.
По поводу архитектуры, как по мне, самое интересное. Да, ответственность за запрещёнку лежит на пользователях, однако, является ли это проблемой, если пользователя нельзя деанонимизировать?
Если нельзя - проблемы нет. Если льзя - проблема есть. В сети Tor, и в таком использовании, деанонимизировать можно.
В реальности же с ограничением пропускной способности узлов справляется естественная сетевая модель современного клирнета с кучей маршрутизаторов\ретрансляторов.
Вряд ли это так. Наблюдателю известны все маршруты в пределах собственных границ, известен и нормализованный уровень трафика, известен и аномальный уровень трафика. Наложение одного на другое уже может дать чёткие маршруты, даже без учёта анализа сети Tor по его специфичному виду протокола.
Если бы государство могло так легко взять и таргетированно (в сговоре с интернет-провайдером) отследить по тепловой карте трафика реальный адрес какого-нибуть сайта в Tor, думаете он бы продолжил свое существование?
Да, потому что Tor использует следующую модель угроз:
Анонимность сосредоточена на клиентской стороне больше, чем на серверной. Определить связь клиента с сервером сложнее, когда неподконтрольны клиент и сервер, нежели когда неподконтролен только сервер. Вероятность же инвертированной ситуации, когда сервер окажется подконтрольным, а клиент - нет, куда меньше, как минимум за счёт того, что сервер есть хранитель информации, профита с его деанонимизации можно получить куда больше,
В основе Tor заложен принцип федеративности, когда маршрутизирующие узлы располагаются на границах разных государств, а сам пакет множественно шифруется и внешне самоизменяется при переходе от одного узла к другому. Когда же происходит слежение за аномально большим трафиком на конечных точках, то от такой маршрутизации смысла становится ровно нуль, если сервер находится в пределах видимости внешнего наблюдателя, даже если сам пакет изменял свою форму в неподконтрольных государствах,
За счёт P2P архитектуры ситуация из второго пункта ухудшает ситуацию ещё больше. Существующие даркнет сайты, тобишь сервера в сети Tor продолжают существовать и функционировать лишь по той простой причине, что отправитель (клиент) и получатель (сервер) находятся в разных государствах. Сам сайт же деплоится в нескольких государствах. Вследствие этого: 1) массовые запросы начинают расщепляться по нескольким репликам, 2) выход из строя одного сервера не приводит к падению сайта. Когда отправитель и получатель находятся в пределах одного государства, тогда анонимизация в сети Tor начинает работать крайне плохо, даже с учётом всей запутывающей маршрутизации. У P2P сети, состоящей из рядовых пользователей, такой возможности как реплицировать себя на множество государств нет. А даже если будет, то всплывёт ещё масса других вопросов, как минимум на счёт консистентности хранимых данных и последующей анонимизации в новых условиях.
Вы справедливо заметите: так ведь Diffie Hellman — протокол симметричного шифрования, ключ-то в конце получился одинаковый!
Когда это DH стал протоколом симметричного шифрования?
Отсутствие алгоритма взлома ключа для квантовых вычислителей
Когда это EC криптография стала невзламываема для квантовых вычислений?
2. На правах непродуманной архитектуры
Каждый участник будет хранить у себя все файлы сети одновременно и самостоятельно просматривать их, индексировать, рендерить и т. д.
Сеть Tor есть крайне плохой выбор для такого рода хранилищ, когда пользователь подгружает всю базу данных / файлов себе на локальный компьютер или сервер. Если предположить, что вдруг, магическим образом, заспавнилась запрещёнка, то все начинают её подгружать себе. Ответственность за этот файл лежит теперь не на раздающем, а на хранящем.
Сеть Tor хорошо анонимизирует отправителей, но плохо анонимизирует получателей / сервера, собственно в этой архитектуре - всех P2P узлов. Банальный способ атаки будет сводиться к существованию двух атакующих: активного внутреннего и пассивного внешнего. Цель активного - просто генерация большого количества запросов на один из доменов. Цель пассивного - смотреть за аномально большим траффиком и вырисовывать получателей такого траффика. Если внешний наблюдатель - есть государство, то вся анонимность буквально будет рушиться на глазах, а все причастные с подгруженной запрещёнкой будут в сию минуту в местах не столь отдалённых.
Что I2P, что Hidden Lake действительно имеют схожие черты, например обе являются P2P сетями, обе дают возможность создавать свои сервисы, обе предлагают свою инфраструктуру как платформу связи. Но чисто технически у них всё же больше различий, чем сходств, в том числе и в способе анонимизации трафика.
I2P базируется на основе чесночной маршрутизации, как подвида луковой. Трафик упаковывается в дольки чеснока, а сами дольки могут точно также как в сети Tor упаковываться множественным шифрованием. Каждый раз, когда сообщение достигает своего маршрутизирующего узла, последний сдирает один из слоёв шифрования и транспортирует сообщение далее. На данном моменте, (пока без учёта ложного трафика) I2P уязвима точно также к глобальному наблюдателю, как и сеть Tor. Одноранговая архитектура от данного случая никак не спасает. Она может спасать от более частных атак, например от атак по времени, где по определению должен отсутствовать глобальный наблюдатель.
Теперь, если мы добавим генерацию ложного трафика в случайные периоды времени, то сути дела это не поменяет. Если связь между двумя абонентами длительная, например это есть передача файла, то подобная связь со временем будет выделяться от ложно генерируемого трафика, и наблюдатель будет это замечать, будет отделять спам (ложный трафик) от истинных сообщений. Иными словами, в сети I2P ложный трафик - это есть накладываемый трафик на уже существующий / истинный массив данных.
В Hidden Lake ситуация иная, ложный трафик не является дополнительным или внешним действием, он вшит в сам механизм, в само ядро анонимизации. Его невозможно отделить, как бы это мы могли успешно сделать в сети I2P. Задача на базе очередей (на которой основывается HL), для успешного своего выполнения, обязана всегда генерировать ложный трафик, потому что лишь при помощи него могут распространяться истинные сообщения. В ходе этого, когда ложный трафик заменяется в той же пропорции истинным, становится невозможным определение истинности / ложности итогового трафика. В этом и есть основное отличие I2P и HL в способе анонимизации.
Также есть и другие различия. Например, у HL отсутствует такая вещь как множественное шифрование. Все сообщения шифруются единожды и единожды расшифровываются истинным получателем. Не существует в привычном смысле маршрутизирующих узлов, которые существуют в Tor, I2P, Mixminion, Crowds и т.д. Существуют лишь ретрансляторы, которые перенаправляют сообщение в таком же виде, в котором они его приняли. Из-за этого HL по умолчанию является F2F сетью, чтобы предотвращять возможность осуществления дополнительных деанонимизирующих атак. Также в ходе этого HL предполагает, что отправитель и получатель априори идентифицируют друг друга (являются друзьями друг для друга), что нельзя сказать об I2P. В I2P отправитель и получатель - также анонимны друг к другу.
Также и по способу маршрутизации существуют отличия. В I2P используется модифицированная версия DHT для быстрой и анонимной маршрутизации трафика. В HL используется слепая маршрутизация, где трафик распространяется по всем узлам в сети. Последнее свойство является точно также обязательным для удержания теоретически доказуемой анонимности, но и в ходе этого HL начинает работать лишь в малых группах, в то время как I2P может работать в больших группах.
Согласно технической документации, SimpleX с этой целью использует «временные анонимные парные идентификаторы очередей сообщений», отдельные для каждого из соединений
Вывод: никак.
Плюс к этому, отсутствие идентификаторов ВООБЩЕ никоим образом не влияет ни на анонимность, ни на безопасность. Идентификация и аутентификация - это разные вещи. Необходимо не только идентифицировать пользователя, но и аутентифицировать им отправленные или полученные ранее сообщения. Если это сделать невозможно, или сложно, то знание идентификаторов особо ничего нам не даст.
Плюс к этому, идентификаторы могут быть вообще скрыты внутри шифрованного трафика и разглашаться лишь при определённых условиях истинным абонентам. Так например, в безопасном мессенджере Bitmessage и в анонимной сети Hidden Lake используется концепция, когда сообщение шифруется полностью, скрывая в том числе и данные об отправляющем и получающем. Единственный способ получить хоть какую-то информацию - это попытаться её расшифровать своим приватным ключом. Если не расшифровали, то значит сообщение было отправлено не вам. Если смогли расшифровать, то и сможете узнать от кого сообщение было отправлено.
Как минимум из этого примера мы видим, что существование идентификаторов никак не влияет ни на безопасность, ни на анонимность. Но при этом сам факт идентификации быть обязан (в том числе и в SimpleX), как минимум для последующей аутентификации принимаемых сообщений.
То, что SimpleX просто делает идентификаторы временными для сессии также не ново, но при этом такое действие приводит к массе других проблем (в этом направлении DC-сети ушли куда дальше и были разработаны куда раньше, став при этом первыми сетями с теоретически доказуемой анонимностью). Сам по себе обмен ключами в P2P системах - есть сложный процесс, но данный мессенджер его ещё и делает постоянно повторяемым. Как следствие, становятся возможными и чрезмерно эффективными MITM атаки, потому что мы знаем, что процесс обмена будет происходить почти в 100% случаев.
В качестве файлообменника он может вполне хорошо применяться, но он неанонимен ровно настолько, насколько неанонимен сам BitTorrent, на котором IPFS базируется. Плюс к этому, шифрования файлов в нём не предусмотрено, потому как он для этого просто не был предназначен. Но думаю IPFS вполне можно использовать поверх I2P, как это ранее делали с BitTorrent, но в таком случае уже не будет теоретически доказуемой анонимности, и как следствие, защиты от глобального наблюдателя.
На такой случай в HL существует концепция тайных каналов связи в композиции двух сервисов HLS+HLT. За счёт того что HL является абстрактной анонимной сетью, она может без проблем подстраиваться под любую среду, включая и централизованную систему. Тут существует несколько способов использования:
Использовать собственный VPS сервак и через него на уровне, например, HTTPS протокола (можно использовать и другие, подобия SSH, FTPS или подконтрольные из белого списка) пропускать весь трафик. В таком случае сам сервер станет обычным ретранслятором, заменив собой текущие HLT, которые работают на проде.
Использовать сторонний сервис, где связка HLS+HLT будет генерировать уже паразитный трафик. Централизованные сервисы не очень подобное любят и потому будут пытаться блокировать данные действия. Как следствие, размер сообщений ещё сильнее сократится, а период генерации сообщений увеличится с той лишь целью, чтобы паразитный трафик был менее заметен.
Как к переводу вопросов вообще нет, но статья же трижды переваренный к**, да и к тому же по уязвимостям, недостаткам, подводным камням от силы три предложения наберётся и то в виде сносок по типу "Что я для себя узнала".
Юзеру предлагается вручную сравнить отпечаток ключа при первом коннекте, и ничего плохого в этом нет.
Точно плохого ничего нет? А с чем он будет сравнивать то отпечаток? От куда он его получит? Само получение отпечатка также может быть подменено вместе с сертификатом.
создание настоящих вирусов с целю прямого причинения ущерба большому количеству людей
Ясно, чисто белые хакеры. Так и запишем
ECHO "LOH PIDR"
Профессионально
Использовать малопопулярный язык программирования, для которого нет большой базы сигнатур для поиска вирусов антивирусом
Одноразовый подход и то не всегда рабочий, некоторые языки программирования просто транслируются в другие. Да и вообще много языков программирования на вашей памяти, которые могут нормально компилироваться, бинарь которых не так велик, не транслируются в другой язык программирования и при этом непопулярны?
Использовать компилятор, которые НЕ шифрует исходный код
Проблема отказа в обслуживании действительно существует, но сеть всё же может являться открытой. Одним из возможных решений может стать создание разделённых друг от друга сетей, чтобы они не могли сливаться воедино. В Hidden Lake для этого присутствует как раз сущность - Network Key. В таком случае, если одна сеть будет сильно перегружена, то можно подключиться к другой сети. Т.к. ретрансляторы крайне примитивны и не требуют больших вычислений, то для поддержания одной сети будет достаточно даже одного выделенного ретранслятора.
Безусловно это не решает проблему полноценно, т.к. она находится очень глубоко, буквально зарыта в ядре всех ныне известных теоретически доказуемых анонимных сетей. Все попытки с моей стороны исследовать возможность искоринения линейной нагрузки на сеть приводили к дальнейшему ухудшению самой анонимности. И это наблюдалось не только в QB-сетях (к коим принадлежит Hidden Lake), но и также в EI-сетях и DC-сетях.
Поэтому не стоит забрасывать после таких новостей Дурова и сам Telegram фразами что «раньше было лучше», «Telegram продался», и других в этом духе
Ну так это так и есть, тенденция ухудшения на лицо. Ровно такая же тенденция наблюдалась и ранее в ВК (дежавю?).
Но можно похвалить их за то что они стараются не делать рекламу броской и навязчивой, а также что модерация очень старается не пропускать никакую рекламу которая нарушала бы их правила
Хвалить за таргетированную рекламу, это конечно сильно. Какой бы фантик реклама на себя не надевала, будь то интегрированный, вводный, фильтрованный, строгий она всегда остаётся рекламой. И если сравнивать потребительную выгоду от использования телеграма для обычных пользователей и меновую выгоду от самой выдачи рекламы со стороны сервисов, то у последних хотя бы появляется что-то материальное на руках, а у обычных людей лишь останется деградирующий мессенджер.
Так что Telegram держится молодцом и старается из-за всех сил поддерживать баланс в битве между желаниями рекламодателей и желаниями пользователей.
Как мы видим, все последние решения которые появляются, явно не в пользу желания пользователей.
В докере есть только поднятие самих сервисов (например, HLS, HLT, HLM), а также одновременное поднятие всех. Если говорить про связь с другими сетями и друзьями, то здесь уже надо вручную. Есть в примерах конечно уже готовые связи, например тут и тут, но все они пока локальны.
Схема интересная, опирается по большей части на безопасность самой криптографической хеш-функции, что хорошо. Но в этом подходе есть также и ряд подводных камней:
Хеш-функции в массе своей итеративны, вследствие этого, номер который дополняет ключ чисто теоретически может дополняться ещё "сверх того". Эта атака может быть применена когда совпадут одновременно два условия: 1) Хеш-функция успешно захешировала блоки в котором находится полный ключ, 2) Номер блока не дополняется до статичной длины. При таких условиях будет осуществима атака удлинения сообщения, где криптоаналитик сможет продолжить шифровать сообщение валидным ключом при этом его не зная. Вследствие этого, лучше использовать не хеш-функцию, а HMAC от этой хеш-функции,
Криптостойкость шифрованного блока ограничена числом N/2 (парадокс дней рождения), где N - длина выходного блока хеш-функции. Иными словами, через N/2 будет возможно взломать один из блоков с вероятностью >50%. Для SHA-256, SHA-512 это приемлемо, но для более малых хеш-функций (например MD5) - это уже будет уязвимостью. Вследствие этого, даже если энтропия ключа будет равна X, где X > N/2, то фактическая безопасность шифра останется всё также равной N/2,
Парольная фраза должна проходить всё же через KDF (например, scrypt, pbkdf2), а не через хеш-функцию. Это не повысит энтропию ключа, но повысит сложность полного перебора. Тем не менее, я бы в данной схеме вообще убрал данный блок, потому что это избыточно. Например, в спецификации AES нет пункта, который бы требовал пропускать ключ через KDF, т.к. предполагается, что ключ уже надёжный. Я бы просто в коде установил, что длина ключа должна быть равна N/2 от длины блока N. В таком случае, мы явно говорим, что безопасность нашего шифра равна N/2 с учётом атаки парадокса дней рождения,
В схеме не хватает дополнительной оказии для сеанса связи. Если шифрование повторится дважды с одним ключом, то это будет крайне плохим событием. Эта проблема уже опирается не на криптографическую хеш-функцию, а на поточную структуру вашего алгоритма. Данная проблема свойственна всем поточным шифрам и режимам шифрования формирующих поточность, как CTR, OFB. Для борьбы с этим либо создают случайный вектор инициализации для каждого шифрованного сообщения, либо уникальный номер для конкретного сеанса связи.
С этим согласен, малая группа всегда становится более уязвимой к репрессивному аппарату, чем большая. И в этом плане QB, EI, DC -сети проигрывают Onion, Proxy -сетям.
Тем не менее в такой концепции существует также ряд тонкостей. Например, анонимные сети с большими группами могут относительно легко делиться на малые подгруппы. Это достигается за счёт:
Конкретной маршрутизации, где из всего множества узлов удаляются непересекающиеся маршруты,
Частоты генерируемого трафика, где долгий период общения может уменьшать группу возможных участников,
Активных атак, где задержка связи или блокировка соединений может приводить к определению более конкретных связей между участниками.
Вследствие этого, большие группы со временем (после ряда проведённых наблюдений) могут делиться на малые подгруппы, каждая из которых уже будет анализироваться проще, чем малая группа такого же размера в QB, EI, DC -сетях.
Этого деления можно было бы избежать, если бы нашлась такая сеть с теоретически доказуемой анонимностью, которая бы при этом могла эффективно масштабироваться. К сожалению, пока такой сети открыто не было.
В сети Hidden Lake каждое сообщение подписывается закрытым ключом отправителя и далее шифруется открытым ключом получателя, с использованием гибридной схемы. В шифрованное сообщение вставляется публичный ключ отправителя, чтобы получатель успешно смог сразу проверить корректность полученной подписи. Более подробно на счёт данного протокола можно почитать здесь.
Если же речь про само доверие к публичному ключу, то здесь ситуация такая, что сеть HL предполагает F2F соединения, где каждый пользователь заранее выставляет свой список друзей (публичных ключей). Предполагается, что обмен ключами осуществляется либо лично, либо с использованием нескольких сервисов, как например описано тут.
Структура шифрованного сообщения, без её сокрытия и доказательства работы, выглядит следующим образом:
pubk - шифрованный публичный ключ отправителя,
enck - шифрованный сеансовый ключ пакета,
salt - шифрованный массив байт,
hash - шифрованный хеш сообщения,
sign - шифрованная подпись хеша,
после @ - шифрованное сообщение.
Чтобы успешно расшифровать сообщение - впервую очередь необходимо попытаться расшифровать сеансовый ключ (enck) своим приватным ключом. Если таковой успешно расшифровался, то можно будет расшифровать все остальные поля, а также сравнить хеш, подпись пакета.
Как понял, определение DH было взято из википедии. Тогда вот полное определение:
Нигде не сказано, что это протокол симметричного шифрования, это протокол распределения ключей. То, что его результаты используют уже в массе своей симметричные алгоритмы шифрования ничего не говорит о какой-либо симметричной сущности самого DH. Полученный секретный ключ может например использоваться в HMAC, что уже не есть симметричное шифрование.
Если нельзя - проблемы нет. Если льзя - проблема есть. В сети Tor, и в таком использовании, деанонимизировать можно.
Вряд ли это так. Наблюдателю известны все маршруты в пределах собственных границ, известен и нормализованный уровень трафика, известен и аномальный уровень трафика. Наложение одного на другое уже может дать чёткие маршруты, даже без учёта анализа сети Tor по его специфичному виду протокола.
Да, потому что Tor использует следующую модель угроз:
Анонимность сосредоточена на клиентской стороне больше, чем на серверной. Определить связь клиента с сервером сложнее, когда неподконтрольны клиент и сервер, нежели когда неподконтролен только сервер. Вероятность же инвертированной ситуации, когда сервер окажется подконтрольным, а клиент - нет, куда меньше, как минимум за счёт того, что сервер есть хранитель информации, профита с его деанонимизации можно получить куда больше,
В основе Tor заложен принцип федеративности, когда маршрутизирующие узлы располагаются на границах разных государств, а сам пакет множественно шифруется и внешне самоизменяется при переходе от одного узла к другому. Когда же происходит слежение за аномально большим трафиком на конечных точках, то от такой маршрутизации смысла становится ровно нуль, если сервер находится в пределах видимости внешнего наблюдателя, даже если сам пакет изменял свою форму в неподконтрольных государствах,
За счёт P2P архитектуры ситуация из второго пункта ухудшает ситуацию ещё больше. Существующие даркнет сайты, тобишь сервера в сети Tor продолжают существовать и функционировать лишь по той простой причине, что отправитель (клиент) и получатель (сервер) находятся в разных государствах. Сам сайт же деплоится в нескольких государствах. Вследствие этого: 1) массовые запросы начинают расщепляться по нескольким репликам, 2) выход из строя одного сервера не приводит к падению сайта. Когда отправитель и получатель находятся в пределах одного государства, тогда анонимизация в сети Tor начинает работать крайне плохо, даже с учётом всей запутывающей маршрутизации. У P2P сети, состоящей из рядовых пользователей, такой возможности как реплицировать себя на множество государств нет. А даже если будет, то всплывёт ещё масса других вопросов, как минимум на счёт консистентности хранимых данных и последующей анонимизации в новых условиях.
1. На правах придирок
Когда это DH стал протоколом симметричного шифрования?
Когда это EC криптография стала невзламываема для квантовых вычислений?
2. На правах непродуманной архитектуры
Сеть Tor есть крайне плохой выбор для такого рода хранилищ, когда пользователь подгружает всю базу данных / файлов себе на локальный компьютер или сервер. Если предположить, что вдруг, магическим образом, заспавнилась запрещёнка, то все начинают её подгружать себе. Ответственность за этот файл лежит теперь не на раздающем, а на хранящем.
Сеть Tor хорошо анонимизирует отправителей, но плохо анонимизирует получателей / сервера, собственно в этой архитектуре - всех P2P узлов. Банальный способ атаки будет сводиться к существованию двух атакующих: активного внутреннего и пассивного внешнего. Цель активного - просто генерация большого количества запросов на один из доменов. Цель пассивного - смотреть за аномально большим траффиком и вырисовывать получателей такого траффика. Если внешний наблюдатель - есть государство, то вся анонимность буквально будет рушиться на глазах, а все причастные с подгруженной запрещёнкой будут в сию минуту в местах не столь отдалённых.
Корпоративный блог RUVDS например
Могу посамопиариться и предложить сеть Hidden Lake, и на основе неё мессенджер HLM c:
Что I2P, что Hidden Lake действительно имеют схожие черты, например обе являются P2P сетями, обе дают возможность создавать свои сервисы, обе предлагают свою инфраструктуру как платформу связи. Но чисто технически у них всё же больше различий, чем сходств, в том числе и в способе анонимизации трафика.
I2P базируется на основе чесночной маршрутизации, как подвида луковой. Трафик упаковывается в дольки чеснока, а сами дольки могут точно также как в сети Tor упаковываться множественным шифрованием. Каждый раз, когда сообщение достигает своего маршрутизирующего узла, последний сдирает один из слоёв шифрования и транспортирует сообщение далее. На данном моменте, (пока без учёта ложного трафика) I2P уязвима точно также к глобальному наблюдателю, как и сеть Tor. Одноранговая архитектура от данного случая никак не спасает. Она может спасать от более частных атак, например от атак по времени, где по определению должен отсутствовать глобальный наблюдатель.
Теперь, если мы добавим генерацию ложного трафика в случайные периоды времени, то сути дела это не поменяет. Если связь между двумя абонентами длительная, например это есть передача файла, то подобная связь со временем будет выделяться от ложно генерируемого трафика, и наблюдатель будет это замечать, будет отделять спам (ложный трафик) от истинных сообщений. Иными словами, в сети I2P ложный трафик - это есть накладываемый трафик на уже существующий / истинный массив данных.
В Hidden Lake ситуация иная, ложный трафик не является дополнительным или внешним действием, он вшит в сам механизм, в само ядро анонимизации. Его невозможно отделить, как бы это мы могли успешно сделать в сети I2P. Задача на базе очередей (на которой основывается HL), для успешного своего выполнения, обязана всегда генерировать ложный трафик, потому что лишь при помощи него могут распространяться истинные сообщения. В ходе этого, когда ложный трафик заменяется в той же пропорции истинным, становится невозможным определение истинности / ложности итогового трафика. В этом и есть основное отличие I2P и HL в способе анонимизации.
Также есть и другие различия. Например, у HL отсутствует такая вещь как множественное шифрование. Все сообщения шифруются единожды и единожды расшифровываются истинным получателем. Не существует в привычном смысле маршрутизирующих узлов, которые существуют в Tor, I2P, Mixminion, Crowds и т.д. Существуют лишь ретрансляторы, которые перенаправляют сообщение в таком же виде, в котором они его приняли. Из-за этого HL по умолчанию является F2F сетью, чтобы предотвращять возможность осуществления дополнительных деанонимизирующих атак. Также в ходе этого HL предполагает, что отправитель и получатель априори идентифицируют друг друга (являются друзьями друг для друга), что нельзя сказать об I2P. В I2P отправитель и получатель - также анонимны друг к другу.
Также и по способу маршрутизации существуют отличия. В I2P используется модифицированная версия DHT для быстрой и анонимной маршрутизации трафика. В HL используется слепая маршрутизация, где трафик распространяется по всем узлам в сети. Последнее свойство является точно также обязательным для удержания теоретически доказуемой анонимности, но и в ходе этого HL начинает работать лишь в малых группах, в то время как I2P может работать в больших группах.
>
>
Вывод: никак.
Плюс к этому, отсутствие идентификаторов ВООБЩЕ никоим образом не влияет ни на анонимность, ни на безопасность. Идентификация и аутентификация - это разные вещи. Необходимо не только идентифицировать пользователя, но и аутентифицировать им отправленные или полученные ранее сообщения. Если это сделать невозможно, или сложно, то знание идентификаторов особо ничего нам не даст.
Плюс к этому, идентификаторы могут быть вообще скрыты внутри шифрованного трафика и разглашаться лишь при определённых условиях истинным абонентам. Так например, в безопасном мессенджере Bitmessage и в анонимной сети Hidden Lake используется концепция, когда сообщение шифруется полностью, скрывая в том числе и данные об отправляющем и получающем. Единственный способ получить хоть какую-то информацию - это попытаться её расшифровать своим приватным ключом. Если не расшифровали, то значит сообщение было отправлено не вам. Если смогли расшифровать, то и сможете узнать от кого сообщение было отправлено.
Как минимум из этого примера мы видим, что существование идентификаторов никак не влияет ни на безопасность, ни на анонимность. Но при этом сам факт идентификации быть обязан (в том числе и в SimpleX), как минимум для последующей аутентификации принимаемых сообщений.
То, что SimpleX просто делает идентификаторы временными для сессии также не ново, но при этом такое действие приводит к массе других проблем (в этом направлении DC-сети ушли куда дальше и были разработаны куда раньше, став при этом первыми сетями с теоретически доказуемой анонимностью). Сам по себе обмен ключами в P2P системах - есть сложный процесс, но данный мессенджер его ещё и делает постоянно повторяемым. Как следствие, становятся возможными и чрезмерно эффективными MITM атаки, потому что мы знаем, что процесс обмена будет происходить почти в 100% случаев.
Поправил, спасибо )
В качестве файлообменника он может вполне хорошо применяться, но он неанонимен ровно настолько, насколько неанонимен сам BitTorrent, на котором IPFS базируется. Плюс к этому, шифрования файлов в нём не предусмотрено, потому как он для этого просто не был предназначен. Но думаю IPFS вполне можно использовать поверх I2P, как это ранее делали с BitTorrent, но в таком случае уже не будет теоретически доказуемой анонимности, и как следствие, защиты от глобального наблюдателя.
На такой случай в HL существует концепция тайных каналов связи в композиции двух сервисов HLS+HLT. За счёт того что HL является абстрактной анонимной сетью, она может без проблем подстраиваться под любую среду, включая и централизованную систему. Тут существует несколько способов использования:
Использовать собственный VPS сервак и через него на уровне, например, HTTPS протокола (можно использовать и другие, подобия SSH, FTPS или подконтрольные из белого списка) пропускать весь трафик. В таком случае сам сервер станет обычным ретранслятором, заменив собой текущие HLT, которые работают на проде.
Использовать сторонний сервис, где связка HLS+HLT будет генерировать уже паразитный трафик. Централизованные сервисы не очень подобное любят и потому будут пытаться блокировать данные действия. Как следствие, размер сообщений ещё сильнее сократится, а период генерации сообщений увеличится с той лишь целью, чтобы паразитный трафик был менее заметен.
Как к переводу вопросов вообще нет, но статья же трижды переваренный к**, да и к тому же по уязвимостям, недостаткам, подводным камням от силы три предложения наберётся и то в виде сносок по типу "Что я для себя узнала".
Точно плохого ничего нет? А с чем он будет сравнивать то отпечаток? От куда он его получит? Само получение отпечатка также может быть подменено вместе с сертификатом.
UPD: но в общем статья получилась хорошая )
C++? Хоть и не под язык, но будет точно лучше отсутствия.
Так ещё конечно белых хакеров никто не называл
Ясно, чисто белые хакеры. Так и запишем
Профессионально
Одноразовый подход и то не всегда рабочий, некоторые языки программирования просто транслируются в другие. Да и вообще много языков программирования на вашей памяти, которые могут нормально компилироваться, бинарь которых не так велик, не транслируются в другой язык программирования и при этом непопулярны?
А какие шифруют?
На веру примем и не будем разбираться
Проблема отказа в обслуживании действительно существует, но сеть всё же может являться открытой. Одним из возможных решений может стать создание разделённых друг от друга сетей, чтобы они не могли сливаться воедино. В Hidden Lake для этого присутствует как раз сущность - Network Key. В таком случае, если одна сеть будет сильно перегружена, то можно подключиться к другой сети. Т.к. ретрансляторы крайне примитивны и не требуют больших вычислений, то для поддержания одной сети будет достаточно даже одного выделенного ретранслятора.
Безусловно это не решает проблему полноценно, т.к. она находится очень глубоко, буквально зарыта в ядре всех ныне известных теоретически доказуемых анонимных сетей. Все попытки с моей стороны исследовать возможность искоринения линейной нагрузки на сеть приводили к дальнейшему ухудшению самой анонимности. И это наблюдалось не только в QB-сетях (к коим принадлежит Hidden Lake), но и также в EI-сетях и DC-сетях.
Ну так это так и есть, тенденция ухудшения на лицо. Ровно такая же тенденция наблюдалась и ранее в ВК (дежавю?).
Хвалить за таргетированную рекламу, это конечно сильно. Какой бы фантик реклама на себя не надевала, будь то интегрированный, вводный, фильтрованный, строгий она всегда остаётся рекламой. И если сравнивать потребительную выгоду от использования телеграма для обычных пользователей и меновую выгоду от самой выдачи рекламы со стороны сервисов, то у последних хотя бы появляется что-то материальное на руках, а у обычных людей лишь останется деградирующий мессенджер.
Как мы видим, все последние решения которые появляются, явно не в пользу желания пользователей.
В докере есть только поднятие самих сервисов (например, HLS, HLT, HLM), а также одновременное поднятие всех. Если говорить про связь с другими сетями и друзьями, то здесь уже надо вручную. Есть в примерах конечно уже готовые связи, например тут и тут, но все они пока локальны.
Дубль: https://habr.com/ru/companies/cloud4y/articles/760400/