Я взял стоимость электроэнергии в США в качестве основы, потому как таковая страна генерирует наибольшее количество хешрейта. Нет сомнений, что стоимость электроэнергии могла быть другой или стоимость самих ASIC'ов могла быть другая. Я абстрагировался от этого посредством того, что уже мы имеем. И на основе этого, на основе имеющихся данных выстраивал стоимость Bitcoin'a.
Если бы я решил выявить прям абсолютно настоящую стоимость Bitcoin'а, то я бы начал вообще с грядок и того, как происходит обмен горохом, картошкой и огурцами. Но это бы требовало как минимум годы исследований, и как вы сказали, полученный результат вряд-ли был бы точным. Поэтому самая правильная стратегия в данной случае - это абстрагирование. Ровно также как и в программировании мы абстрагируемся от конкретно физических явлений и руководствуемся исключительно алгоритмическим представлением.
Изначальный посыл не вполне верен: вы рассчитали скорее себестоимость (майнеры + энергия). Цена зависит в еще и от того, сколько люди готовы заплатить.
Верно, я расчитал себестоимость в лице стоимости P, а далее определил, что существует другая - динамичная стоимость равная P', которая как раз и зависит от того, сколько люди готовы заплатить в надежде подорожания товара (Bitcoin'a). На этом моменте и держутся криптовалюты, а также их скачкообразность.
В остальном могу лишь добавить, что после того как будут уходить майнеры, алгоритмы Bitcoin'a вновь выровняют сложность под текущие реалии. Поэтому в любом случае, майнеры будут держаться на определённо заданной границе. И как следствие, вновь ASIC'и начинают играть свою роль.
Такое равенство "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 можно буквально на каждом ресурсе найти по программированию.
Я взял стоимость электроэнергии в США в качестве основы, потому как таковая страна генерирует наибольшее количество хешрейта. Нет сомнений, что стоимость электроэнергии могла быть другой или стоимость самих ASIC'ов могла быть другая. Я абстрагировался от этого посредством того, что уже мы имеем. И на основе этого, на основе имеющихся данных выстраивал стоимость Bitcoin'a.
Если бы я решил выявить прям абсолютно настоящую стоимость Bitcoin'а, то я бы начал вообще с грядок и того, как происходит обмен горохом, картошкой и огурцами. Но это бы требовало как минимум годы исследований, и как вы сказали, полученный результат вряд-ли был бы точным. Поэтому самая правильная стратегия в данной случае - это абстрагирование. Ровно также как и в программировании мы абстрагируемся от конкретно физических явлений и руководствуемся исключительно алгоритмическим представлением.
Где вы это нашли? Везде я приводил скорости в /s, включая и хешрейт самого Биткоина: https://bitinfocharts.com/ru/comparison/bitcoin-hashrate.html#3y
Верно, я расчитал себестоимость в лице стоимости P, а далее определил, что существует другая - динамичная стоимость равная P', которая как раз и зависит от того, сколько люди готовы заплатить в надежде подорожания товара (Bitcoin'a). На этом моменте и держутся криптовалюты, а также их скачкообразность.
В остальном могу лишь добавить, что после того как будут уходить майнеры, алгоритмы Bitcoin'a вновь выровняют сложность под текущие реалии. Поэтому в любом случае, майнеры будут держаться на определённо заданной границе. И как следствие, вновь ASIC'и начинают играть свою роль.
Тут я согласен. Можно сказать, что 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 можно буквально на каждом ресурсе найти по программированию.
То есть, отпечаток пальца или скан лица не переводятся в цифровой вид и их нельзя будет скопировать? Магия будущего?
И как понимаю опечатка в "парольные".