Нет, они сами являются «конечной точкой» в е2е и имеют доступ к этой информации легитимно
Легитимно - (в юридическом смысле этого слова) может быть (и то случаются натяжки), сквозное ли это шифрование - точно нет. Суть E2E шифрования в том, что оно должно протягиваться до конечных точек, в мессенджерах конечные точки - это друзья, с которыми ты общаешься, это группы, ленту которых ты просматриваешь и т.д., но точно не сам сервис. Такой же принцип с маркетплейсами, конечная точка - это продавец, а не сам сервис. Такой же принцип с электронной почтой, конечная точка - это получатель письма, а не сервис электронной почты. И т.д., и т.п. ...
Между тобой и сервером ВК, а также между сервером ВК и твоим другом есть две, вполне себе e2e зашифрованные линии
Это не E2E шифрование, а обычное, что ни на есть, клиент-серверное шифрование, где безопасная коммуникация строится только от клиентов к серверу, а не от клиентов к клиентам.
Сквозное шифрование гарантирует, что данные остаются конфиденциальными не только для внешних злоумышленников, но и для самих компаний, предоставляющих услуги
...
Яркий пример — https-протокол
То-есть, ВКонтакте, Одноклассники, Ozon, WB, Mail.ru и прочие - это всё примеры сервисов со сквозным шифрованием, где даже сам сервис не знает что вы отправляете, что вы покупаете, что вы просматриваете?
Скорее всего вы просто не разобрались в теме, либо ещё проще - воспользовались нейросетью, чтобы она сказала, что есть такое сквозное (E2E) шифрование.
При этом, я не говорю, что централизованные сервисы вовсе бесполезны в концепте E2E шифрования. Так например, я могу обменяться лично публичным ключом со своим другом, а далее использовать ВКонтакте, как платформу, для обмена шифртекстами. В этом случае у нас создаётся действительно сквозное шифрование - шифрование, при котором только истинный собеседник получает открытый текст. Все промежуточные узлы, начиная от провайдеров связи и заканчивая централизованными сервисами - получают лишь шифртекст. И как видно, HTTPS здесь вообще никакой роли не играет, даже если бы использовался голый HTTP, сквозное шифрование оставалось бы нетронутым.
Все чаты защищены с помощью симметричного шифрования, при этом используется принцип одноразового блокнота, то есть каждое сообщение шифруется новым ключом.
Ничего общего с одноразовым блокнотом это не имеет. В ссылке, в которой вы же указываете, есть точные критерии, как минимум - условие истинной случайности. Если таковой нет, то ни о каком одноразовом блокноте уже и не стоит говорить. В ином случае, мы так и поточные шифры легко сможем сравнять с одноразовыми блокнотами.
Постоянный идентификатор позволяет соотнести личность анонимного пользователя с профилями в социальных сетях и определить его настоящее имя.
Идентификатор позволяет определить личность ровно настолько же насколько позволяет в SimpleX определить эту же самую личность "временные анонимные парные идентификаторы очередей сообщений", которыми клиенты обмениваются. Иными словами, как бы мессенджер не говорил об отсутствии идентификации, но сделать его безопасным, без какой бы то ни было идентификации, - невозможно. Либо мы шифруем сообщения и априори добавляем в схему методы аутентификации (и как следовательно идентификации), либо мы вообще не шифруем сообщения.
На счёт не шифрования сообщений - не всё так безрассудно, как может показаться на первый взгляд, потому как анонимность != безопасность. Так например, DC-сети (сети на базе проблемы обедающих криптографов) вообще не шифруют сообщение как таковое, а просто отправляют его всем узлам в сети, но при этом, анонимность близка к идеальной (в плане сетевого распространения сообщений), т.к. скрывает источника (отправителя) информации с хорошими гарантиями.
подключение к удалённым серверам через Tor;
Вот это вообще бомба. В двух из трёх вами описанных мессенджерах фактически реальная анонимность формируется не за счёт архитектурных решений, принятых разработчиками, а за счёт использования уже готового решения в лице Tor'а. А в третьем мессенджере так вообще не понятно за счёт чего формируется хоть какая-то анонимность. SimpleX и Technitium Mesh без Tor'a нельзя было бы назвать анонимными мессенджерами, их можно было бы просто относить к мессенджерам по типу Signal или Telegram (с секретными чатами). Т.е. вся их фича анонимности в большей мере лежит на сторонней технологии, а не на их изобретённых новшествах. Они архитектурно безопасны, но их анонимность достигается не за счёт них самих.
Основная суть анонимности - это скрывать связь между множеством отправителей и получателей от множества наблюдателей. Отсутствие идентификаторов - решающей роли в этом не играет, Непонятно как все эти описанные мессенджеры скрывают связь между реальным отправителем и реальным получателем, если вдруг каким-то образом их сервера или узлы захватит наблюдатель, или если таковой наблюдатель вообще будет глобальным. Tor - даёт определённый спектр решений и некоторые гарантии, а также ограничения. SimpleX, Technitium Mesh и BeProg (в чистом виде) - не дают гарантий вовсе.
Я отрицательную оценку не ставил, но пробелы в повествовании всё же есть:
1.
Если мы шифруем, например JSON документ, отправляем на обработку, где вносятся минимальные изменения где-нибудь в конце или середине — мы это узнаем.
Чтобы этого не было, используется как раз вектор инициализации. В статье про его предназначение особо ничего не сказано, кроме того, что он опционален, хотя на деле - скорее обязателен, потому как, действительно, его отсутствие приводит к описанной вами проблеме.
Из этого также вытекает теперь и то, что одинаковый минус, приписанный к CBC, CFB, OFB, по поводу малого изменения данных в середине или конце открытого текста, просто исчезает.
2.
В определении "шифратора", алгоритм дополнения кажется излишним. И действительно, в поточных режимах по типу OFB, CTR, а также "полу-поточном" CFB - алгоритма дополнения нет вовсе.
Плюс к этому, режимы шифрования, базируемые на дополнении (как пример, CBC), могут обладать также интересным вектором атак с оракулом. Было бы неплохо этот пункт внести как минус или предупреждение.
3.
Следуя спецификациям режима CTR мы XOR'им значение счетчика с блоком открытого текста, а затем шифруем. Алгоритм похож на CBC, по крайней мере визуально, но лишен его недостатков.
Ничего также не сказано о минусах поточных режимов шифрования по типу CTR, OFB, а именно - что если мы будем использовать один и тот же ключ шифрования с идентичным вектором инициализации / счётчиком? В таком случае, мы сможем вообще удалить ключ шифрования: (m1 xor k) xor (m2 xor k) = m1 xor m2, что является серьёзной уязвимостью, если не противодействовать повторениям.
UPD. Визуально всё же OFB больше похож на CBC, чем CTR.
UPD. Также почему-то в CTR счётчик стал просто вектором инициализации, хотя это уже не инициализация, раз таковая применяется в каждом блоке шифрования. Плюс к этому у счётчика в CTR - два параметра: константное (сеанс связи) и переменное (сам счётчик) значения. В статье об этом также ничего не сказано.
Вопрос действительно интересный, т.к. основная проблема перехода - это потеря идентификации узлов. Если это система по типу криптовалют, где всё держится на подобного рода идентификации - необходимым условием становится связывание ключей, где ключ RSA подписывает ключ ML-DSA, а ML-DSA - ключ RSA. Соответственно в логике криптовалют / блокчейна должны будут храниться два ключа с последующей возможностью их валидации. Если RSA ещё не взломан, он вполне себе может подтверждать идентификацию участника через ML-DSA какое-то время. Этого времени должно быть достаточно ровно настолько, чтобы оставшиеся узлы смогли перейти на подтверждённый ML-DSA ключ, а RSA ключ воспринять как Deprecated. Таким образом, предполагается, что до создания мощного квантового компьютера состояние Deprecated сможет перейти в состояние Forbidden, а все действия, что происходили с RSA ключом в виде хеша будут сохранены в состоянии под ML-DSA подписью.
С анонимными сетями ситуация немного упрощённее, т.к. не требуется хранить состояние, плюс к этому не все анонимные сети в равной степени будут сложнопереносимы. Как пример, для сети Tor переход на постквантовые алгоритмы будет более простым, чем для I2P, т.к. бОльшая часть коммуникаций связана у него всё же с открытым Интернетом, а не внутренними Hidden Services. Что касается Hidden Lake, то тут ситуация ещё проще, потому как: 1) у HL нет какой-то одной глобальной сети, в отличие от Tor или I2P, вследствие чего одна сеть может работать на RSA, другая - на ML-DSA, 2) HL работает с малыми группами узлов, а потому обновить их будет чисто количественно проще, 3) HL не настолько популярна как Tor, I2P, поэтому радикальные обновления можно делать более смело.
Что касается Hidden Lake, как концепта - год назад сеть таковой действительно являлась, сейчас уже скорее нет, чем да, т.к.: 1) сеть вполне успешно функционирует, ретрансляторы запущены и распределяют / сохраняют шифртексты, 2) исследовательские работы написаны, рассмотрены пределы сети, её достоинства и уязвимости, 3) основная часть кода, связанная с анонимностью и безопасностью, покрыта тестами более чем на 98% (пакет go-peer).
По умолчанию маскировка пакетов отсутствует. Так например, при подключении к готовым ретрансляторам можно достаточно легко определить принадлежность трафика к анонимной сети: 1) сообщения генерируются каждые 5 секунд, 2) размер каждого сообщения равен 8KiB, 3) каждое сообщение отправляется по TCP вида len(c) || c, где c - шифртекст, len - размер сообщения, 4) каждое сообщение ретранслируется на всех участников.
Но на самом деле не всё так мрачно, т.к вышеописанный паттерн - это лишь один из способов запуска. Период генерации в HL может становиться динамичным (параметр rand_queue_period>0), размер сообщения может быть варьируемо-случайным (параметр rand_message_size_bytes>0), сообщения могут передаваться по другим протоколам, например HTTPS (фича с len - специфика только при сырых TCP соединениях), за счёт использования адаптеров.
по факту это тот же https с но самописный и не продуманный
С HTTPS здесь очень мало схожего, разве что есть асимметричный алгоритм, и на этом собственно все схожести заканчиваются.
если больше 1й ноды, придется передавать ключи всех НОД
Не придётся, ноды могут быть несвязаны между собой вовсе асимметричными ключами. Если существует три узла, то может существовать вероятность того, что только два узла всегда коммуницируют между собой, в то время как третий постоянно генерирует ложный трафик и не знает публичные ключи других узлов.
расшифровка сообщений будет по экспоненте
Расшифровка линейна (от количества участников в сети), но точно не экспонциональна.
Анонимность QB-задачи в скрытии факта общения. Наблюдателям сложно определить состояние анализируемого узла: отправляет ли он какие-нибудь сообщения, принимает их или вовсе бездействует. Вследствие этого, становится сложно определить существование реальной коммуникации между несколькими узлами.
AsmX Foundation реализовали довольно необычную систему, которая больше похожа на JIT‑компилятор, но не является классической виртуальной машиной. Впервые я сталкиваюсь с подобным подходом, и это можно считать своего рода ноу‑хау
Ассемблер на интерпретаторе JS-кода - это и вправду ноу-хау, потому что смысла в этом = 0.
Ассемблер — это низкоуровневый язык программирования, который напрямую взаимодействует с аппаратным обеспечением.
AsmX подходит под данное определение? Вопрос конечно риторический. С учётом того, как автор данной статьи восхищается AsmX - не удивлюсь, что он есть также и автор данного ассемблера. Более подробно про AsmX можно почитать в статье: Обзор языка программирования AsmX.
Если скажем 2 человека захотят пообщаться анонимно, то развернув сеть они получат пшик: их всего двое и кто и когда отправлял понятно сразу. Если же они решат подключиться к существующей сети, то им надо мощное железо, иначе их дохлые одноразовые смартфоны просто зависнут на броадкастах.
Вы разбираете крайние случаи, что с одной стороны, что с другой. Помимо двух этих сторон могут существовать и вполне благоприятные условия среды, когда сеть не перегружена, но присутствует хотя бы несколько узлов.
Это если роутеры не отсекут непонятный паразитный траффик (я не очень спец, но так же можно и сетевой роутер положить раньше, чем сам комп)
Отсечение паразитного трафика скорее вряд-ли, если роутер специально не был на это настроен. По поводу выхода из строя (в плане корректной работоспособности) - может, если пакеты будут сильно большими или если будет много пакетов сумма которых будет превосходить лимит выставленный провайдером связи (мбит/с, гбит/с). Для текущей настройки сети HL размер пакета равен 8КиБ. Каждый узел генерирует его раз в пять секунд, т.е. в секунду будет генерироваться ~1.6КиБ. При редиректах данный пакет может возвращаться отправителю, предположим, что в худшем случае будет в секунду генерироваться ~3.2КиБ/с или ~25.6 кбит/с. Чтобы перегрузить роутер с лимитом в 100мбит/с потребуется примерно 4000 узлов, что скорее всего никогда не произойдёт, т.к. процессорные мощности закончатся раньше.
А покупая топовое железо ради анонимности - вы уже привлекаете внимание
Не настолько сеть требовательна, чтобы собирать топовое железо. Основные затраты узла, при небольшой группе участников, заключаются в генерации трафика с его же стороны, т.к. используется PoW. Попытка расшифрования сообщений занимает меньше ресурсов. Только когда увеличивается трафик, тогда количество ресурсов на расшифрование трафика начинает превосходить затрачиваемые ресурсы на PoW.
Также, из-за относительной автономности сети, такие параметры как: длина ключа, сложность работы и период генерации сообщений - могут настраиваться. Вследствие этого, даже если устройства в системе очень слабые, сеть можно подстроить под конкретную среду исполнения.
Смысл в уникальных возможностях никуда не исчезает - даже при таких атаках всегда будет существовать прослойка специфичного прикладного применения. В некоторых случаях защититься от кого-угодно легко просто использованием секретного сетевого ключа. В других случаях уже приходиться ухищряться и разделять сеть на множество подсетей, чтобы атакующему необходимо было совершать больше вычислений.
Помимо этого, сеть Hidden Lake не является монолитным решением подобно сетям Tor и I2P. Напротив, сеть HL спроектирована таким образом, чтобы она умела разворачиваться почти что в любой сетевой среде - в локальной или глобальной, в централизованной или децентрализованной, с минимальным количеством условий. Это становится определённого рода компенсацией в обмен невозможности успешного масштабирования. Таким образом, создаётся ситуация при которой сеть может как быстро падать, так и быстро восстанавливаться из-за своей специфичной автономности.
Отсечение пакетов происходит только на уровне дедупликации, в остальном никаких механизмов противодействия перегрузкам излишним трафиком нет. Если система будет масштабироваться, то каждый узел будет принимать от неё всё больше трафика. Постепенно это будет приводить к отсеканию наиболее слабых узлов от сети, неспособных своевременно редиректить и дешифровывать трафик. Вследствие этого, сеть действительно будет способна работать только в пределах малых групп, например 50-100 узлов (в зависимости от их мощностей).
Хорошо, ретранслятор - а как его найти в сети? Должен быть тогда какой-то список...
Да, конфигурационные файлы с указанными ретрансляторами можно найти тут: _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. В таком случае, для последующего успешного общения должен быть выбран один из них.
В сети 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).
Основная особенность сети заключается в том, что для сторонних узлов и наблюдателей задача выявления факта отправления или получения сообщений является вычислительно сложной вне зависимости от количества участников в сети и их связей между друг другом.
Легитимно - (в юридическом смысле этого слова) может быть (и то случаются натяжки), сквозное ли это шифрование - точно нет. Суть E2E шифрования в том, что оно должно протягиваться до конечных точек, в мессенджерах конечные точки - это друзья, с которыми ты общаешься, это группы, ленту которых ты просматриваешь и т.д., но точно не сам сервис. Такой же принцип с маркетплейсами, конечная точка - это продавец, а не сам сервис. Такой же принцип с электронной почтой, конечная точка - это получатель письма, а не сервис электронной почты. И т.д., и т.п. ...
Это не E2E шифрование, а обычное, что ни на есть, клиент-серверное шифрование, где безопасная коммуникация строится только от клиентов к серверу, а не от клиентов к клиентам.
...
То-есть, ВКонтакте, Одноклассники, Ozon, WB, Mail.ru и прочие - это всё примеры сервисов со сквозным шифрованием, где даже сам сервис не знает что вы отправляете, что вы покупаете, что вы просматриваете?
Скорее всего вы просто не разобрались в теме, либо ещё проще - воспользовались нейросетью, чтобы она сказала, что есть такое сквозное (E2E) шифрование.
При этом, я не говорю, что централизованные сервисы вовсе бесполезны в концепте E2E шифрования. Так например, я могу обменяться лично публичным ключом со своим другом, а далее использовать ВКонтакте, как платформу, для обмена шифртекстами. В этом случае у нас создаётся действительно сквозное шифрование - шифрование, при котором только истинный собеседник получает открытый текст. Все промежуточные узлы, начиная от провайдеров связи и заканчивая централизованными сервисами - получают лишь шифртекст. И как видно, HTTPS здесь вообще никакой роли не играет, даже если бы использовался голый HTTP, сквозное шифрование оставалось бы нетронутым.
Ничего общего с одноразовым блокнотом это не имеет. В ссылке, в которой вы же указываете, есть точные критерии, как минимум - условие истинной случайности. Если таковой нет, то ни о каком одноразовом блокноте уже и не стоит говорить. В ином случае, мы так и поточные шифры легко сможем сравнять с одноразовыми блокнотами.
Идентификатор позволяет определить личность ровно настолько же насколько позволяет в SimpleX определить эту же самую личность "временные анонимные парные идентификаторы очередей сообщений", которыми клиенты обмениваются. Иными словами, как бы мессенджер не говорил об отсутствии идентификации, но сделать его безопасным, без какой бы то ни было идентификации, - невозможно. Либо мы шифруем сообщения и априори добавляем в схему методы аутентификации (и как следовательно идентификации), либо мы вообще не шифруем сообщения.
На счёт не шифрования сообщений - не всё так безрассудно, как может показаться на первый взгляд, потому как анонимность != безопасность. Так например, DC-сети (сети на базе проблемы обедающих криптографов) вообще не шифруют сообщение как таковое, а просто отправляют его всем узлам в сети, но при этом, анонимность близка к идеальной (в плане сетевого распространения сообщений), т.к. скрывает источника (отправителя) информации с хорошими гарантиями.
Вот это вообще бомба. В двух из трёх вами описанных мессенджерах фактически реальная анонимность формируется не за счёт архитектурных решений, принятых разработчиками, а за счёт использования уже готового решения в лице Tor'а. А в третьем мессенджере так вообще не понятно за счёт чего формируется хоть какая-то анонимность. SimpleX и Technitium Mesh без Tor'a нельзя было бы назвать анонимными мессенджерами, их можно было бы просто относить к мессенджерам по типу Signal или Telegram (с секретными чатами). Т.е. вся их фича анонимности в большей мере лежит на сторонней технологии, а не на их изобретённых новшествах. Они архитектурно безопасны, но их анонимность достигается не за счёт них самих.
Основная суть анонимности - это скрывать связь между множеством отправителей и получателей от множества наблюдателей. Отсутствие идентификаторов - решающей роли в этом не играет, Непонятно как все эти описанные мессенджеры скрывают связь между реальным отправителем и реальным получателем, если вдруг каким-то образом их сервера или узлы захватит наблюдатель, или если таковой наблюдатель вообще будет глобальным. Tor - даёт определённый спектр решений и некоторые гарантии, а также ограничения. SimpleX, Technitium Mesh и BeProg (в чистом виде) - не дают гарантий вовсе.
Я отрицательную оценку не ставил, но пробелы в повествовании всё же есть:
1.
Чтобы этого не было, используется как раз вектор инициализации. В статье про его предназначение особо ничего не сказано, кроме того, что он опционален, хотя на деле - скорее обязателен, потому как, действительно, его отсутствие приводит к описанной вами проблеме.
Из этого также вытекает теперь и то, что одинаковый минус, приписанный к CBC, CFB, OFB, по поводу малого изменения данных в середине или конце открытого текста, просто исчезает.
2.
В определении "шифратора", алгоритм дополнения кажется излишним. И действительно, в поточных режимах по типу OFB, CTR, а также "полу-поточном" CFB - алгоритма дополнения нет вовсе.
Плюс к этому, режимы шифрования, базируемые на дополнении (как пример, CBC), могут обладать также интересным вектором атак с оракулом. Было бы неплохо этот пункт внести как минус или предупреждение.
3.
Ничего также не сказано о минусах поточных режимов шифрования по типу CTR, OFB, а именно - что если мы будем использовать один и тот же ключ шифрования с идентичным вектором инициализации / счётчиком? В таком случае, мы сможем вообще удалить ключ шифрования: (m1 xor k) xor (m2 xor k) = m1 xor m2, что является серьёзной уязвимостью, если не противодействовать повторениям.
UPD. Визуально всё же OFB больше похож на CBC, чем CTR.
UPD. Также почему-то в CTR счётчик стал просто вектором инициализации, хотя это уже не инициализация, раз таковая применяется в каждом блоке шифрования. Плюс к этому у счётчика в CTR - два параметра: константное (сеанс связи) и переменное (сам счётчик) значения. В статье об этом также ничего не сказано.
Вопрос действительно интересный, т.к. основная проблема перехода - это потеря идентификации узлов. Если это система по типу криптовалют, где всё держится на подобного рода идентификации - необходимым условием становится связывание ключей, где ключ RSA подписывает ключ ML-DSA, а ML-DSA - ключ RSA. Соответственно в логике криптовалют / блокчейна должны будут храниться два ключа с последующей возможностью их валидации. Если RSA ещё не взломан, он вполне себе может подтверждать идентификацию участника через ML-DSA какое-то время. Этого времени должно быть достаточно ровно настолько, чтобы оставшиеся узлы смогли перейти на подтверждённый ML-DSA ключ, а RSA ключ воспринять как Deprecated. Таким образом, предполагается, что до создания мощного квантового компьютера состояние Deprecated сможет перейти в состояние Forbidden, а все действия, что происходили с RSA ключом в виде хеша будут сохранены в состоянии под ML-DSA подписью.
С анонимными сетями ситуация немного упрощённее, т.к. не требуется хранить состояние, плюс к этому не все анонимные сети в равной степени будут сложнопереносимы. Как пример, для сети Tor переход на постквантовые алгоритмы будет более простым, чем для I2P, т.к. бОльшая часть коммуникаций связана у него всё же с открытым Интернетом, а не внутренними Hidden Services. Что касается Hidden Lake, то тут ситуация ещё проще, потому как: 1) у HL нет какой-то одной глобальной сети, в отличие от Tor или I2P, вследствие чего одна сеть может работать на RSA, другая - на ML-DSA, 2) HL работает с малыми группами узлов, а потому обновить их будет чисто количественно проще, 3) HL не настолько популярна как Tor, I2P, поэтому радикальные обновления можно делать более смело.
Что касается Hidden Lake, как концепта - год назад сеть таковой действительно являлась, сейчас уже скорее нет, чем да, т.к.: 1) сеть вполне успешно функционирует, ретрансляторы запущены и распределяют / сохраняют шифртексты, 2) исследовательские работы написаны, рассмотрены пределы сети, её достоинства и уязвимости, 3) основная часть кода, связанная с анонимностью и безопасностью, покрыта тестами более чем на 98% (пакет go-peer).
По умолчанию маскировка пакетов отсутствует. Так например, при подключении к готовым ретрансляторам можно достаточно легко определить принадлежность трафика к анонимной сети: 1) сообщения генерируются каждые 5 секунд, 2) размер каждого сообщения равен 8KiB, 3) каждое сообщение отправляется по TCP вида len(c) || c, где c - шифртекст, len - размер сообщения, 4) каждое сообщение ретранслируется на всех участников.
Но на самом деле не всё так мрачно, т.к вышеописанный паттерн - это лишь один из способов запуска. Период генерации в HL может становиться динамичным (параметр rand_queue_period>0), размер сообщения может быть варьируемо-случайным (параметр rand_message_size_bytes>0), сообщения могут передаваться по другим протоколам, например HTTPS (фича с len - специфика только при сырых TCP соединениях), за счёт использования адаптеров.
QR-коды не криптография и не инфобез
Административного бремени и в современном мире предостаточно )
С HTTPS здесь очень мало схожего, разве что есть асимметричный алгоритм, и на этом собственно все схожести заканчиваются.
Не придётся, ноды могут быть несвязаны между собой вовсе асимметричными ключами. Если существует три узла, то может существовать вероятность того, что только два узла всегда коммуницируют между собой, в то время как третий постоянно генерирует ложный трафик и не знает публичные ключи других узлов.
Расшифровка линейна (от количества участников в сети), но точно не экспонциональна.
Хаб криптография и тег шифрование - лишние.
Анонимность QB-задачи в скрытии факта общения. Наблюдателям сложно определить состояние анализируемого узла: отправляет ли он какие-нибудь сообщения, принимает их или вовсе бездействует. Вследствие этого, становится сложно определить существование реальной коммуникации между несколькими узлами.
Ассемблер на интерпретаторе JS-кода - это и вправду ноу-хау, потому что смысла в этом = 0.
AsmX подходит под данное определение? Вопрос конечно риторический. С учётом того, как автор данной статьи восхищается AsmX - не удивлюсь, что он есть также и автор данного ассемблера. Более подробно про AsmX можно почитать в статье: Обзор языка программирования AsmX.
Вы разбираете крайние случаи, что с одной стороны, что с другой. Помимо двух этих сторон могут существовать и вполне благоприятные условия среды, когда сеть не перегружена, но присутствует хотя бы несколько узлов.
Отсечение паразитного трафика скорее вряд-ли, если роутер специально не был на это настроен. По поводу выхода из строя (в плане корректной работоспособности) - может, если пакеты будут сильно большими или если будет много пакетов сумма которых будет превосходить лимит выставленный провайдером связи (мбит/с, гбит/с). Для текущей настройки сети HL размер пакета равен 8КиБ. Каждый узел генерирует его раз в пять секунд, т.е. в секунду будет генерироваться ~1.6КиБ. При редиректах данный пакет может возвращаться отправителю, предположим, что в худшем случае будет в секунду генерироваться ~3.2КиБ/с или ~25.6 кбит/с. Чтобы перегрузить роутер с лимитом в 100мбит/с потребуется примерно 4000 узлов, что скорее всего никогда не произойдёт, т.к. процессорные мощности закончатся раньше.
Не настолько сеть требовательна, чтобы собирать топовое железо. Основные затраты узла, при небольшой группе участников, заключаются в генерации трафика с его же стороны, т.к. используется PoW. Попытка расшифрования сообщений занимает меньше ресурсов. Только когда увеличивается трафик, тогда количество ресурсов на расшифрование трафика начинает превосходить затрачиваемые ресурсы на PoW.
Также, из-за относительной автономности сети, такие параметры как: длина ключа, сложность работы и период генерации сообщений - могут настраиваться. Вследствие этого, даже если устройства в системе очень слабые, сеть можно подстроить под конкретную среду исполнения.
Смысл в уникальных возможностях никуда не исчезает - даже при таких атаках всегда будет существовать прослойка специфичного прикладного применения. В некоторых случаях защититься от кого-угодно легко просто использованием секретного сетевого ключа. В других случаях уже приходиться ухищряться и разделять сеть на множество подсетей, чтобы атакующему необходимо было совершать больше вычислений.
Помимо этого, сеть Hidden Lake не является монолитным решением подобно сетям Tor и I2P. Напротив, сеть HL спроектирована таким образом, чтобы она умела разворачиваться почти что в любой сетевой среде - в локальной или глобальной, в централизованной или децентрализованной, с минимальным количеством условий. Это становится определённого рода компенсацией в обмен невозможности успешного масштабирования. Таким образом, создаётся ситуация при которой сеть может как быстро падать, так и быстро восстанавливаться из-за своей специфичной автономности.
Отсечение пакетов происходит только на уровне дедупликации, в остальном никаких механизмов противодействия перегрузкам излишним трафиком нет. Если система будет масштабироваться, то каждый узел будет принимать от неё всё больше трафика. Постепенно это будет приводить к отсеканию наиболее слабых узлов от сети, неспособных своевременно редиректить и дешифровывать трафик. Вследствие этого, сеть действительно будет способна работать только в пределах малых групп, например 50-100 узлов (в зависимости от их мощностей).
Да, конфигурационные файлы с указанными ретрансляторами можно найти тут: _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. В таком случае, для последующего успешного общения должен быть выбран один из них.
del
В сети Hidden Lake существует фактически два уровня маршрутизации: сетевой и криптографический.
Сетевой уровень работает с идентификацией по IP адресам, где могут быть указаны как ретрансляторы, так и непосредственно полноценные узлы, через которые трафик будет транспортироваться. При этом каких-либо отличий узлов от ретрансляторов на данном уровне маршрутизации нет, т.к. главная его цель - просто распространить сообщение по всем узлам в сети без знания того является ли сообщение истинным или ложным. Иными словами, для распространения сообщений используется заливочная маршрутизация.
Истинная же маршрутизация начинает выстраиваться лишь на криптографическом уровне, когда происходит отправление сообщений с использованием публичных ключей. Если узел получает шифрованное сообщение из сети, но при этом оно не расшифровывается его приватным ключом, то это означает, что сообщение было отправлено не ему. Если же узел смог успешно расшифровать принятое сообщение из сети, то значит, что сообщение было назначено конкретно ему.
Обмен публичными ключами и дальнешая их установка должна осуществляться вне сети Hidden Lake. Это может быть как физический обмен ключами, так и обмен ключами посредством например такого протокола. В HL можно также и отключить опцию F2F, прописав в настройках конфига строчку f2f_disabled: true, но я бы не стал такого делать из-за возможности спама, а также возможных активных наблюдений за состоянием очереди, хоть это в сумме и упростит дальнейшую коммуникацию.
Подключаться можно к ретрансляторам или к уже существующим узлам с внешним адресом. Все такие подключения будут происходить на сетевом уровне, а потому выстраиваемая топология никак не будет приводить к раскрытию информации об общении узлов. Наблюдателю будет доступна лишь информация об участниках сети, т.е. информация об их факте подключения к сети. Информация же о каком-либо факте отправления или получения сообщений будет для него недоступна. Если необходимо скрывать также и принадлежность участников к сети, то можно это сделать посредством сокрытия / инкапсуляции анонимизированного трафика в HTTPS (адаптеры), выстраиванием динамических периодов (rand_queue_period_ms>0) и размеров сообщений (rand_message_size_bytes>0).
Возможно вы правы, т.к. при написании мной был поставлен больше упор именно на запуск узла. Добавил спойлер «Немного о QB-задаче».
Основная особенность сети заключается в том, что для сторонних узлов и наблюдателей задача выявления факта отправления или получения сообщений является вычислительно сложной вне зависимости от количества участников в сети и их связей между друг другом.