STM32F4 random number generation validation

[munish4u911ex]

Hello all,

I am working on a cryptography project based on STM32F407VGT micro controller, in which I need to generate random data using inbuilt RNG peripheral. I dump this random data to my Ubuntu 16.04 host machine using USB in CDC mode and using libusb 1.0.9. My buffer size is 16KB which I sent 64 times per 1MB. When I ran the statistical test suite on the 1MB generated data file, it gives a result of repeated sequence of bit stream around the last 64 KB of file. My window/slice size for statistical test is 1KB.

Now my question is whether or not I am initialising and using the RNG in the correct way.

I have attached my main.c here.

According to App note AN4230, the RNG on the STM32 is a TRNG (and not PRNG). But is it possible that the RNG is giving repetitive data? I suspect so because it mentions an LFSR and LFSRs have a finite bit sequence period.

[waclawek.jan]

I don't use Cube.

Do you have RNG clock enabled in RCC? Do you check CEIS/SEIS in RNG_SR?

JW

[munish4u911ex]

Thanks for replying​, Jan. Yes I have checked and the CubeMX is doing the initialization for the RNG and its clock (in HAL_RNG_Init() function).

In another version of the code, I had checked for CEIS/SEIS bits and cleared them as suggested in the STM43F4x7's User Manual. But still it's showing the same behaviour.

​

Another thing that I have tried is de-init & init the RNG peripheral periodically while sending data but to no use.​

[waclawek.jan]

> I had checked for CEIS/SEIS bits

And were they set? According to RM, you are not supposed to use the generated number if they are set.

I used RNG in 'F407 as generator of audio noise. I know it's not a rigorous test, but IMO if there would be a repetition pattern, I suppose I'd see it as a peak in the spectrum.

JW

[waclawek.jan]

@munish4u911ex​  ,

any progress?

Btw. I noticed AN4230 has been updated - coincidence?

JW

[munish4u911ex]

Hi Jan,

Thanks for your reply and many apologies that I could not post a response as I had gotten too busy with the project. Anyway, the problem was found to be somewhere in Libusb & linux communication, and not with the RNG. CEIS/SEIS bits were never set. We later had to send some deterministic data to confirm the problem with Libusb. It might be a libusb/linux bug which I'll explain in another thread.

I was always highly skeptical of the idea that the RNG will be repetitive but had a hard time explaining this to my hell-bent boss because of the mention of LFSR in the datasheet. I feel that there should be more detailed explanation about the LFSR implementation in the F4 User guide (e.g no. of bits), as well as of why it is reuired at all.

Regards

[waclawek.jan]

Thanks for the explanation.

JJW