Рейтинг:1

Как проверить уровень безопасности случайного k, если k является входным параметром функции генерации подписи ECDSA с использованием openssl-fips

флаг pe

Насколько я понимаю,

1.Степень защиты указывается в битах согласно https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf

2. Надежность зависит от длины ввода энтропии при генерации случайного числа.

Итак, в функции генерации подписи, если случайное k является входным параметром (не генерировать случайное k в этой функции)

Как проверить действительный k? сила безопасности случайного k?

1, проверить только количество бит случайного k?

2, другие испытания?

Спасибо

Рейтинг:4
флаг ng

в стандартное определение ECDSA, одноразовый номер $к$ должно быть секретным равномерно случайным целым числом в диапазоне $[1,n)$, куда $n$ является простым порядком генератора. Анализ пар сообщение/подпись при $к$ известен или имеет дефект (например, предвзятость или склонность к повторению) может привести к утечке закрытого ключа, что приведет к генерированию $к$ имеет значение для безопасности.

Реализация генерации подписи ECDSA не может осмысленно проверить, что значение вход $к$ он получает подходит для безопасного использования как предписано в стандартное определение подписи ECDSA, потому что невозможно сказать по значению, является ли оно секретным или нет, что является наиболее важным качеством $к$ должен обладать. Также невозможно оценить, является ли данное $к$ является случайным, как предполагает вопрос, по крайней мере, если мы не знаем, как он был произведен. И в любом случае, в контексте случайность вторична по отношению к тайне.

Поэтому вместо принятия $к$ в качестве входных данных, общая процедура состоит в том, чтобы сделать генерацию случайного $к$ часть реализации генерации подписи ECDSA. Основная (хотя и не обязательно рекомендуемая) процедура состоит в том, чтобы нарисовать $\lceil\log_2(n)\rceil$ биты из предполагаемого криптографически стойкого ГСЧ (например, /dev/urandom) и интерпретировать эти биты как целое число $к$ напр. соглашение с обратным порядком байтов, пока оно не будет выполнено $0<k<n$ (что для многих $n$ используется на практике по существу всегда, т.к. $n$ чуть меньше степени двойки). Я игнорирую эту основную процедуру в остальной части ответа (хотя это комментарий предполагает, что это была суть вопроса).

Можно изменить процедуру генерации подписи ECDSA, чтобы безопасно использовать любые $к$ он получает. Вместо $к$, генерация подписи может использовать $k':=f(d_U,H,k)$ куда $d_U$ закрытый ключ, $Ч$ это хэш сообщения для подписи, и $f$ представляет собой функцию получения открытого ключа, использующую $d_U$ как мастер-ключ, с выходом, близким к равномерному в $[1,n)$ куда $n$ это порядок генератора. Такая практика никоим образом не нарушает совместимость и обнаруживается только с обоими $к$ и закрытый ключ (поверх другой общедоступной информации). За $n$ по крайней мере до 384-бит, подходящей функцией будет $$k':=1+(\operatorname{HMAC-SHA-512}(d_U,H\mathbin\|k)\bmod(n-1))$$

Примечание: теоретически процедура подписания имеет ряд «возвратов к шагу 1», которые повторно вызывают $f$ и ожидать другого $к'$, и не получит этого.Однако это спорно, так как вероятность повторного вызова $ф$ совершенно пренебрежимо мал и не поддается проверке даже при контроле $d_U$, $Ч$ и $к$, для правильной фиксированной незлокачественной $ф$. Если эта возможность, тем не менее, предотвращает попадание резинового штампа на бумагу, мы могли бы использовать $k'=f(d_U,H\oplus j,k)$ куда $j$ количество предыдущих вызовов $ф$ в подписи.

Примечание: если нет недостатка в том, чтобы сделать подпись детерминированной, мы можем игнорировать входные данные. $к$. При рассмотрении некоторых (но далеко не всех) атак по побочным каналам, которые могут быть даже безопаснее, в частности, против атак злоумышленников, которые знают и контролируют $к$.

Andy avatar
флаг pe
Прежде всего, большое спасибо за ваше объяснение! Итак, если k из TRNG (en.wikipedia.org/wiki/Hardware_random_number_generator), зная, как оно было произведено. Возможно ли мое первое решение? который является только проверкой количества битов k. Предположим, что k (из TRNG) являются секретными и случайными
fgrieu avatar
флаг ng
@Andy: я расширил базовый (если не рекомендуемый) способ генерации $k$ в ECDSA, см. третий абзац ответа. Обратите внимание, что если вы используете существующую реализацию подписи ECDSA, скорее всего, она сгенерирует $k$ (и если она заботится о безопасности, она может использовать метод, аналогичный описанному в четвертом абзаце). Имейте в виду, что существует множество трудностей при создании безопасной реализации генерации подписи ECDSA (побочные каналы, атаки с ошибкой и т. д.), и здравый смысл подсказывает, что это следует оставить опытным программистам безопасности.

Ответить или комментировать

Большинство людей не понимают, что склонность к познанию нового открывает путь к обучению и улучшает межличностные связи. В исследованиях Элисон, например, хотя люди могли точно вспомнить, сколько вопросов было задано в их разговорах, они не чувствовали интуитивно связи между вопросами и симпатиями. В четырех исследованиях, в которых участники сами участвовали в разговорах или читали стенограммы чужих разговоров, люди, как правило, не осознавали, что задаваемый вопрос повлияет — или повлиял — на уровень дружбы между собеседниками.