Implementation of hardware RNGs on MCUs

[MicroControleurMonde]

Hi guys,

I needed to generate random numbers several weeks ago and so I pulled out my RP2040 to do this. And then you know what it is, from thread to needle, I jumped on my esp32 and so on.

In fact I realized that the hardware RNG part wasn't there, so I started working on it. I have been rummaging through the docs and I have coded the calls to the correct registers.

Question, I had fun on the PyBoard with 'pyb.rng()'. Does it call on the STM32 hardware RNG ? I didn't go to check.

ESP32
ESP32-C3
ESP32-C6
RP2040 using ADC.
Teensy 4.1

Note: For the Tensy, I am not able to implement the TRNG ... I used several ADC to generate values instead.

Cheers.

[robert-hh]

All three ports you mention support already a hardware TRNG with the os.urandom() method. The random class uses a Pseudo RNG.
See https://docs.micropython.org/en/latest/library/os.html#os.urandom and https://docs.micropython.org/en/latest/library/random.html#module-random

[MicroControleurMonde]

Hi Robert,

Pseudo RNG ... sorry but If I have read the ESP32 docs correctly, they are hardware RNG, not pseudo-random.
So what I've coded is going to read hardware registers.
For the RP2040 and the Teensy, the ADCs are used to collect noise.
I didn't touch the Pyboard. I used it as it is. And it's good

Now for urandom: "Whenever possible, it is generated by the hardware random number generator"
Ok, good.
Which MCUs exactly ?

[robert-hh]

As said, the MicroPython module uses a Pseudo RNG in all ports.
os.urandom() is based on a True RNG (hardware), but not supported by all ports and MCUs.
Ports that uses a TRNG with os.urandom():

• STM32
• ESP32
• ESP8266
• RP2
• MIMXRT (teensy)
• SAMD
• Renesas RA
• NRF

Maybe more. In order to tell, whether a certain MCU uses a TRNG, look whether os.urandom() exists.

[MicroControleurMonde]

Thanks for the reply Robert.

I was wondering since the definition of urandom() was still rather vague.

You can admit that this is already confusing, right?

I'm delighted to discover that the i.MX RT are supported. Given the number of registers at stake, this will save me a lot of headaches.

Incredible: ‘RP2350 contains a Real Random Number Generator block based on Arm IP’. They never cease to impress me at Raspberry!

[robert-hh]

Yes, I know this sentence.

[MicroControleurMonde]

• ESP8266 since when ?

You're sure about that ?

[robert-hh]

As far as I understand the code, the random numbers are taken from the WiFi block as entropy source. Similar like you wanted it to do with ADC. Only in the WiFi section the bandwidth is much higher. I faintly remember that the ESP32 (maby only some of them) also use the WiFi block as entropy source,

The RP2040 also supports Hardware RNG, and it seems to use a side effect of the clock circuity.
For SAMD21 I used a jitter between two PLLs as random source.

I did not look into the other devices. And for each port there may be MCUs that do not support a TRNG.

[Josverl]

Would it make sense to:

• document the known implemented TRNGs in a Wiki page
• add a link to that from the random.urandom() documentation

[MicroControleurMonde]

@robert-hh

Not entirely: the ESP32s have a dedicated block for random generation.

In the Espressif doc, they advise this:

"...Thermal noise comes from the high-speed ADC or SAR ADC or both" and then ..."When there is noise coming from the SAR ADC, the random number generator is fed with a 2-bit entropy in on clock cycle of RC_FAST_CLK (8 MHz), which is generated from an internal RC oscillator ...".
Then you go read your register to collect your 32 bits value.

So, if my understand is correct, the term ‘RC oscillator’ refers to an internal oscillator based on an RC (resistor-capacitor) circuit. In the context of the ESP32 and its RNG, this means that the random noise used to generate random numbers comes from the oscillator. Not only the ADC (or SAR ADC). They are using a XOR on the 3 sources.

From what I found in the datasheets, here are the boards which have an included hardware RNG: all ESP32, some STM32 (STM32F4,STM32L4), some Microchip SAMD (SAMD21, SAMD51), surprisingly the BBC V2.2 (Nordic nRF52833) and the NXP i.MX RT serie. And now the RP2350 ^_^

