#️⃣Хэш функции
Blake3,SHA-256 и ещё кое-что
Следующим важным компонентом являются хэш-функции. В KLYNTAR мы будем использовать такой набор функций в наших внутренних процессах:
BLAKE3 (256 битная с расширением до 512 бит)
SHA-256
SHA3
BLAKE3
BLAKE3 была выбрана в качестве основного кандидата для использования в качестве ведущей хэш-функции для получения хэшей заголовков блоков, хэшей workflow, архивов сервисов, квантовых свопов (модификация атомарных свопов) и так далее. Сверхбыстрая, поддерживает режимы PRF, MAC, KDF и XOF, обладает высокой степенью параллелизма и т.д.
Поскольку BLAKE3 поддерживает режим XOF, то выходная длина хэша может быть переменной(как в семействе алгоритмов хеширования SHAKE). Это важно в случае ее использования в качестве квантово-безопасной альтернативы 128- или 256-битным схемам, которые могут быть неустойчивыми перед алгоритмами Гровера или BHT в случае обнаружения коллизий, что будет опасно для квантовых свопов между симбиотами (подробнее см.Квантовые заметки & мысли).
Использование на симбиотах
BLAKE3 будет использоваться в симбиоте kNULL рабочим процессом dev_controller для генерации хэшей блоков, транзакций и так далее. Также, благодаря механизмам мутации, разработчики других рабочих процессов, операторы узлов в других симбиотах будут иметь возможность использовать любую функцию, которую они захотят, которая будет представлена в официальном репозитории или разработана/распространена третьими лицами(контрибуторами или свободными разработчиками) по альтернативным каналам.
Использование для генерации адресов
Так же что касается применения на уровне алгоритмов, то мы используем BLAKE3 для генерации адресов в пост-квантовых схемах подписи ввиду большого размера публичного ключа. Очевидно что адресом будет BLAKE3(PublicKey)
В этом можно убедиться даже через Apollo
Использование для квантовых свопов
Для обмена ресурсов в парах симбиот - симбиот или хостчейн - симбиот данная функция так же будет необходима.
Использование для идентификации сервисов и смарт-контрактов
Уникальные ID для уникальных контрактов и сервисов. Для смарт-контрактов речь идёт про хэш WASM модуля, для сервиса - хэш архива.
SHA-256
Хорошая и надёжная, а так же сверхпопулярная хэш-функция которая прошла проверку временем. В KLYNTAR используется выборочно в определённых местах типа для получения сида при расшифровке ключей или для надёжности в репозиториях сервисов(вместо устаревшего SHA-1).
SHA3
256-битная SHA-3(так же известная как Keccak-256) на основе функции-губки является стандартом NIST. Она используется в качестве основной в Ethereum(хоть там и небольшая путаница между соответствиями) и в других криптовалютах. В KLYNTAR мы используем ее для кольцевых подписей и zkp доказательства Шнорра.
Квантовая угроза и концепция RippedHashes
То что в настоящее время считается квантово-устойчивым уже завтра может попасть под категорию уязвимых алгоритмов для квантовых компьютеров.
Поскольку квантовые алгоритмы - это не чёрный магический ящик, а вполне конкретные математические алгоритмы которые просто полагаются на физические свойства элементарных частиц(которые можно называть квантовыми и которые проявляют соответствующие свойства корпускулярно-волнового дуализма, недетерминированности, запутанности и других эффектов), то надо быть готовым к тому что завтра на условном arxiv.org появится статья об очередном алгоритме который уже будет угрожать 256-битным секретам и для этого нужно будет меньшее количество квантовой памяти, меньшее количество одновременно запутанных частиц или же узнаем о новом рекорде по времени декогеренции.
Так или иначе перед нами станет совершенно реальная проблема угрожающая всем блокчейнам, алгоритмам основанных на хэш функциях и так далее. А это мы только упомянули ущерб от атак на хэши, а ведь есть ещё и другие криптографические схемы-обмен ключами, подписи, доказательства с нулевым разглашением...
Тем не менее, поскольку этот раздел посвящён именно хэшам, то о них и пойдёт речь.
Размеры хэша
Упомянутая BLAKE3 может быть расширена до 512 байт и более. Так же можно будет рассмотреть вариант применения и других XOF функций.
Алгоритмы подписи
KLYNTAR так же включает в себя алгоритмы подписи на основе хэшей. Это Winternitz и HORS, оба используются с деревом Меркла(поскольку не являются stateless, а требуют хранения "использованных" раскрытых хэшей). Они так же могут быть переведены на 512 битные хэши при необходимости без значительных затрат. В настоящее время они входят в репозиторий, однако мы пока что не планируем их использования ввиду наличия более эффективных пост-квантовых алгоритмов подписи - Dilithium(NIST кандидат) и BLISS.
RippedHashes
Теперь речь пойдёт про ещё один метод защиты. Криптографически стойкая хэш функция по сути нужна для того, чтоб мы были уверенны что некоторому x соответствует hash=H(x) и при этом функция была стойкая к атакам первого и второго рода.
Имея поле значений злоумышленнику должно быть крайне трудно подобрать правильный x для H(x) и таким образом например обмануть лёгкие клиенты которые не хранят доказательства в виде хэша или новые узлы которые хотят убедится в верности состояния некоторого сервиса путём сравнения хэшей состояния в симбиоте с получаемыми данными.
Предположим что есть две стороны - проверяющий и доказывающий. Проверяющий хранит только хэши блоков некоторого симбиота, а доказывающий отправляет ему эти блоки. После чего проверяющий считает хэш блока, убеждается в его валидности и вхождению в единственно возможную цепочку блоков симбиота и принимает состояние симбиота. Это в упрощённом виде то как работает мутуализм между симбиотами.
Однако, если доказывающему удастся подменить блоки, но хэш будет идентичным, то разумеется что атака будет успешной ведь теперь непонятно какой из блоков - это часть цепи. Условно говоря окажется что на какой-то высоте 500 000 разные узлы предлагают нам блок с тем же индексом но только с хэшами aaaa... и bbbb...
Да и можно ли теперь вообще как-то работать? Ведь даже наличие ставок унобтаниума добытого PoW путём потенциально не спасёт - имея такой алгоритм злоумышленник будет быстро находить нужные хэши и формировать ложные доказательства даже для PoW алгоритмов.
В основе RippedHashes лежит то, что помимо хэша проверяющему так же надо будет хранить определённую часть оригинальных данных + придерживаться определённой логики(принимать блоки только правильного формата). Таким образом, если например ограничить размер блока до 4 мегабайт, то в теории это равносильно пространству из
вариантов блока(рассчитано на основе бит). Учитывая формат, а так же значения внутри(например суммы транзакций не могут быть отрицательными) это число сильно уменьшается, хоть и сложно сказать согласно какой закономерности. Злоумышленнику уже сложнее подобрать нужный хэш, ведь пространство значений ограничено, а даже если удастся найти какой-то альтернативный блок с тем же хэшем(по сути - коллизию), но внутри у такого блока будут не те форматы адресов, неправильные форматы данных и т.д., то такой блок уже не выдать за настоящий.
Однако, хоть пространство значений и уменьшилось, всё таки оно не стало нулевым. Для большей минимизации, проверяющий должен был изначально сохранить помимо хэша блока ещё часть "чистых данных". Например адрес получателя в транзакции с индексом 10, последние 5 байт адреса коммита какого-то сервиса и так далее. В таком случае, у атакующего ещё меньше вариантов сгенерировать блок который бы нарушил всё и при этом соответствовал хэшу и таким вот дополнительным условиям. Так что путём увеличения хранимых данных для проверяющего мы таким образом уменьшаем область для атак доказывающего злоумышленника.
Алгоритм ещё сырой и требует исследований + скорее является теоретическим, но мы должны быть ко всему готовыми.
Стоит так же упомянуть что RippedHashes не подходят для случаев когда необходимо держать секрет в тайне. Например, для квантовых свопов или доказательств с нулевым разглашением. Хотя опять таки, можно попытаться что-то выкрутить и заняться исследованиями.
Last updated