| cover | coverY |
|---|---|
../../.gitbook/assets/raijin-art-cyberpunk-girl-horn-vers.jpg |
555.440414507772 |
Да, не обошлось и без применения симметричных алгоритмов шифрования на KLYNTAR. Изначально область их применения была довольно узкой(ввиду локальности), но всё же вариантов использования много поэтому сейчас расскажем подробней.
Среди симметричных алгоритмов нет более известного, устойчивого и надёжного чем этот. Включён в OpenSSL, GPG, используется в ProtonMail, Google(для шифрования паролей), разработчиками разного рода малвари и в других популярных и широко используемых продуктах и протоколах. AES был принят правительством США в качестве официальной рекомендации, и с этого момента не было обнаружено никаких существенных недостатков или атак.
В настоящее время считается квантово-устойчивым(учитывая размер ключа в 256 бит).
Мы используем как раз таки 256 битный ключ который является SHA-256 хэшем вашего пароля. AES используется в режиме CBC, хотя это может быть изменено в зависимости от использования.
Для настройки демона вам нужно будет зашифровать все ваши приватные ключи-как приватные ключи KLYNTAR так и приватные ключи хостчейнов для интеграции с ними(создавать транзакции, взаимодействовать с контрактами и так далее).
При запуске демона KLYNTAR попросит расшифровать все ваши ключи как видно на изображении ниже
За кулисами происходит же следующий процесс
-
Мы получаем 32 байтный seed путём хэширования SHA-256
HEXSEED = SHA256(YOU_PASSWORD)\ -
Далее делим его на части по 16 байт. Первые 16 байт - пароль, вторые - вектор инициализации
-
После этого ваши ключи размещаются в памяти процесса в котором работает демон KLYNTAR
Несмотря на то что на машине приватные ключи будут хранится зашифрованы, все же они будут доступные в рантайме запущенного ядра. Таким образом, злоумышленник у которого будет достаточно прав(например он под рутом или проэксплуатировал ваш старый Apache) может сдампить память процесса и извлечь оттуда пароли.
По этой причине рекомендуем ответственно подходить к харденингу вашей системы. В идеале конечно чтоб демон был отдельным пользователем и никто кроме него не имел доступа к его ресурсам.
Ввиду того что сфера применения довольно узкая, а приватные ключи - это не такие уж и большие объемы чтоб переживать из-за скорости мы пока что не рассматриваем другие альтернативы.
В сервисах вы можете применять что угодно, даже использовать кастомные алгоритмы в смарт-контрактах.
Как уже было упомянуто, 256 бит достаточно против атаки Гровера с получением квадратичного ускорения при подборе ключа (O(√N)) и против алгоритма BHT(сложность O(N^1/3) однако требует больше запутанных кубит). Так же вы можете посетить так называемый Quantum Zoo для получения дополнительных материалов
{% embed url="https://quantumalgorithmzoo.org/" %}
В будущем мы так же планируем реализовать технологию Remote signing благодаря которой вам не придётся хранить ключи на "рабочих машинах". Узлы вашей инфраструктуры просто будут присылать вам необходимые данные на подпись и вы в безопасной среде в автоматическом режиме будете производить валидные подписи.