Я отрицательную оценку не ставил, но пробелы в повествовании всё же есть:
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).
Основная особенность сети заключается в том, что для сторонних узлов и наблюдателей задача выявления факта отправления или получения сообщений является вычислительно сложной вне зависимости от количества участников в сети и их связей между друг другом.
Насколько знаю большинство современных алгоритмов цифровой подписи базируются на схеме Эль-Гамаля, в который по умолчанию закладывается механизм удвоения размера выходных данных. Для сохранения 128-битной безопасности используют 256-битный ключ, который, в свою очередь, уже генерирует 512-битные подписи (тобишь 64 байта). Насколько знаю на практике также часто могут применяться эллиптические кривые 224-битные, которые могут создавать подписи размером 56 байт. Но они, в свою очередь, придерживаются минимальной планки безопасности в 112-бит, что может быть опасным при долгосрочном использовании.
NIST: сравнительная характеристика длин ключей при лобовой атаке
Было бы интересно подобное разобрать, но при написании статьи потеряется особенность, которая ранее содержалась в алгоритме RSA, - обманчивая простота. В криптографии на эллиптических кривых такой обманчивости мало, и как следствие, описание самих атак станет более изощрённым занятием. Поэтому схожего разбора эллиптических кривых мной пока не планируется, но не буду говорить и о том, что такого разбора не будет вовсе. Скорее всего будет, просто в другой оболочке.
Я отрицательную оценку не ставил, но пробелы в повествовании всё же есть:
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-задаче».
Основная особенность сети заключается в том, что для сторонних узлов и наблюдателей задача выявления факта отправления или получения сообщений является вычислительно сложной вне зависимости от количества участников в сети и их связей между друг другом.
Насколько знаю большинство современных алгоритмов цифровой подписи базируются на схеме Эль-Гамаля, в который по умолчанию закладывается механизм удвоения размера выходных данных. Для сохранения 128-битной безопасности используют 256-битный ключ, который, в свою очередь, уже генерирует 512-битные подписи (тобишь 64 байта). Насколько знаю на практике также часто могут применяться эллиптические кривые 224-битные, которые могут создавать подписи размером 56 байт. Но они, в свою очередь, придерживаются минимальной планки безопасности в 112-бит, что может быть опасным при долгосрочном использовании.
Было бы интересно подобное разобрать, но при написании статьи потеряется особенность, которая ранее содержалась в алгоритме RSA, - обманчивая простота. В криптографии на эллиптических кривых такой обманчивости мало, и как следствие, описание самих атак станет более изощрённым занятием. Поэтому схожего разбора эллиптических кривых мной пока не планируется, но не буду говорить и о том, что такого разбора не будет вовсе. Скорее всего будет, просто в другой оболочке.
Дежавю недельной выдержки?