Consider using TRNG for RP2350

[deshipu]

The RP2350 has a new peripheral for a true random generator, it could be nice to make use of it.

[jepler]

Based on a quick perusal of the 2350 datasheet the 2040 compatible "rosc randombit" generator should work with the new chip but using the new hw module mother be faster or something.

[jepler]

Better yet switch to pico rand from the sdk and delete my "crypto" code from circuitpthon. It will select the right hw mode for generating random bytes

[jepler]

I would probably drop this from the 9.2.0 milestone. While I don't actually have any RP2350 hardware for testing, I believe the ROSC based RNG is currently working on both chips, so this is not urgent missing functionality.

[mimi89999]

I'd be happy to implement this. I'd mix entropy from both TRNG and ROSC (as pico_rand does), but I'd keep the existing SHA-256 conditioning rather than switching to pico_rand. It gives more control over the TRNG configuration (health tests, sampling rate), and SHA-256 is a stronger conditioner than the splitmix64/xoroshiro128** that pico_rand uses.

[dhalbert]

I don't know enough about RNG's to judge, and would follow your judgment. Is there a significant performance difference?

[mimi89999]

I have a working implementation. Here are benchmarks on a Seeed Studio XIAO RP2350:

OLD:

os.urandom benchmark
-------------------------------------------------------
Size:    1B | 1000 calls | 0.039s | 25.04 KB/s
Size:    4B | 1000 calls | 0.040s | 97.65 KB/s
Size:   16B | 1000 calls | 0.041s | 381.09 KB/s
Size:   32B | 1000 calls | 0.042s | 744.05 KB/s
Size:   64B | 1000 calls | 0.074s | 844.54 KB/s
Size:  128B | 1000 calls | 0.140s | 892.86 KB/s
Size:  256B | 1000 calls | 0.275s | 909.09 KB/s
Size:  512B | 1000 calls | 0.531s | 941.62 KB/s
Size: 1024B | 1000 calls | 1.043s | 958.77 KB/s
Size: 2048B | 1000 calls | 2.069s | 966.65 KB/s
Size: 4096B | 1000 calls | 4.121s | 970.64 KB/s
Size: 8192B | 1000 calls | 8.157s | 980.75 KB/s
-------------------------------------------------------

NEW:

os.urandom benchmark
-------------------------------------------------------
Size:    1B | 1000 calls | 0.064s | 15.26 KB/s
Size:    4B | 1000 calls | 0.064s | 61.04 KB/s
Size:   16B | 1000 calls | 0.071s | 220.07 KB/s
Size:   32B | 1000 calls | 0.074s | 422.27 KB/s
Size:   64B | 1000 calls | 0.119s | 525.26 KB/s
Size:  128B | 1000 calls | 0.186s | 672.03 KB/s
Size:  256B | 1000 calls | 0.317s | 788.64 KB/s
Size:  512B | 1000 calls | 0.565s | 884.95 KB/s
Size: 1024B | 1000 calls | 1.062s | 941.62 KB/s
Size: 2048B | 1000 calls | 2.048s | 976.57 KB/s
Size: 4096B | 1000 calls | 4.014s | 996.51 KB/s
Size: 8192B | 1000 calls | 7.910s | 1011.38 KB/s
-------------------------------------------------------

Maybe it could be sped up with the RP2350's hardware SHA-256 accelerator but I haven't gone there.

The real point isn't performance though, it's entropy quality. By mixing both sources into the SHA-256 conditioner, one source failing doesn't zero out the entropy.

[mimi89999]

I implemented it in #10826

[mimi89999]

There is the following note in section 8.3.8 of the datasheet that actually made me consider changing the RNG source:

When the system clocks are running from the XOSC, you can use the ROSC to generate random numbers. Enable the
ROSC and read the RANDOMBIT register to get a 1-bit random number; to get an n-bit value, read it n times. This does not
meet the requirements of randomness for security systems because it can be compromised, but it may be useful in less
critical applications. If the cores are running from the ROSC, the value will not be random because the timing of the
register read will be correlated to the phase of the ROSC