Random() is much too slow

[westfw]

@vvb333007

We are trying to find a faster replacement for "random()"

But we haven't clearly specified how good a random number we need.
There's little point in trying to gather entropy from multiple sources if all you want is for your hand-held game to play differently each time it is run. The pseudo-random number generator that you get if you supply a seed via randomSeed() takes 4us on an R4, and is probably fine for most applications (there weren't many complaints about the R3 random(), which is also PRNG.)

It's not good for cryptographic applications, though.

The R4 has a True Random number generator, that is supposed to be good enough for crypto. There shouldn't be any need to search futher than that, assuming that it's "fast enough." The current implementation in Arduino seems to take about 90000us, which is the complaint. That's a "bug", IMO. It should only take about 20us. (which is still 5x slower than the PRNG.) That fetches 16 bytes worth of TRN, and 12 are just thrown away. With a bit more code and some static storage, the average speed could be down close to the PRNG speed. (and in theory, some of the generation time could be done in the background...) (Hmm. At the expense of some power consumption. There was a bug on the Renesas github where turning off the SCE did not fully turn off the TRNG, leading to 130uA or so of excess current in sleep modes..)

@Coding_Badly

There is no such thing as "increase security" with simple generators.

I dunno. That's like saying a 6 letter password doesn't have any increased security over a 4digit pin. OF COURSE it's "better." And of course seeding a PRNG with a bit of entropy is better than letting it be seeded with a built-in constant. It's not mathematically better, but it's slightly better in a practical sense. You need to understand your "attack surface" to guess whether it's "good enough."
(I think I've told the story about designing an "encryption scheme" that led to the company I work for being blackmailed ("pay me or I'll tell everyone how to decrypt your stuff!")... )

(BTW, if you're interested in doing cryptographically secure stuff, getting a good random number is probably a minor problem compared to figuring out how to do some sort of secure key storage.)

[DaveX]

For this thread we haven't heard back from OP, and seem to have solved the R4 random() speed problem by seeding randomSeed().

@westfw

It's not good for cryptographic applications, though.

Do cryptographic applications typically require large volumes of high quality random numbers? I thought the high quality is needed for key generation, but once you have the keys, then the algorithms are just algorithms. Maybe a high volume of commercial transactions would require a fast stream of high quality keys, but I can't see running an Arduino on the back end of that.

For large simulations, high quality, repeatable, fast PRNGs make sense, but I don't understand the use-case of a fast true RNG on an Arduino.

[westfw]

@westfw

some of the generation time could be done in the background

Well, THAT'S not going to happen. The bottom level code provided by Renesas has its own wait loops, is completely obscure, and doesn't show any signs of being able to be "backgrounded." (it looks a bit like everything funnels through some multiplexed SCE addresses, so leaving the RNG running might interfere with anything else that tried to use the SCE. Sigh.
Weird code, too...

ra/fsp/src/r_sce/crypto_procedures/src/sce5/plainkey/primitive/hw_sce_p09.c