Comments 15
А в чем суть сети из примера так и не понятно.
Основная особенность сети заключается в том, что для сторонних узлов и наблюдателей задача выявления факта отправления или получения сообщений является вычислительно сложной вне зависимости от количества участников в сети и их связей между друг другом.
Вот еще немного про узлы стало интересно.
В примере подняты два узла и для их поднятия нужно прописывать публичные ключи в конфиги.
Как тогда строить сеть с другими (не подконтрольными) узлами?
Да, если вы знаете IP:port узла (опять же откуда его взять?), то можете запросить у него публичный ключ и прописать его себе во френды, но кто пропишет во френды того узла ваш pb key?
Как выбирать куда подключаться и как вообще должна формироваться топология таких сетей? И само по себе эта топология разве не раскрывает информацию о том с какими узлами общается наш узел в принципе.
Допускаю что эти моменты как-то освещены в ссылках на подробности, но там довольно объемные документы (как я уже говорил).
В сети 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).
Хм... получается я могу и вообще не иметь ни одного френда, но подключится к сети через ретранслятор....
Хорошо, ретранслятор - а как его найти в сети? Должен быть тогда какой-то список... и если этот список в открытом доступе, то похоже тут начнется самое интересное...
Правильно я понимаю, что ретранслятор примет сообщение от вообще любого узла?
Ретранслятор, как я понял, на одно сообщение должен послать N сообщений другим узлам. Ппри этом он не может знать - что там в сообщении т.к. все зашифровано, а у него нет ключей. И даже есть ли у узла приславшего ему сообщение френды - он тоже знать не может. Тогда и отличить спам от полезный сообщений - нет возможности. Так это прямо таки лакомый кусочек для DOS или DDOS атак. Положить узел, который из одного сообщения делает N - проще простого. И защиты никакой не сделать, на первый взгляд.
Хорошо, ретранслятор - а как его найти в сети? Должен быть тогда какой-то список...
Да, конфигурационные файлы с указанными ретрансляторами можно найти тут: _configs/prod. Есть также таблица ретрансляторов с более подробной информацией внизу файла README.
Правильно я понимаю, что ретранслятор примет сообщение от вообще любого узла?
Правильно, и это ключевая проблема, лежащая, на данный момент, в основе всех сетей с теоретически доказуемой анонимностью. DC (проблема обедающих криптографов), QB (задача на базе очередей), EI (задаче на базе увеличения энтропии) -сети все плохо масштабируются.
Hidden Lake, основываясь на QB-задаче, также не решает проблему масштабируемости окончательно, поэтому как вы полностью верно указали, она может подвергаться DoS и DDoS атакам. Для того, чтобы такие атаки сделать менее влиятельными в Hidden Lake предусмотрены следующие моменты:
Сеть HL может расщепляться на несколько подсетей с общей логикой функционирования за счёт использования разных network_key параметров,
Для того, чтобы сети с разными network_key параметрами проблематично сливались в одну систему, используется алгоритм доказательства работы (PoW),
Параметр network_key может быть секретным значением. В таком случае преднамеренные атаки отказа в обслуживании становятся наименее вероятными.
Если это всё переносить на Hidden Lake в открытой сети, то безусловно network_key параметр не будет являться секретным, поэтому третий пункт отпадает. В HL существует четыре ретранслятора, каждый из которых с разным network_key. В таком случае, для последующего успешного общения должен быть выбран один из них.
если в сети Т узлов и каждый генерирует Т сообщений через Х времени, то при росте количества узлов не получится ли аналог броадкаст шторма? Я не увидел в статье ничего об отсечении пакетов (может слишком бегло читал). Ведь при достаточно большом потоке данных все это ляжет само собой безо всякого ддоса. Или оно предназначено только для совсем мелких пакетов/мелких групп?
Отсечение пакетов происходит только на уровне дедупликации, в остальном никаких механизмов противодействия перегрузкам излишним трафиком нет. Если система будет масштабироваться, то каждый узел будет принимать от неё всё больше трафика. Постепенно это будет приводить к отсеканию наиболее слабых узлов от сети, неспособных своевременно редиректить и дешифровывать трафик. Вследствие этого, сеть действительно будет способна работать только в пределах малых групп, например 50-100 узлов (в зависимости от их мощностей).
тогда какой смысл? сеть такого размера легко накроется кем угодно.
Смысл в уникальных возможностях никуда не исчезает - даже при таких атаках всегда будет существовать прослойка специфичного прикладного применения. В некоторых случаях защититься от кого-угодно легко просто использованием секретного сетевого ключа. В других случаях уже приходиться ухищряться и разделять сеть на множество подсетей, чтобы атакующему необходимо было совершать больше вычислений.
Помимо этого, сеть Hidden Lake не является монолитным решением подобно сетям Tor и I2P. Напротив, сеть HL спроектирована таким образом, чтобы она умела разворачиваться почти что в любой сетевой среде - в локальной или глобальной, в централизованной или децентрализованной, с минимальным количеством условий. Это становится определённого рода компенсацией в обмен невозможности успешного масштабирования. Таким образом, создаётся ситуация при которой сеть может как быстро падать, так и быстро восстанавливаться из-за своей специфичной автономности.
все равно звучит не очень убедительно. Если скажем 2 человека захотят пообщаться анонимно, то развернув сеть они получат пшик: их всего двое и кто и когда отправлял понятно сразу. Если же они решат подключиться к существующей сети, то им надо мощное железо, иначе их дохлые одноразовые смартфоны просто зависнут на броадкастах. Это если роутеры не отсекут непонятный паразитный траффик (я не очень спец, но так же можно и сетевой роутер положить раньше, чем сам комп).
А покупая топовое железо ради анонимности - вы уже привлекаете внимание. Тут даже в технологиях не нужно слишком разбираться, чтобы это все выглядело сомнительно. Впрочем, как и тор.
Если скажем 2 человека захотят пообщаться анонимно, то развернув сеть они получат пшик: их всего двое и кто и когда отправлял понятно сразу. Если же они решат подключиться к существующей сети, то им надо мощное железо, иначе их дохлые одноразовые смартфоны просто зависнут на броадкастах.
Вы разбираете крайние случаи, что с одной стороны, что с другой. Помимо двух этих сторон могут существовать и вполне благоприятные условия среды, когда сеть не перегружена, но присутствует хотя бы несколько узлов.
Это если роутеры не отсекут непонятный паразитный траффик (я не очень спец, но так же можно и сетевой роутер положить раньше, чем сам комп)
Отсечение паразитного трафика скорее вряд-ли, если роутер специально не был на это настроен. По поводу выхода из строя (в плане корректной работоспособности) - может, если пакеты будут сильно большими или если будет много пакетов сумма которых будет превосходить лимит выставленный провайдером связи (мбит/с, гбит/с). Для текущей настройки сети HL размер пакета равен 8КиБ. Каждый узел генерирует его раз в пять секунд, т.е. в секунду будет генерироваться ~1.6КиБ. При редиректах данный пакет может возвращаться отправителю, предположим, что в худшем случае будет в секунду генерироваться ~3.2КиБ/с или ~25.6 кбит/с. Чтобы перегрузить роутер с лимитом в 100мбит/с потребуется примерно 4000 узлов, что скорее всего никогда не произойдёт, т.к. процессорные мощности закончатся раньше.
А покупая топовое железо ради анонимности - вы уже привлекаете внимание
Не настолько сеть требовательна, чтобы собирать топовое железо. Основные затраты узла, при небольшой группе участников, заключаются в генерации трафика с его же стороны, т.к. используется PoW. Попытка расшифрования сообщений занимает меньше ресурсов. Только когда увеличивается трафик, тогда количество ресурсов на расшифрование трафика начинает превосходить затрачиваемые ресурсы на PoW.
Также, из-за относительной автономности сети, такие параметры как: длина ключа, сложность работы и период генерации сообщений - могут настраиваться. Вследствие этого, даже если устройства в системе очень слабые, сеть можно подстроить под конкретную среду исполнения.
del
Быстрое введение в сеть Hidden Lake