From ae09a56ab4c40b8a377821678c929e32ef2a0c0d Mon Sep 17 00:00:00 2001 From: Sergey Matveev Date: Fri, 18 Apr 2025 09:54:14 +0300 Subject: [PATCH] =?utf8?q?SPHINCS+=20=D0=B2=20KEKS/CM?= MIME-Version: 1.0 Content-Type: text/plain; charset=utf8 Content-Transfer-Encoding: 8bit https://sphincs.org/ К KEKS/CM форматам добавил возможность создания подписей SPHINCS+ алгоритмом, который стал стандартом SLH-DSA (stateless hash-based digital signature algorithm) в NIST, наравне с ML-DSA. Чем мне очень понравился SPHINCS? Тем, что он полностью основан исключительно на хэш-функциях и я в общем и целом понимаю его устройство, понимаю принцип работы. Не в таком понимании как эллиптические кривые и простое доверие что всё так и есть, когда объясняют на пальцах, а такое, что я прям осязаю что вся сложность задачи сводится к свойствам хэшей криптографических. Ну и в его создании участвовал DJB. Активно пытаются стандартизовать XMSS алгоритм подписей. Тоже всё на хэшах, но он stateful -- каждая подпись это изменение состояния "приватного ключа". Что не шибко то удобно, но зато точно работает. Так вот SPHINCS это как-бы надстройка над XMSS, делающая его stateless. Но ценой вычислительных мощностей и размера подписи. Если взять самый параноидально безопасный вариант SPHINCS+: 256s-robust, то создание ключевой пары, создание и проверка подписи занимают несколько секунд. Но позже в SPHINCS+ предложили "simple" вариант, который в разы легче по затратам процессора и более чем удовлетворяет безопасностью. SLH-DSA выбрал вообще только этот вариант. "256f" ("s" -- small, "f" -- fast) вариант гораздо более быстрее, ценой размера подписи большим на 10 килобайт (~30 vs ~40). Это компромисс, но я выбрал более быстрый вариант, ибо место довольно дёшево и это не вопрос 1K (который влезет в один IP-пакет) vs 10K. Подпись можно делать детерминированной (без использования случайных данных) или randomised. Изначально я слепо выбрал детерминированную, ибо это убирает требование наличия хорошего PRNG. По аналогии с детерминированными подписями в Ed25519 vs ECDSA/ГОСТ. И SPHINCS+ и NIST намекают, что randomisation полезно для борьбы с fault-injection атаками. Но позже я осознал свою неправоту: хороший PRNG вовсе не требует. Даже если PRNG будет константой, то это просто станет детерминированной подписью, без каких-либо рисков для утечки приватного ключа. Поэтому он либо ничего не даст (если PRNG плохой), либо приятные свойства против fault-injection атак. Да, размер подписи большой, но всё же более чем пригодный для применения на практике, плюс точно очень безопасный, даже против квантовых компьютеров. Пока мне видится использование SPHINCS+ (или SLH-DSA варианта) как предпочтительного для долговременных документов. Не там где подпись используется для интерактивной аутентификации (TLS тот же), а для подписей рядом с файлами. И то, для интерактивных протоколов стоит не подписи, а DH использовать. -- 2.48.1