Запрос на общественные комментарии по подписи на основе хеша (HBS)
В настоящее время NIST намеревается одобрить схемы подписей на основе хеш-кодирования как с LMS, так и с XMSS, и стремится получить публичные комментарии по этому предложенному действию к 1 апреля 2019 года.
В декабре 2016 года NIST объявил конкурс предложений.использование криптосистем с открытым ключом, способных защищать конфиденциальную информацию даже после появления квантовых компьютеров. Соответствующий FAQотметил, что в NIST планируется отдельный процесс стандартизации подписей на основе хеша с сохранением состояния, который будет координироваться с другими организациями по стандартизации, такими как Internet Engineering Task Force (IETF),
IETF занимается разработкой спецификаций для двух схем цифровой подписи на основе хэширования, XMSS и LMS. XMSS был опубликован как Запрос комментариев (RFC) в мае 2018 года. LMS все еще находится в стадии разработкино почти завершен. 21 июня 2018 года NIST запросилинформация от общественности о ее планах стандартизировать подписи на основе хеша с указанием состояния, спрашивать, должен ли NIST перейти к XMSS сейчас или дождаться завершения LMS. Общее согласие было то, что оба должны быть стандартизированы.
Схемы подписи на основе хэширования с учетом состояния, такие как XMSS и LMS, подвержены неправильному использованию. В этих схемах подписывающее лицо имеет набор пар ключей для одноразовой схемы подписи. Если какой-либо конкретный закрытый ключ используется для генерирования подписей в двух или более отдельных «сообщениях» (т. e. В данных, которые должны быть подписаны), то злоумышленнику, имеющему доступ к сигнатурам, будет легко создать подделки (дополнительные «действительные» подписи). ) на другие сообщения.
В то время как точный уровень безопасности зависит от параметров схемы одноразовой подписи, безопасность подписей на основе хеша с сохранением состояния должна считаться нарушенной в случае повторного использования ключа. При типичных значениях параметров безопасность будет снижена до уровня, который на несколько порядков ниже, чем у одноключевого DES, который был публично взломан в конце 1990-х годов. В некоторых случаях подделка подписи может быть произведена за несколько минут вычислений на ноутбуке потребительского уровня; см. [Bruinderink и Hülsing] для подробного анализа. Следовательно, реализации XMSS или LMS должны поддерживать состояние для отслеживания одноразовых закрытых ключей, которые использовались для генерации подписей, чтобы предотвратить их повторное использование.
Эти соображения мотивировали следующее утверждение в FAQ и июньское объявление:
Ожидается, что NIST будет утверждать стандарт подписи на основе хэша с сохранением состояния только для использования в ограниченном диапазоне приложений для подписи, таких как подписывание кода, где большинство реализаций смогут безопасно обрабатывать требование сохранения состояния.
На практике, однако, NIST трудно ограничить приложения для криптографических методов, даже для реализаций, которые сертифицированы под эгидой Программы проверки криптографических модулей (CMVP). Например, когда библиотека программного обеспечения криптографических методов проверяется в рамках программы, ее поставщик не обязательно будет располагать какой-либо информацией о приложениях для подписи, для которых клиенты поставщика могут выбрать развертывание этих методов.
Кроме того, CMVP и Программа проверки криптографических алгоритмов (CAVP) предназначены для обеспечения гарантии того, что отдельные модули правильно реализуют криптографические методы. Опыт показывает, что может быть очень трудно обеспечить соблюдение требований в более крупной системе, в которой развернуты модули.
Отдел компьютерной безопасности NIST хотел бы получить ваши отзывы.
В настоящее время NIST планирует одобрить как LMS, так и XMSS. Поскольку подписи на основе хеша с сохранением состояния склонны к неправильному использованию, NIST ищет ответы на следующие вопросы:
Как спецификация NIST должна характеризовать приложения, для которых такие подписи подходят или не подходят?
Какие требования и рекомендации по защите от неправильного использования должны включать NIST помимо того, что предусмотрено в спецификациях IETF?
Комментарии могут быть отправлены на pqc-comments@nist.gov с темой «Полные комментарии HBS» до 1 апреля 2019 года.