В сети Hidden Lake существует фактически два уровня маршрутизации: сетевой и криптографический.
Сетевой уровень работает с идентификацией по IP адресам, где могут быть указаны как ретрансляторы, так и непосредственно полноценные узлы, через которые трафик будет транспортироваться. При этом каких-либо отличий узлов от ретрансляторов на данном уровне маршрутизации нет, т.к. главная его цель - просто распространить сообщение по всем узлам в сети без знания того является ли сообщение истинным или ложным. Иными словами, для распространения сообщений используется заливочная маршрутизация.
Истинная же маршрутизация начинает выстраиваться лишь на криптографическом уровне, когда происходит отправление сообщений с использованием публичных ключей. Если узел получает шифрованное сообщение из сети, но при этом оно не расшифровывается его приватным ключом, то это означает, что сообщение было отправлено не ему. Если же узел смог успешно расшифровать принятое сообщение из сети, то значит, что сообщение было назначено конкретно ему.
Да, если вы знаете IP:port узла (опять же откуда его взять?), то можете запросить у него публичный ключ и прописать его себе во френды, но кто пропишет во френды того узла ваш pb key?
Обмен публичными ключами и дальнешая их установка должна осуществляться вне сети Hidden Lake. Это может быть как физический обмен ключами, так и обмен ключами посредством например такого протокола. В HL можно также и отключить опцию F2F, прописав в настройках конфига строчку f2f_disabled: true, но я бы не стал такого делать из-за возможности спама, а также возможных активных наблюдений за состоянием очереди, хоть это в сумме и упростит дальнейшую коммуникацию.
Как выбирать куда подключаться и как вообще должна формироваться топология таких сетей? И само по себе эта топология разве не раскрывает информацию о том с какими узлами общается наш узел в принципе.
Подключаться можно к ретрансляторам или к уже существующим узлам с внешним адресом. Все такие подключения будут происходить на сетевом уровне, а потому выстраиваемая топология никак не будет приводить к раскрытию информации об общении узлов. Наблюдателю будет доступна лишь информация об участниках сети, т.е. информация об их факте подключения к сети. Информация же о каком-либо факте отправления или получения сообщений будет для него недоступна. Если необходимо скрывать также и принадлежность участников к сети, то можно это сделать посредством сокрытия / инкапсуляции анонимизированного трафика в HTTPS (адаптеры), выстраиванием динамических периодов (rand_queue_period_ms>0) и размеров сообщений (rand_message_size_bytes>0).
Основная особенность сети заключается в том, что для сторонних узлов и наблюдателей задача выявления факта отправления или получения сообщений является вычислительно сложной вне зависимости от количества участников в сети и их связей между друг другом.
Насколько знаю большинство современных алгоритмов цифровой подписи базируются на схеме Эль-Гамаля, в который по умолчанию закладывается механизм удвоения размера выходных данных. Для сохранения 128-битной безопасности используют 256-битный ключ, который, в свою очередь, уже генерирует 512-битные подписи (тобишь 64 байта). Насколько знаю на практике также часто могут применяться эллиптические кривые 224-битные, которые могут создавать подписи размером 56 байт. Но они, в свою очередь, придерживаются минимальной планки безопасности в 112-бит, что может быть опасным при долгосрочном использовании.
NIST: сравнительная характеристика длин ключей при лобовой атаке
Было бы интересно подобное разобрать, но при написании статьи потеряется особенность, которая ранее содержалась в алгоритме RSA, - обманчивая простота. В криптографии на эллиптических кривых такой обманчивости мало, и как следствие, описание самих атак станет более изощрённым занятием. Поэтому схожего разбора эллиптических кривых мной пока не планируется, но не буду говорить и о том, что такого разбора не будет вовсе. Скорее всего будет, просто в другой оболочке.
Истинно оно действительно не всегда, но чем больше централизованная система начинает расширяться, чем больше она начинает вбирать в себя пользователей, тем сильнее она впадает в стадию метаморфозов, когда интересы продолжают своё движение уже чисто в экономическом русле, где от первичного энтузиазма мало что остаётся. Такое движение поощряется и поддержкой сервиса в его способности существовать, и в выдаче зарплаты сотрудникам, и государствами на уровне кнута и пряника - либо сбор данных и последующая лояльность, либо отказ в сборе и последующая блокировка. При завершении подобных метаморфозов система начинает жить уже не для клиентов, а за счёт них. Это хорошо наблюдается в развитии компаний и технологий, которые ранее действительно создавались на энтузиазме, но впоследствии скатились в беспроссветную выдачу таргетированной рекламы и сбор конфиденциальных / персональных данных клиентов.
С первой половиной суждений я полностью согласен, более того, они также и не противоречат самому содержанию статьи. Проблема анонимности действительно социальная, этого я также не отрицаю.
Давайте начнем с того, что настоящий коммунизм - анархический
Это сильное упрощение двух идей, посредством которого они далее начинают сводиться к одной сущности. Если мы говорим о конечной цели, то да, несомненно оба течения стремятся к ликвидации классовых противоречий, к ликвидации государства, как аппарата насилия. Если же мы говорим о способах достижения цели, то они рознятся довольно сильно. С одной стороны коммунистическое движение должно пройти через этап ещё бОльшей централизации, через этап ещё бОльшей концентрации средств производства, через этап захвата и удержания аппарата насилия, чтобы достичь того момента, когда базовые товары будут производиться преимущественно автоматическим образом, и за счёт чего их дальнейшая стоимость будет приближаться к нулю. С другой стороны движение анархизма напротив, отрицает необходимость такой централизации, исключает захват аппарата насилия для своих интересов, и ставит разрушение государства первостепенной важностью.
А уж ваше упование на корпорации
У меня нет никакого упования на корпорации, я их не идеализирую и не выдаю их за венок эволюции. Основной их плюс - это их предсказуемость, они экономически рациональны и лишь по этой простой причине в них могут прослеживаться интересные противоречия. Но возлагать на корпорации какие-либо надежны - слишком утопично. Корпорациям важна прибыль и если технологии начнут идти в убыток, то такие технологии либо будут забываться, либо будут уничтожаться. Криптовалюты как раз хорошо играют на этом противоречии, с одной стороны предоставляя способы увеличения капитала, с другой стороны предоставляя развитие безопасных средств коммуникации.
Как работает блокчейн: объяснение от эксперта по ML и AI Петра Емельянова
По статье вопросов нет, вполне хорошая, но название заголовка хромает прям логически. Как экспертиза в одной сфере может быть перенесена на совершенно иную сферу? Если никак, то зачем это вообще указывать? ML в блокчейне редкость, да и в самой статье про это также ни слова.
Схема интересная, опирается по большей части на безопасность самой криптографической хеш-функции, что хорошо. Но в этом подходе есть также и ряд подводных камней:
Хеш-функции в массе своей итеративны, вследствие этого, номер который дополняет ключ чисто теоретически может дополняться ещё "сверх того". Эта атака может быть применена когда совпадут одновременно два условия: 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, но в таком случае уже не будет теоретически доказуемой анонимности, и как следствие, защиты от глобального наблюдателя.
В сети Hidden Lake существует фактически два уровня маршрутизации: сетевой и криптографический.
Сетевой уровень работает с идентификацией по IP адресам, где могут быть указаны как ретрансляторы, так и непосредственно полноценные узлы, через которые трафик будет транспортироваться. При этом каких-либо отличий узлов от ретрансляторов на данном уровне маршрутизации нет, т.к. главная его цель - просто распространить сообщение по всем узлам в сети без знания того является ли сообщение истинным или ложным. Иными словами, для распространения сообщений используется заливочная маршрутизация.
Истинная же маршрутизация начинает выстраиваться лишь на криптографическом уровне, когда происходит отправление сообщений с использованием публичных ключей. Если узел получает шифрованное сообщение из сети, но при этом оно не расшифровывается его приватным ключом, то это означает, что сообщение было отправлено не ему. Если же узел смог успешно расшифровать принятое сообщение из сети, то значит, что сообщение было назначено конкретно ему.
Обмен публичными ключами и дальнешая их установка должна осуществляться вне сети Hidden Lake. Это может быть как физический обмен ключами, так и обмен ключами посредством например такого протокола. В HL можно также и отключить опцию F2F, прописав в настройках конфига строчку f2f_disabled: true, но я бы не стал такого делать из-за возможности спама, а также возможных активных наблюдений за состоянием очереди, хоть это в сумме и упростит дальнейшую коммуникацию.
Подключаться можно к ретрансляторам или к уже существующим узлам с внешним адресом. Все такие подключения будут происходить на сетевом уровне, а потому выстраиваемая топология никак не будет приводить к раскрытию информации об общении узлов. Наблюдателю будет доступна лишь информация об участниках сети, т.е. информация об их факте подключения к сети. Информация же о каком-либо факте отправления или получения сообщений будет для него недоступна. Если необходимо скрывать также и принадлежность участников к сети, то можно это сделать посредством сокрытия / инкапсуляции анонимизированного трафика в HTTPS (адаптеры), выстраиванием динамических периодов (rand_queue_period_ms>0) и размеров сообщений (rand_message_size_bytes>0).
Возможно вы правы, т.к. при написании мной был поставлен больше упор именно на запуск узла. Добавил спойлер «Немного о QB-задаче».
Основная особенность сети заключается в том, что для сторонних узлов и наблюдателей задача выявления факта отправления или получения сообщений является вычислительно сложной вне зависимости от количества участников в сети и их связей между друг другом.
Насколько знаю большинство современных алгоритмов цифровой подписи базируются на схеме Эль-Гамаля, в который по умолчанию закладывается механизм удвоения размера выходных данных. Для сохранения 128-битной безопасности используют 256-битный ключ, который, в свою очередь, уже генерирует 512-битные подписи (тобишь 64 байта). Насколько знаю на практике также часто могут применяться эллиптические кривые 224-битные, которые могут создавать подписи размером 56 байт. Но они, в свою очередь, придерживаются минимальной планки безопасности в 112-бит, что может быть опасным при долгосрочном использовании.
Было бы интересно подобное разобрать, но при написании статьи потеряется особенность, которая ранее содержалась в алгоритме RSA, - обманчивая простота. В криптографии на эллиптических кривых такой обманчивости мало, и как следствие, описание самих атак станет более изощрённым занятием. Поэтому схожего разбора эллиптических кривых мной пока не планируется, но не буду говорить и о том, что такого разбора не будет вовсе. Скорее всего будет, просто в другой оболочке.
Дежавю недельной выдержки?
Истинно оно действительно не всегда, но чем больше централизованная система начинает расширяться, чем больше она начинает вбирать в себя пользователей, тем сильнее она впадает в стадию метаморфозов, когда интересы продолжают своё движение уже чисто в экономическом русле, где от первичного энтузиазма мало что остаётся. Такое движение поощряется и поддержкой сервиса в его способности существовать, и в выдаче зарплаты сотрудникам, и государствами на уровне кнута и пряника - либо сбор данных и последующая лояльность, либо отказ в сборе и последующая блокировка. При завершении подобных метаморфозов система начинает жить уже не для клиентов, а за счёт них. Это хорошо наблюдается в развитии компаний и технологий, которые ранее действительно создавались на энтузиазме, но впоследствии скатились в беспроссветную выдачу таргетированной рекламы и сбор конфиденциальных / персональных данных клиентов.
С первой половиной суждений я полностью согласен, более того, они также и не противоречат самому содержанию статьи. Проблема анонимности действительно социальная, этого я также не отрицаю.
Это сильное упрощение двух идей, посредством которого они далее начинают сводиться к одной сущности. Если мы говорим о конечной цели, то да, несомненно оба течения стремятся к ликвидации классовых противоречий, к ликвидации государства, как аппарата насилия. Если же мы говорим о способах достижения цели, то они рознятся довольно сильно. С одной стороны коммунистическое движение должно пройти через этап ещё бОльшей централизации, через этап ещё бОльшей концентрации средств производства, через этап захвата и удержания аппарата насилия, чтобы достичь того момента, когда базовые товары будут производиться преимущественно автоматическим образом, и за счёт чего их дальнейшая стоимость будет приближаться к нулю. С другой стороны движение анархизма напротив, отрицает необходимость такой централизации, исключает захват аппарата насилия для своих интересов, и ставит разрушение государства первостепенной важностью.
У меня нет никакого упования на корпорации, я их не идеализирую и не выдаю их за венок эволюции. Основной их плюс - это их предсказуемость, они экономически рациональны и лишь по этой простой причине в них могут прослеживаться интересные противоречия. Но возлагать на корпорации какие-либо надежны - слишком утопично. Корпорациям важна прибыль и если технологии начнут идти в убыток, то такие технологии либо будут забываться, либо будут уничтожаться. Криптовалюты как раз хорошо играют на этом противоречии, с одной стороны предоставляя способы увеличения капитала, с другой стороны предоставляя развитие безопасных средств коммуникации.
По статье вопросов нет, вполне хорошая, но название заголовка хромает прям логически. Как экспертиза в одной сфере может быть перенесена на совершенно иную сферу? Если никак, то зачем это вообще указывать? ML в блокчейне редкость, да и в самой статье про это также ни слова.
Схема интересная, опирается по большей части на безопасность самой криптографической хеш-функции, что хорошо. Но в этом подходе есть также и ряд подводных камней:
Хеш-функции в массе своей итеративны, вследствие этого, номер который дополняет ключ чисто теоретически может дополняться ещё "сверх того". Эта атака может быть применена когда совпадут одновременно два условия: 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, но в таком случае уже не будет теоретически доказуемой анонимности, и как следствие, защиты от глобального наблюдателя.