Такое равенство "3250000= 5416" вы выдумали? 3250000 способны сгенерировать блок за 1 секунду, если будут его генерировать с равными мощностями. 5416 есть уже количество ASIC'ов растянутое на 10 минут. Иными словами, такое количество сможет найти блок примерно через 10 минут от старта вычислений.
Да, до тех пор пока существуют устройства, на которые были потрачены реальные трудозатраты и стоимости, они должны в конечном счёте хотя бы окупить вложения.
Безусловно 1 секунда будет непозволительна майнингу в концепции сети Bitcoin с учётом текущих ресурсов. Если бы такое произошло, сеть бы со временем повысила сложность вычислений. Но тут нет никаких противоречий, чтобы буквально "растянуть" вычислительную производительность на более долгое время, уменьшая при этом количество самих устройств.
В составе AsmX присутствует мини-операционная система под названием AsmX OS. Следует отметить, что данная ОС не является полноценной и предназначена для специфических задач.
Ни в каком смысле этого слова данное приложение просто не может считаться какой бы то ни было ОС. Это обычное консольное приложение, запускаемое в уже существующей ОС, которое поддерживает JS и ноду. И непонятно где вы использовали AsmX при написании даже этой "ОС". Всё что я вижу - это голый JS.
Хакатон закончился, подводим итоги. Активно участвовало в хакатоне буквально пару человек. С одной стороны это хорошо, если мы говорим о вознаграждении, с другой стороны это плохо, когда мы говорим о поиске уязвимостей. Но так или иначе, вознаграждения вполне честные и заслуженные. Чтобы не раскрывать имена/фамилии или какие-либо другие персональные данные, я попросил у участников никнеймы.
Первое место - TeaRot (73.334 рублей)
Второе место - vectorABY (51.666 рублей)
Найденные уязвимости/баги были следующие:
[TeaRot] Атака двух друзей HLM<->HLS.
Когда пользователь авторизуется в HLM он расшифровывает приватный ключ посредством ввода логина и пароля. Далее этот приватный ключ он отсылает к HLS. И начиная с этого момента, чтобы совершать последующие действия (например отправка/получение сообщений для внесения в БД) HLM всегда запрашивает у HLS публичный ключ. Это может привести к следующему сценарию:
HLM отправляет приватный ключ к HLS
HLM запрашивает в N-ом действии свой публичный ключ от HLS (подразумивая, что этот публичный ключ от переданного им ранее приватного ключа)
HLS отправляет к HLM совершенно иной публичный ключ, и совершает анонимизацию под совершенно другим приватным ключом
Протокол анонимизации работает всегда корректно, но сам пользователь под HLM фактически находится под другим аккаунтом.
Эксплуатировать уязвимость можно таким образом:
Существует три пользователя и две связи друзей: A <-> B, B <-> C, то есть B общается сразу с двумя друзьями.
Злоумышленник, располагая скомпромитированными приватными ключами A и C, может их поменять местами, и фактически пользователь A будет общаться за C, а C за A.
Также такой сценарий возможен не только в эксплуатации уязвимости, но и при неявном/неправильном проектировании других прикладных приложений вместе с HLM. Так например, если оба приложения имеют авторизацию, то одно из таковых приложений может сменить приватный ключ, и тем самым другое приложение уже не будет работать корректно.
Решением здесь является следующее:
Если авторизация находится на стороне прикладного приложения, то следует проверять публичный ключ, который перешёл от HLS с публичным ключом (полученным из расшифрованного приватного при авторизации). Таким образом, мы исключаем атаку выдачи некорректного публичного ключа.
Использовать промежуточный сервис, который бы отвечал за авторизацию всех прикладных приложений (такая идея у меня ранее действительно уже присутствовала). В таком случае не будет возникать события, когда несколько прикладных приложений перекрывают друг друга.
[TeaRot] Атака двух друзей HLM<->HLT.
Когда HLM запрашивает у HLT сообщения, то для начала HLM скачивает их хеши. Далее по запросам на хеши HLM получает от HLT сообщения и перенаправляет их к HLS. Тем не менее, HLM не проверяет целостность самого сообщения, а именно не сравнивает хеш предполагаемый и хеш получаемый. В таком сценарии, HLT может выдавать случайные хеши, но при этом всегда отсылать только конкретные сообщения.
В большей мере это не уязвимость, т.к. здесь эксплуатация может сводиться лишь к неправильно принятым сообщениям, либо сообщениям которые мы уже много раз получали. В таком сценарии HLS просто проигнорирует всё, что получит.
[TeaRot] Неправильное/невалидное API HLS, HLT.
Это уже конечно не уязвимость, но правильное замечание. Редактируя HLS, HLT иногда я забывал редактировать соответствующую документацию по API.
[TeaRot] Всегда в ответах: text/plain;
Это тоже из разряда бага/неправильного проектирования. Суть заключается в том, что HLS, HLT отправляют всегда ответы с text/plain форматом, даже если результатом их ответов является JSON. В итоге, браузеры, постман и прочие могут некорректно отображать сами результаты (в виде обычного текста, без структуризации).
Когда HLM отправляет или получает сообщения, то таковые сообщения переходят или приходят от HLS непосредственно в открытом виде. Иными словами, безопасная коммуникация наблюдается лишь и только между двумя HLS, но не между двумя HLM. Более кратко это можно описать так: HLM -- [незашифрованное сообщение] --> HLS -- [зашифрованное сообщение] --> HLS -- [незашифрованное сообщение] --> HLM.
Но связь между HLM и HLM вполне можно сделать защищённой от HLS, т.к. HLM уже знает кому надо отправить сообщение или от кого она получает сообщение (т.к. HLS говорит об отправителе). Таким образом, HLM может зашифровать сообщение, передать его к HLS, тот в свою очередь преобразует данное сообщение в анонимизирующий трафик, передаст его другому HLS, а тот в свою очередь снимет анонимизацию и передаст к HLM зашифрованное сообщение, которое впоследствии будет расшифровано.
Иными словами, благодаря этому хаку мы уменьшаем уровень доверия к самому HLS, а также к потенциальному пассивному наблюдателю (в роли шпиона), находящимся на устройстве.
Тем не менее, решить данную проблему сложнее чем кажется. Суть заключается в том, что HLM работает по принципу HTTP-сервера, где сами же данные адресуемые от интерфейса к HLM незашифрованы. Эту проблему можно исправить, если создать приложение самодостаточное - либо десктопное, либо мобильное.
[vectorABY] Некорректное вычисление статичного размера сообщений в pkg/client.
Баг, в том плане, что некоторые байты при вычислении статичного размера сообщения мы просто не могли использовать.
Большая часть моментов уже была исправлена, а именно:
Атака двух друзей HLM<->HLS (с авторизацией внутри HLM, нужно будет также сделать авторизацию через отдельный сервис)
Атака двух друзей HLM<->HLT
Неправильное/невалидное API HLS, HLT
Всегда в ответах: text/plain
Небезопасное отправление/получение сообщений HLM<->HLM (ЧАСТИЧНО! т.к. HLM не был переведён на десктоп/мобильное приложение)
Некорректное вычисление статичного размера сообщений в pkg/client
Нужно также ещё понимать, что ChaCha20 - это представитель поточных алгоритмом шифрования в которых генерация гаммы оторвана от шифруемого сообщения, и проблемой которых всегда является необходимость учитывать неповторяемость гаммы за счёт неповторяемости Nonce или ключа (как в RC4). В это же время, блочные алгоритмы более гибки в своей настройке за счёт режимов шифрования, хоть и в большинстве случаев менее производительны. И за счёт режимов, как пример, CBC, CFB, отпадает необходимость учитывать Nonce. Вполне достаточным остаётся использование случайного вектора инициализации. И даже если таковой повторится, то проблема сведётся к режиму ECB (с определённо установленным IV), а не к полной дешифровке нескольких сообщений.
ECDiffieHellmanCng - это протокол Диффи-Хеллмана на эллиптических кривых, созданный для распределения ключей, а далее используемый симметричными шифрами. Я же говорю конкретно про шифрование без участия каких бы то ни было симметричных алгоритмов.
TLS и является гибридным, я же писал - ассиметричные ключи для аутентификации, симметричное шифрование.
Я не про TLS говорю, а про то, что не существует какой бы то ни было программной реализации асимметричного алгоритма на базе EC, который мог бы самодостаточно (без какого-либо симметричного алгоритма) шифровать информацию и был бы при этом проверенным как временем, так и криптографами потратившими своё время на его анализ.
Тобишь моральное устарeвание означало бы, что всё что есть у RSA - уже давно есть у EC. А я говорю, что шифрования в EC на уровне программной реализации так и не завезли и поэтому вряд-ли можно говорить о каком-либо устаревании до тех пор, пока не будет аналогов. В этом был мой тезис.
Самый популярный ассиметричный алгоритм - RSA, но при этом - морально устаревший. На эту тему есть замечательная статья Хватит использовать RSA от @Scratch. Для генерации ключей рекомендуют использовать 2048-bit RSA или 256-bit ECDSA. Но ECDSA - быстрее и размер ключа меньше.
Это всё хорошо, но покажите мне стандартизированную и проверенную временем/криптографами программную реализацию ECIES на любом языке программирования, которой люди могли бы пользоваться как RSA для шифрования сообщений. Всё, что я видел - так это ECIES созданный в кустарных условиях.
Тут например, люди используют ECDH при помощи openssl для генерации сеансового ключа, а только потом его используют в качестве входа в AES для последующего шифрования, что является гибридной схемой шифрования, но не асимметричным шифрованием.
Одно дело говорить, что RSA - морально устарел, а другое дело - это реальность, когда не существует аналога к RSA на основе эллиптических кривых, который можно было бы легко и безопасно использовать (шифровать/расшифровывать информацию) в качестве уже готовой реализации.
Статья понравилась, но есть всё же небольшой комментарий:
Законы Природы применимы для любой предметной области, в том числе и для информационной безопасности. На протяжении длительного времени можно наблюдать эволюцию и совершенствование технологий и инструментов защиты, а также техник, тактик и процедур злоумышленников. В ответ на брошенный киберпреступниками вызов развиваются приемы обороны и отражения атак. Мы наблюдаем непрекращающееся противостояние и взаимное развитие сторон.
Это не законы Природы, а всё же диалектические законы, если их так можно назвать.
Так например, при законе единства и борьбы противоположностей, атакующие и защищающие, являясь с одной стороны противоположностями друг к другу, начинают дополнять друг друга, если мы рассматриваем их действия в движении, а не в застывшей форме. Как пример, на ранних этапах, на краткосрочных перспективах атакующие производят свои атаки, например, с целью заработка, разрушая и деструктуризируя безопасность, в то время как уже в долгосрочных временных интервалах их действия наоборот рассматриваются не как со стороны последующих атак, а как со стороны их предотвращения. В конечном итоге, система защиты начинает залатывать дыры за счёт своего нападения, и тем самым, развивается.
Это же явление можно рассматривать также и со стороны закона отрицание отрицания, когда атакующий, начиная отрицать систему безопасности, порождает из первичного тезиса (системы) его антитезис (взломанную систему). Отрицая далее антитезис (в котором уже содержится сам тезис) мы находим сходства и различия обеих систем, порождая из них синтез (безопасную систему). И на этой же модели триады тезис-антитезис-синтез мы далее видим закон перехода количественных изменений в качественные, где ряд, массовость и количественность таковых атак приводит к формированию качества самих систем, повышающих при каждой новой атаке планку информационной безопасности.
Отличием законов Природы от диалектических законов является то, что при рассмотрении законов Природы мы проводим связи и ассоциации с информационной безопасностью, в то время как диалектика уже представляет общий метод познания движения и развития. Иными словами, диалектике нет надобности создавать дополнительные связи и ассоциации, потому как диалектика и есть их описание. Вследствие этого, при помощи диалектики, мы можем описывать не только законы Природы, но и всё, что имеет движение, развитие. В то время как законы Природы всё же не способны описывать любое движение, например развитие Физики сложно как-то описать законами Природы, орудуя такими терминами как гомеостаз, адаптация, иммунитет, эпидемия и прочее.
Поддерживаются основные примитивы системного программирования, необходимые для криптографии, в том числе генератор случайных чисел. Например, через Math.random()
Что? Math.random - это ГПСЧ, а не КСГПСЧ.
Note:Math.random()does not provide cryptographically secure random numbers. Do not use them for anything related to security. Use the Web Crypto API instead, and more precisely the window.crypto.getRandomValues() method.
Генерация большого количества дополнительного «мусорного» трафика, замаскированного под полезный в случайные моменты времени.
Необязательны случайные моменты времени. На самом деле, наиболее эффективная (со стороны теоретически доказуемых моделей) анонимизация трафика проводится, как бы это не звучало парадоксально, за счёт детерминированности отправления и получения сообщений, а не их хаотичности. Например, DC-сети (проблема обедающих криптографов) и QB-сети (модель очередей, как пример тут) базируются как раз на таковых принципах.
Чем не зашёл метанит для освоения таких базовых вещей? Возможно это моё субъективное мнение, но основы языка Go можно буквально на каждом ресурсе найти по программированию.
Помним, что мы строим сеть в которой есть дядя, который может принудить делать все УЦ всё что угодно.
Пропустил это. Да, если сами центры сертификации начнут подменять все запросы, то данный метод становится бессильным. Но, по моиму субъективному мнению, такая кооперация и ЦС, и сервисов связи является достаточно сложной, потому как требуется не только подменить сертификат на стороне ЦС, но и перенаправлять все запросы на внешне похожие сервисы связи, или на оригинальные сервисы, с учётом того, если они смогут корректно воспринимать подменённый сертификат от самого ЦС.
Откуда им взяться в сети с глобальным наблюдателем?
Глобальный наблюдатель здесь и не фигурирует. Суть заключается в том, что идентификация любого рода, будь то знание публичного ключа или знание сетевого адреса не приведёт к деанонимизации самих действий в анонимной сети. Будет ровно такая же сложность обнаружения действий пользователя.
Причём забавно, что чем больше мы этих сервисов добавляем, тем сложнее становится алгоритм консенсуса "а кому из них мы можем доверять". Любой скомпроментированный УЦ автоматически ложит нам вообще всю сеть. Ну такое.
Алгоритм можно изменить на доверие к N-ому количеству сервисов из множества представленных. Сам алгоритм является вероятностным в любом случае, поэтому здесь оперируем лишь количественными характеристиками.
> Причем интересно то, что пользователям предлагается обменяться публичными ключами самостоятельно, что на самом эквивалентно обмену симметричными ключами и сводит весь смысл использования ассиметрии к нулю.
>> Не сводит. Как минимум асимметричная криптография защищает от пассивных атак злоумышленника, что нельзя сказать о симметричной криптографии.
Почему нельзя сказазать этого о симметричной? Откуда такой вывод 0_o?
Я говорил в контексте обмена ключами асимметричной и симметричной криптографий. При симметричной криптографии обмен ключами легко может привести к пассивным атакам на обычный их перехват, что нельзя сказать об асимметричной криптографии, где действуют лишь активные атаки на перехват ключей.
В принципе, как и симметричные, только в отличии от ассиметрии вообще не проблема обменяться энтропией при встрече хоть до конца жизни. В принципе, как и публичных ключей можно выдать хоть 100500 штук сразу, что опять же вызывает вопросы: нафига нам ассиметрия?
Как минимум простота обмена ключами: N(N-1)/2, вместо 2N, и существование идентификатора со связью 1 (публичный ключ) ко многим абонентам, а не 1 (сеансовый ключ) к одному абоненту.
Да - это сузит область прослушивания для глобального наблюдателя, но это не решит его проблему - он всё также не сможет определить кто из этих 100 получателей мой целевой.
Совершенно верно. Подобного же принципа придерживается сеть Herbivore, разделяющая участников сети по группам. Тем не менее у такого принципа есть нюанс в плане того, что децентрализованные сети сами по себе являются динамичными структурами. Если будут существовать в сети статичные узлы, то вероятность того, что пользователь общается именно с ними будет стремиться к нулю. Если общение двух абонентов частое, то из всего множества N=100 можно со временем по крупицам убирать узлы, которых ранее не существовало и оставлять только тех, которые до сих пор активно работают. В таком случае, будет существовать вероятность, при которой N будет стремиться к единице за счёт продолжительной связи между двумя абонентами. Когда же мы в качестве N берём все узлы в системе, такого уже не будет возникать.
Ассиметричная криптография сама по себе подтверждена MITM атакам и требует наличия полноценной инфраструктуры PKI (УЦ, CRL и вот это всё). При наличии глобального наблюдателя - анонимность слили в мусор. Наличие УЦ - это точки доверия, а значит анонимность в мусор.
В статье об этом говорится и о решении тоже:
Необходимо, чтобы все пользователи обменялись своими публичными ключами. Данное обстоятельство также может быть проблемой, потому как публичный ключ может быть подменён извне. Из-за децентрализованного характера сети, не допускается использование центров сертификации (ЦС). Тем не менее, можно воспользоваться N-ым количеством централизованных сервисов явно не связанных между собой для безопасной передачи публичных ключей.
---
Есть всего два вменяемыхсценария распределения ключей - это квантовое распределение ключей (менее надёжно)
Как вы защититесь от централизованных сервисов, которые и являются фактическими конечными получателями всех сообщений? Квантовые технологии лишь укрепят безопасность связи клиент-сервер, но не клиент-клиент.
Причем интересно то, что пользователям предлагается обменяться публичными ключами самостоятельно, что на самом эквивалентно обмену симметричными ключами и сводит весь смысл использования ассиметрии к нулю.
Не сводит. Как минимум асимметричная криптография защищает от пассивных атак злоумышленника, что нельзя сказать о симметричной криптографии. Данное свойство как раз и позволяет использовать множество централизованных сервисов для обмена публичными ключами. Если бы мы передавали симметричные ключи, то их можно было бы напрямую использовать без явной подмены.
Также надо помнить, что существует такая вещь, как "нагрузка на ключ", т.е. мы не можем передавать на одном ключе слишком много информации, т.к. каждый отправленный бит увеличивает вероятность раскрытия информации. А значит ещё нужно предусмотреть возможность обновления этих ключей...
Факт, только в какой пропорции происходит увеличение вероятности раскрытия информации, сколько потребуется памяти для её осуществления? На сколько знаю такие атаки также являются достаточно трудоёмкими и требуют огромного количества открытых и закрытых текстов для их осуществления. Асимметричные ключи могут жить фактически годами, но да, это не отменяет необходимости их смены/замены.
Если честно, не до конца понял, зачем нам полная связность между узлами. При условии посылки сообщений каждый период T подойдёт в принципе любая топология, вопрос только в скорости передачи.
Совершенно верно. Полная связность необходима лишь для упрощения самого механизма работы, т.к. это исключает маршрутизацию и, как следствие, дополнительный код. Целью статьи являлось, в первую очередь, создание минимальной анонимной сети. Все дальнейшие совершенствования лишь увеличили бы её количество кода. Так например, в основной моей анонимной сети, которую я пишу в свободное время, как раз неважна топология. Но в любом случае, какую бы мы топологию не выбрали, нагрузка на сеть будет всегда линейна. Если бы мы выбрали топологию "Звезда", то от одной точки к любой другой также бы сообщение доходило и также бы обрабатывалось.
И вот тут мы плавно переходим к третьей проблеме: стабильности работы сети. При наличии одного глобального периода Т возникает проблема доверенного источника времени.
Возможно тут я неправильно донёс мысль. В задаче на базе очередей период T выставляется локально и независимо для каждого узла в сети. Иными словами, они не кооперируют с тем, чтобы каждый подстраивался под конкретное время начала генерации. Асинхронность, либо даже изменение выставленного периода T, в сравнении со всеми другими узлами сети, не влияет на качество анонимизации трафика. Тем не менее, период T равный одному и тому же значению для всех узлов в сети как минимум способен приводить к отсутствию чётко заданных групп, которые можно было бы выделять по времени генерации. Поэтому я в описании задачи на базе очередей указывал именно константную T.
Примерно как-то так, надеюсь ответил на все вопросы и замечания.
Тут я согласен. Можно сказать, что 5416 - это идеально возможное количество.
Такое равенство "3250000= 5416" вы выдумали? 3250000 способны сгенерировать блок за 1 секунду, если будут его генерировать с равными мощностями. 5416 есть уже количество ASIC'ов растянутое на 10 минут. Иными словами, такое количество сможет найти блок примерно через 10 минут от старта вычислений.
Электроэнергия была также учтена в расчётах.
Чтобы вычислить материальные трудозатраты для биткоина. Из этого мы видим разницу реально потраченных средств и количество влитого капитала.
Да, до тех пор пока существуют устройства, на которые были потрачены реальные трудозатраты и стоимости, они должны в конечном счёте хотя бы окупить вложения.
Безусловно 1 секунда будет непозволительна майнингу в концепции сети Bitcoin с учётом текущих ресурсов. Если бы такое произошло, сеть бы со временем повысила сложность вычислений. Но тут нет никаких противоречий, чтобы буквально "растянуть" вычислительную производительность на более долгое время, уменьшая при этом количество самих устройств.
Ни в каком смысле этого слова данное приложение просто не может считаться какой бы то ни было ОС. Это обычное консольное приложение, запускаемое в уже существующей ОС, которое поддерживает JS и ноду. И непонятно где вы использовали AsmX при написании даже этой "ОС". Всё что я вижу - это голый JS.
Или всё просто скатится в C++
Хакатон закончился, подводим итоги. Активно участвовало в хакатоне буквально пару человек. С одной стороны это хорошо, если мы говорим о вознаграждении, с другой стороны это плохо, когда мы говорим о поиске уязвимостей. Но так или иначе, вознаграждения вполне честные и заслуженные. Чтобы не раскрывать имена/фамилии или какие-либо другие персональные данные, я попросил у участников никнеймы.
Первое место - TeaRot (73.334 рублей)
Второе место - vectorABY (51.666 рублей)
Найденные уязвимости/баги были следующие:
[TeaRot] Атака двух друзей HLM<->HLS.
Когда пользователь авторизуется в HLM он расшифровывает приватный ключ посредством ввода логина и пароля. Далее этот приватный ключ он отсылает к HLS. И начиная с этого момента, чтобы совершать последующие действия (например отправка/получение сообщений для внесения в БД) HLM всегда запрашивает у HLS публичный ключ. Это может привести к следующему сценарию:
HLM отправляет приватный ключ к HLS
HLM запрашивает в N-ом действии свой публичный ключ от HLS (подразумивая, что этот публичный ключ от переданного им ранее приватного ключа)
HLS отправляет к HLM совершенно иной публичный ключ, и совершает анонимизацию под совершенно другим приватным ключом
Протокол анонимизации работает всегда корректно, но сам пользователь под HLM фактически находится под другим аккаунтом.
Эксплуатировать уязвимость можно таким образом:
Существует три пользователя и две связи друзей: A <-> B, B <-> C, то есть B общается сразу с двумя друзьями.
Злоумышленник, располагая скомпромитированными приватными ключами A и C, может их поменять местами, и фактически пользователь A будет общаться за C, а C за A.
Также такой сценарий возможен не только в эксплуатации уязвимости, но и при неявном/неправильном проектировании других прикладных приложений вместе с HLM. Так например, если оба приложения имеют авторизацию, то одно из таковых приложений может сменить приватный ключ, и тем самым другое приложение уже не будет работать корректно.
Решением здесь является следующее:
Если авторизация находится на стороне прикладного приложения, то следует проверять публичный ключ, который перешёл от HLS с публичным ключом (полученным из расшифрованного приватного при авторизации). Таким образом, мы исключаем атаку выдачи некорректного публичного ключа.
Использовать промежуточный сервис, который бы отвечал за авторизацию всех прикладных приложений (такая идея у меня ранее действительно уже присутствовала). В таком случае не будет возникать события, когда несколько прикладных приложений перекрывают друг друга.
[TeaRot] Атака двух друзей HLM<->HLT.
Когда HLM запрашивает у HLT сообщения, то для начала HLM скачивает их хеши. Далее по запросам на хеши HLM получает от HLT сообщения и перенаправляет их к HLS. Тем не менее, HLM не проверяет целостность самого сообщения, а именно не сравнивает хеш предполагаемый и хеш получаемый. В таком сценарии, HLT может выдавать случайные хеши, но при этом всегда отсылать только конкретные сообщения.
В большей мере это не уязвимость, т.к. здесь эксплуатация может сводиться лишь к неправильно принятым сообщениям, либо сообщениям которые мы уже много раз получали. В таком сценарии HLS просто проигнорирует всё, что получит.
[TeaRot] Неправильное/невалидное API HLS, HLT.
Это уже конечно не уязвимость, но правильное замечание. Редактируя HLS, HLT иногда я забывал редактировать соответствующую документацию по API.
[TeaRot] Всегда в ответах: text/plain;
Это тоже из разряда бага/неправильного проектирования. Суть заключается в том, что HLS, HLT отправляют всегда ответы с text/plain форматом, даже если результатом их ответов является JSON. В итоге, браузеры, постман и прочие могут некорректно отображать сами результаты (в виде обычного текста, без структуризации).
[vectorABY] Небезопасное отправление/получение сообщений HLM<->HLM.
Когда HLM отправляет или получает сообщения, то таковые сообщения переходят или приходят от HLS непосредственно в открытом виде. Иными словами, безопасная коммуникация наблюдается лишь и только между двумя HLS, но не между двумя HLM. Более кратко это можно описать так: HLM -- [незашифрованное сообщение] --> HLS -- [зашифрованное сообщение] --> HLS -- [незашифрованное сообщение] --> HLM.
Но связь между HLM и HLM вполне можно сделать защищённой от HLS, т.к. HLM уже знает кому надо отправить сообщение или от кого она получает сообщение (т.к. HLS говорит об отправителе). Таким образом, HLM может зашифровать сообщение, передать его к HLS, тот в свою очередь преобразует данное сообщение в анонимизирующий трафик, передаст его другому HLS, а тот в свою очередь снимет анонимизацию и передаст к HLM зашифрованное сообщение, которое впоследствии будет расшифровано.
Иными словами, благодаря этому хаку мы уменьшаем уровень доверия к самому HLS, а также к потенциальному пассивному наблюдателю (в роли шпиона), находящимся на устройстве.
Тем не менее, решить данную проблему сложнее чем кажется. Суть заключается в том, что HLM работает по принципу HTTP-сервера, где сами же данные адресуемые от интерфейса к HLM незашифрованы. Эту проблему можно исправить, если создать приложение самодостаточное - либо десктопное, либо мобильное.
[vectorABY] Некорректное вычисление статичного размера сообщений в pkg/client.
Баг, в том плане, что некоторые байты при вычислении статичного размера сообщения мы просто не могли использовать.
Большая часть моментов уже была исправлена, а именно:
Атака двух друзей HLM<->HLS (с авторизацией внутри HLM, нужно будет также сделать авторизацию через отдельный сервис)
Атака двух друзей HLM<->HLT
Неправильное/невалидное API HLS, HLT
Всегда в ответах: text/plain
Небезопасное отправление/получение сообщений HLM<->HLM (ЧАСТИЧНО! т.к. HLM не был переведён на десктоп/мобильное приложение)
Некорректное вычисление статичного размера сообщений в pkg/client
Нужно также ещё понимать, что ChaCha20 - это представитель поточных алгоритмом шифрования в которых генерация гаммы оторвана от шифруемого сообщения, и проблемой которых всегда является необходимость учитывать неповторяемость гаммы за счёт неповторяемости Nonce или ключа (как в RC4). В это же время, блочные алгоритмы более гибки в своей настройке за счёт режимов шифрования, хоть и в большинстве случаев менее производительны. И за счёт режимов, как пример, CBC, CFB, отпадает необходимость учитывать Nonce. Вполне достаточным остаётся использование случайного вектора инициализации. И даже если таковой повторится, то проблема сведётся к режиму ECB (с определённо установленным IV), а не к полной дешифровке нескольких сообщений.
ECDiffieHellmanCng - это протокол Диффи-Хеллмана на эллиптических кривых, созданный для распределения ключей, а далее используемый симметричными шифрами. Я же говорю конкретно про шифрование без участия каких бы то ни было симметричных алгоритмов.
Я не про TLS говорю, а про то, что не существует какой бы то ни было программной реализации асимметричного алгоритма на базе EC, который мог бы самодостаточно (без какого-либо симметричного алгоритма) шифровать информацию и был бы при этом проверенным как временем, так и криптографами потратившими своё время на его анализ.
Тобишь моральное устарeвание означало бы, что всё что есть у RSA - уже давно есть у EC. А я говорю, что шифрования в EC на уровне программной реализации так и не завезли и поэтому вряд-ли можно говорить о каком-либо устаревании до тех пор, пока не будет аналогов. В этом был мой тезис.
Это всё хорошо, но покажите мне стандартизированную и проверенную временем/криптографами программную реализацию ECIES на любом языке программирования, которой люди могли бы пользоваться как RSA для шифрования сообщений. Всё, что я видел - так это ECIES созданный в кустарных условиях.
Тут например, люди используют ECDH при помощи openssl для генерации сеансового ключа, а только потом его используют в качестве входа в AES для последующего шифрования, что является гибридной схемой шифрования, но не асимметричным шифрованием.
Одно дело говорить, что RSA - морально устарел, а другое дело - это реальность, когда не существует аналога к RSA на основе эллиптических кривых, который можно было бы легко и безопасно использовать (шифровать/расшифровывать информацию) в качестве уже готовой реализации.
Статья понравилась, но есть всё же небольшой комментарий:
Это не законы Природы, а всё же диалектические законы, если их так можно назвать.
Так например, при законе единства и борьбы противоположностей, атакующие и защищающие, являясь с одной стороны противоположностями друг к другу, начинают дополнять друг друга, если мы рассматриваем их действия в движении, а не в застывшей форме. Как пример, на ранних этапах, на краткосрочных перспективах атакующие производят свои атаки, например, с целью заработка, разрушая и деструктуризируя безопасность, в то время как уже в долгосрочных временных интервалах их действия наоборот рассматриваются не как со стороны последующих атак, а как со стороны их предотвращения. В конечном итоге, система защиты начинает залатывать дыры за счёт своего нападения, и тем самым, развивается.
Это же явление можно рассматривать также и со стороны закона отрицание отрицания, когда атакующий, начиная отрицать систему безопасности, порождает из первичного тезиса (системы) его антитезис (взломанную систему). Отрицая далее антитезис (в котором уже содержится сам тезис) мы находим сходства и различия обеих систем, порождая из них синтез (безопасную систему). И на этой же модели триады тезис-антитезис-синтез мы далее видим закон перехода количественных изменений в качественные, где ряд, массовость и количественность таковых атак приводит к формированию качества самих систем, повышающих при каждой новой атаке планку информационной безопасности.
Отличием законов Природы от диалектических законов является то, что при рассмотрении законов Природы мы проводим связи и ассоциации с информационной безопасностью, в то время как диалектика уже представляет общий метод познания движения и развития. Иными словами, диалектике нет надобности создавать дополнительные связи и ассоциации, потому как диалектика и есть их описание. Вследствие этого, при помощи диалектики, мы можем описывать не только законы Природы, но и всё, что имеет движение, развитие. В то время как законы Природы всё же не способны описывать любое движение, например развитие Физики сложно как-то описать законами Природы, орудуя такими терминами как гомеостаз, адаптация, иммунитет, эпидемия и прочее.
Что? Math.random - это ГПСЧ, а не КСГПСЧ.
Необязательны случайные моменты времени. На самом деле, наиболее эффективная (со стороны теоретически доказуемых моделей) анонимизация трафика проводится, как бы это не звучало парадоксально, за счёт детерминированности отправления и получения сообщений, а не их хаотичности. Например, DC-сети (проблема обедающих криптографов) и QB-сети (модель очередей, как пример тут) базируются как раз на таковых принципах.
Чем не зашёл метанит для освоения таких базовых вещей? Возможно это моё субъективное мнение, но основы языка Go можно буквально на каждом ресурсе найти по программированию.
То есть, отпечаток пальца или скан лица не переводятся в цифровой вид и их нельзя будет скопировать? Магия будущего?
И как понимаю опечатка в "парольные".
Пропустил это. Да, если сами центры сертификации начнут подменять все запросы, то данный метод становится бессильным. Но, по моиму субъективному мнению, такая кооперация и ЦС, и сервисов связи является достаточно сложной, потому как требуется не только подменить сертификат на стороне ЦС, но и перенаправлять все запросы на внешне похожие сервисы связи, или на оригинальные сервисы, с учётом того, если они смогут корректно воспринимать подменённый сертификат от самого ЦС.
Глобальный наблюдатель здесь и не фигурирует. Суть заключается в том, что идентификация любого рода, будь то знание публичного ключа или знание сетевого адреса не приведёт к деанонимизации самих действий в анонимной сети. Будет ровно такая же сложность обнаружения действий пользователя.
Алгоритм можно изменить на доверие к N-ому количеству сервисов из множества представленных. Сам алгоритм является вероятностным в любом случае, поэтому здесь оперируем лишь количественными характеристиками.
Я говорил в контексте обмена ключами асимметричной и симметричной криптографий. При симметричной криптографии обмен ключами легко может привести к пассивным атакам на обычный их перехват, что нельзя сказать об асимметричной криптографии, где действуют лишь активные атаки на перехват ключей.
Как минимум простота обмена ключами: N(N-1)/2, вместо 2N, и существование идентификатора со связью 1 (публичный ключ) ко многим абонентам, а не 1 (сеансовый ключ) к одному абоненту.
Совершенно верно. Подобного же принципа придерживается сеть Herbivore, разделяющая участников сети по группам. Тем не менее у такого принципа есть нюанс в плане того, что децентрализованные сети сами по себе являются динамичными структурами. Если будут существовать в сети статичные узлы, то вероятность того, что пользователь общается именно с ними будет стремиться к нулю. Если общение двух абонентов частое, то из всего множества N=100 можно со временем по крупицам убирать узлы, которых ранее не существовало и оставлять только тех, которые до сих пор активно работают. В таком случае, будет существовать вероятность, при которой N будет стремиться к единице за счёт продолжительной связи между двумя абонентами. Когда же мы в качестве N берём все узлы в системе, такого уже не будет возникать.
В статье об этом говорится и о решении тоже:
---
Как вы защититесь от централизованных сервисов, которые и являются фактическими конечными получателями всех сообщений? Квантовые технологии лишь укрепят безопасность связи клиент-сервер, но не клиент-клиент.
Не сводит. Как минимум асимметричная криптография защищает от пассивных атак злоумышленника, что нельзя сказать о симметричной криптографии. Данное свойство как раз и позволяет использовать множество централизованных сервисов для обмена публичными ключами. Если бы мы передавали симметричные ключи, то их можно было бы напрямую использовать без явной подмены.
Факт, только в какой пропорции происходит увеличение вероятности раскрытия информации, сколько потребуется памяти для её осуществления? На сколько знаю такие атаки также являются достаточно трудоёмкими и требуют огромного количества открытых и закрытых текстов для их осуществления. Асимметричные ключи могут жить фактически годами, но да, это не отменяет необходимости их смены/замены.
Совершенно верно. Полная связность необходима лишь для упрощения самого механизма работы, т.к. это исключает маршрутизацию и, как следствие, дополнительный код. Целью статьи являлось, в первую очередь, создание минимальной анонимной сети. Все дальнейшие совершенствования лишь увеличили бы её количество кода. Так например, в основной моей анонимной сети, которую я пишу в свободное время, как раз неважна топология. Но в любом случае, какую бы мы топологию не выбрали, нагрузка на сеть будет всегда линейна. Если бы мы выбрали топологию "Звезда", то от одной точки к любой другой также бы сообщение доходило и также бы обрабатывалось.
Возможно тут я неправильно донёс мысль. В задаче на базе очередей период T выставляется локально и независимо для каждого узла в сети. Иными словами, они не кооперируют с тем, чтобы каждый подстраивался под конкретное время начала генерации. Асинхронность, либо даже изменение выставленного периода T, в сравнении со всеми другими узлами сети, не влияет на качество анонимизации трафика. Тем не менее, период T равный одному и тому же значению для всех узлов в сети как минимум способен приводить к отсутствию чётко заданных групп, которые можно было бы выделять по времени генерации. Поэтому я в описании задачи на базе очередей указывал именно константную T.
Примерно как-то так, надеюсь ответил на все вопросы и замечания.