• The RP2040 does not have a built-in hardware random number generator. And indeed I used the ADC to replicate the ESP principle.
  It works but the final entropy is a bit lower ...
• I did the same with the ESP8266 (ADC reading + Wifi) and the entropy is a bit better than the RP2040.

[MicroControleurMonde]

@Josverl

Well, that's totally make sens, because if I'd known about the urandom() module, I wouldn't have gone off fiddling with registers and I'd have focused on my entropy study.

[robert-hh]

The RP2040's data sheet section 2.17.5 is called 2.17.5. Random Number Generator. It refers to RANDOMBIT bit in the ROSC register, which accordingly is used by machine.urandom() to get random numbers. I made some simple test for randomness, and it looked not very well. Even the simple histograms looked odd. But feeding the data stream though a CRC or even just XOR made it looked better. So it should pass RNG tests when used to constantly inject a Pseudo-RNG.

[MicroControleurMonde]

And right you are !

Raspberry Pi Pico Datasheet - Build-date: 2024-10-15 / Build-version: eec2b0c-clean

Chapter 2.17. Ring Oscillator (ROSC) - Page 222.

My datasheet was stamped Build-date 2023-06-14 Build-version a6fe703-clean ...

My bad !

:-(

The ROSC is the internal oscillator that can be used to generate random numbers indeed.
Ok then, I will update my RP2040_RNG repo and test a fat batch of 1 million+ values to see if it pass the Dieharder and what entropie score it reaches.

In initial method (with ADC), it reached a 3.437 bits per byte entropy.
I will keep you posted.

[MicroControleurMonde]

Update.

• TestU01 (Rabbit battery): Report - " ... the generator does not perfectly meet the criteria for statistical tests of random number quality."
• rngtest : Report - all the FIPS tests failed. 👀

[MicroControleurMonde]

@robert-hh

Your RANDOMBIT +CRC makes wonder !
Ent and rngtest are perfect.
Only Diehard shows some few weakness.

And it's fast: 1'5000'00 values: 133 seconds...

[robert-hh]

Thanks. I tried to make it efficient. CRC is always good for spreading bits.
Obviously using it for creating keys may not the best choice. But for other random number applications it works well.

[MicroControleurMonde]

It is (efficient) !

You could create keys with it but it would require post-RNG un-bias filter (ex.Von Neumann method).
PCG32 (from O'Neil) is very fast as well. It might replace CRC with a less "critical" value dispersion.

[MicroControleurMonde]

@robert-hh

FYI: I tested the Von Neumann filter: it works well but more than 50% of the values go to the trash.

I did 2 batches test of 13 million without and with filter and the statistical differences are really significant. But at what cost.

If you wish I can share the tests reports.

• Ent/DJent
• rngtest
• dieharder
• booltest

[MicroControleurMonde]

I have prepared a paper on RNGs and their application. Well, it's in French at the moment... I still haven't finished translating it completely. I will publish it later this week on my page.

I am also working on a small high entropy TRNG project (MCU + amp. + capacitors + resistors).
I hope I can break the 7+ bits per byte threshold.

[MicroControleurMonde]

@robert-hh

Guten Morgen Robert,

I'm not going to open a new thread because the topic is related to RNGs.

I am implementing my RNG code on ESP32-S3-DevKitC-1 v 1.1.

By reading the Technical Reference Manual version 1.6 for ESP32-S3, page 921, the memory address of the register 'RNG_DATA_REG' is indicated as being: 0x6003_3110

I have tried everything possible, but the result was always nill. So I have decided to go fishing for information on the Espressif website, in their source code. I finally found what I was looking for here (within the wdev_reg.h include file) :

https://github.com/espressif/esp-idf/blob/cc9fb5bd5ea7d3ddb1a8c26e5bf0076b3e1352f3/components/soc/esp32s3/include/soc/wdev_reg.h#L4

I have tried this address and now it works perfectly.

So, question: Can anyone here confirm or deny that the address 0x6003_3110 is incorrect and that the correct address is potentially 0x6003507C ?

primary_test_code_esp32-s3_hw_rng.md

I have send a report to Espressif's CRM website, but not sure they will reply soon ...