Use of 'internal' procedures for testing of FIPS algorithms

[RodriM11]

According to FIPS 203, 204 and 205, the separation between the main internal and the actual processes of each operation of the PQ FIPS algorithms is done to allow testing directly over the internal (derandomized) versions, as for example FIPS 203 establishes:
"The interfaces specified in this section will be used to test ML-KEM implementations through the Cryptographic Algorithm Validation Program (CAVP). "

My question was whether the internal processes already present on ML-KEM and ML-DSA will be made available 'somehow', in order to test the 'derandomized' versions of these algorithms.

Thanks in advance!

[bhess]

Hi @RodriM11,

liboqs currently tests the NIST ACVP vectors, covering both the deterministic and randomized versions of FIPS 203, as well as the internal sign and verify functions of FIPS 204. You can find the relevant test implementations here:

vectors_kem.c
vectors_sig.c
test_acvp_vectors.py

#2051 will further cover the updated FIPS 204 vectors covering the external interface.

Let me know if this answers your question or if you think anything is missing.

[dstebila]

Can we consider this resolved by the merging of #2051?

[RodriM11]

Hi @bhess! First, thanks for your detailed answer. I did see the code you mentioned, but I fail to understand how the code is actually accessing crypto_kem_keypair_derand directly. The way I interpret the code (I am sure I am wrong) is: it is accessing crypto_kem_keypair (which, in turn calls crypto_kem_keypair_derand) but it is deterministic since liboqs DRBG is toggled to establish a deterministic one. And the way I interpret FIPS 203 is that for testing purposes, an API directly into the internal processes should be made available (i.e., I shouldn't need to toggle with liboqs DRBG in order to perform KATs of ML-KEM, ML-DSA or SLH-DSA).

My question was if there will be a way (or a compilation option, etc...) in which the internal (_derand) processes will be able to be accessed directly, without the need for toggling with the DRBG.

[bhess]

I think you interpret it the correct way, we create a custom DRBG that outputs the deterministic values needed to perform the derandomized tests.

Looking at FIPS 203, Sec 3.3 states:

Controlled access to internal functions. The key-encapsulation mechanism ML-KEM makes use
of internal, “derandomized” functions ML-KEM.KeyGen_internal, ML-KEM.Encaps_internal, and
ML-KEM.Decaps_internal, specified in Section 6. The interfaces for these functions should not
be made available to applications other than for testing purposes. In particular, the sampling of
random values required for key generation (as specified in ML-KEM.KeyGen) and encapsulation
(as specified in ML-KEM.Encaps) shall be performed by the cryptographic module.

I interpret the text as permitting these functions to be made available (only) for testing purposes, but it does not require that they must be explicitly exposed. Since we have a less intrusive way to run the tests by using a custom DRBG, I believe there is no need to explicitly expose the internal functions. Let me know if you interpret this differently.

[RodriM11]

I understand your interpretation (IMO it is a perfectly valid way of testing the procedures, given liboqs structure), since I feel wording of FIPS 203 is not explicit either way. IMO it is a matter of how to interpret

The interfaces for these functions should not
be made available to applications other than for testing purposes.

Nevertheless, my question was not so much related to the specific wording of NIST, and more over the question of whether it might be desirable for users not on academic uses to have a testing procedure that does not involve DRBG toggling.