mupq / pqm4

Post-quantum crypto library for the ARM Cortex-M4
296 stars 75 forks source link

Random Number Generation and FIPS 140-2 Compliance #347

Open ecominetti opened 3 months ago

ecominetti commented 3 months ago

Hello,

I have been studying the pqm4 code and I have a doubt about the random number generator (specifically for STM32F4 board, as hardware RNG varies for each board).

I see that random number generation for STM32F4 board follows exactly section 24.3.1 from the reference manual (https://www.st.com/resource/en/reference_manual/rm0090-stm32f405415-stm32f407417-stm32f427437-and-stm32f429439-advanced-armbased-32bit-mcus-stmicroelectronics.pdf).

However, the manual also says that FIPS 140-2 requires that the first random number not to be used and that each new random number to be compared to the last one, in a test called "Continuous random number generator test". This test is also described on FIPS 140-2 itself.

I have not seen this test performed on the code at any point. Thus, I believe the RNG used on pqm4 is not currently FIPS 140-2 compliant. Am I missing something or this is a deliberate implementation decision?

Thank you,

Eduardo

mkannwischer commented 3 months ago

From a technical perspective: My understand is that rng_get_random_blocking of libopencm3 blocks until DRDY is set which means a new 32-bit value is available. So I do not see an obvious security problem here other than it not following arbitrary rules mandated by FIPS.

From a compliance perspective: We are certainly not claiming any FIPS 140-2 compliance. Whoever wants to use (part of) pqm4 for any FIPS 140-2 certification will have to replace the randombytes() with their own implementation. pqm4 is not planning to do any certification at this point (and likely we won't in the future); it should be used for testing and benchmarking purposes only.

If you happen to know a better randombytes() implementation based on libopencm3, please let us know and we'll consider it.