Как мы можем измерить уровни безопасности постквантовых криптографических алгоритмов? Есть ли стандартный способ этого измерения?

Как мы измеряем уровни безопасности алгоритмов постквантовой криптографии, таких как: NTRU Prime, Sabre, Kyber,... которые представлены в процессе стандартизации NIST PQC (конкурсе) в целом?

Я читал документацию в пакете представления NIST для NTRU Prime, но понимание уровней безопасности кажется очень сложным для алгоритмов PQC, в отличие от алгоритмов без PQC, для которых мы можем использовать простые методы сравнения с AES-256. Они говорят о трансформациях и уровнях безопасности CCA, CPA в зависимости от каких-то параметров, но мне это кажется сложным.

Может ли кто-нибудь объяснить измерение безопасности для алгоритмов PQC в целом?

(сбой уровня безопасности и сбой RAND_bytes)Ниже мое решение: Внешний файл источника шума от TRNGНапример: (80 бит), эти данные прошли все тесты

Подключить (1) к OpenSSL по движку Снова вызвать BN_rand() (собрать энтропию -> семя -> PRNG)

• Такой подход подходит? если нет, то какие другие методы?
• Большое спасибо !
• Как подключить внешний файл источника шума к openssl-fips-2.0.16
• Эта схема правильная? Что я должен просмотреть/прочитать, чтобы сделать это правильно? $2^{30}$Одна очевидная проблема заключается в том, что клиент готов расшифровать произвольные зашифрованные тексты с помощью своего закрытого ключа. Следовательно, если он использует закрытый ключ для каких-либо других целей, это небезопасно. $2^{30}$В статье от Digital Ocean вы можете найти, что клиент не отправляет необработанные данные обратно на сервер, а получает из них md5 и отправляет только md5. Почему так ? Ну, это для того, чтобы кто-то не использовал клиент Oracle в качестве расшифровщика; они по-прежнему могли бы использовать его как Oracle «расшифровать и MD5», но это не так уж плохо.Лично я бы сделал три изменения:
• Замените MD5 современным хэшем (например, SHA-256) — хотя MD5, вероятно, совершенно безопасен при таком использовании, он показал достаточно слабых сторон, поэтому лучше избегать его использования.

Я бы заменил детерминированный хэш рандомизированным. То есть я бы попросил клиента выбрать случайную строку «r» и вернуть пару $r, SHA256(r || расшифровка)$

. Таким образом, клиент также не может использоваться в качестве оракула «расшифровать и SHA256». В случае сбоя расшифровки я бы выбрал случайную расшифровку и вернул пару

Часто схемы (асимметричного) шифрования можно обсуждать с точки зрения доказуемой безопасности — мы можем показать, что схема безопасна при определенных атаках, если основной криптографический примитив является сложным. Другими словами, доказуемая безопасность основана на сведении нашей проблемы к ее примитиву, например, проблема RSA сводится к проблеме факторинга.

Как правило, обсуждаются следующие четыре свойства: IND, CPA, CCA и CCA2:

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

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

IND-CCA (неразличимость при атаке с выбранным зашифрованным текстом): то же самое, что и раньше, однако на этот раз у противника есть оракул дешифрования, который он может запрашивать, пока ему не будет предоставлен зашифрованный текст вызова.

IND-CCA2 (неразличимость при атаке с адаптивным выбранным зашифрованным текстом): как и в предыдущем примере, однако теперь злоумышленнику разрешено запрашивать оракула дешифрования даже после получения запроса (с оговоркой, что ему не разрешено вводить зашифрованный текст вызова оракулу)

Они выбраны для обсуждения, как если бы мы могли доказать, что (предполагая, что доказательство применяется в надлежащем контексте), нам нужно беспокоиться только о сложности проблемы, лежащей в его основе.

Определения этих свойств могут немного отличаться для симметричных схем (они не основаны на математических задачах), но мы можем доказать аналогичные результаты, опять же при определенных условиях (вспомните длину ключа).

Это позволяет нам теперь оценить «уровень безопасности» для этих параметров таким образом, чтобы их можно было перевести и сравнить с AES.