Разрешается ли вообще выполнять алгоритмы, не соответствующие FIPS, в системе, совместимой с FIPS?

Если часть программного обеспечения работает в режиме FIPS и использует криптографические модули, сертифицированные FIPS, разрешено ли ему выполнять какие-либо алгоритмы, отличные от FIPS, даже если безопасность системы не зависит от них однозначно?

Пример: допустим, у вас есть система, которая обменивается двумя парами ключей ECDH: одной парой ключей curve25519 и одной парой ключей NIST P-384. Согласование ключей выполняется с использованием обеих пар ключей, а затем полученные секреты объединяются и хэшируются с помощью SHA-384.

Криптографически я не вижу проблемы, так как результат SHA-384 (K0 | K1) такой же сильный, как и самая сильная кривая. Это связано с тем, что SHA-384 (секрет | известное значение) является секретом, а это означает, что если злоумышленник взломает, скажем, кривую 25519, он все равно не узнает результат хеширования этого секрета с другим секретом, которого они не знают.

Мой вопрос заключается в том, позволяет ли это FIPS или он должен выполнять только код и алгоритмы, сертифицированные FIPS. Можете ли вы считать вычисленный общий секрет curve25519 «солью» или чем-то еще?

Изменить: учтите, что результат соглашения без FIPS, например. Curve25519 можно смешать с «официальным» секретом в виде соли, например. HMAC-SHA384 (соль, ключ).

На самом деле, curve25519 находится на пути к одобрению FIPS (NIST SP 800-186), но это не то, о чем вы спрашиваете.

Чтобы ответить на ваш вопрос, да, NIST заявил, что они разрешают неутвержденный алгоритм параллельно с их предпочтительным обменом ключами. На данный момент их официальный утвержденный процесс потребует обработки неутвержденного общего доступа к ключу иначе, чем утвержденного; однако они отмечают, что это изменится в следующей версии NIST SP 800-56C.

Их фактическое заявление (из https://csrc.nist.gov/Projects/post-quantum-cryptography/faqs), который применим не только к постквантовой криптографии (некоторые тексты с постквантовыми примерами были опущены):

Возможно ли, чтобы гибридный режим установки ключа выполнялся в режиме работы, одобренном FIPS 140? (добавлено 28.01.20)

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

Текущие стандарты NIST ... могут поддерживать несколько конструкций создания гибридных ключей в «режиме FIPS», как определено в FIPS 140. Например, предположим, что значение Z является общим секретом, который был сгенерирован в рамках криптографического протокола, одобренного NIST. схема, и что значение T генерируется или распространяется через другую схему (схемы)... Ниже приведены различные способы включения значения T в процедуру получения ключа для достижения гибридного режима, разрешенного текущими стандартами:

Для любого одношагового метода получения ключа, указанного в SP 800-56C, входные данные, определенные как SuppPrivInfo, могут быть включены в (необязательное) поле FixedInfo, а T может быть включено в это поле. В любом из методов получения ключа, указанных в SP 800-56C, будь то одношаговый или экстракция-затем-расширение, значение T может быть включено в поле соли. Кроме того, NIST планирует включить более чистую и, следовательно, предпочтительную конструкцию создания гибридного ключа в будущую версию SP 800-56C:

В любом из методов получения ключа, указанных в SP 800-56C, редакция допускает конкатенацию Z и T, например, Z||T, для использования в качестве общего секрета вместо Z. Это потребует вставки T в возможно, потребуется изменить кодировку схемы и код проверки FIPS 140.