Open ecominetti opened 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.
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