Has anyone found a good entropy source for uCs without RNG? I've tried timebase skew, but the RCs are too stable over short periods. The low bit of the temperature sensor is also too stable. RAM after POR isn't reliably random either. Ideas?

[DAlbe.3]

..

[Peter BENSCH]

That is a good question to which there are many different answers. So far, a noise source has often been used, and the TRNG in the STM32 also makes use of it. However, additional effort is required which, depending on the requirement for entropy, quickly becomes quite large and makes an STM32 derivative with built-in and certified TRNG seem more sensible.

Examples of RNG replicas from the past can be found here (using the ADC) or there (external zener diodes as noise source).

Good luck!

/Peter

[DAlbe.3]

Thank you @Peter BENSCH​, I agree and for future product builds, we will shift to a processor that includes a TRNG...that will take time because of lead times...as I'm sure you understand. From our discussion in another thread, we had been under the impression that the processor we were using already had a TRNG. For now, we have implemented a workaround such that if a TRNG is present, we use it; if not, we use a PRNG with entropy source. I'm just looking for a way to improve the entropy source (which I will describe below in my response to waclawek.jan).

[waclawek.jan]

Maybe your application is better off with a well-controlled PRNG than a bad noise source (or you may be well-off with the combination of the two). If yes, you may want to consider storing new seed (possibly calculated by a different PRNG algorithm) into EEPROM upon each reset.

In true mcu, there's no one size fits all.

JW

[DAlbe.3]

Thank you @Community member​, the issue with using any PRNG is both the seed and how cryptographically secure the PRNG is. We used the TRNG for a variety of security reasons including AES IVs. The idea of keeping the seed in EEPROM and storing an initial random seed at the factory is interesting and I need to think about that more; I worry that the seed becomes the vulnerability (as well as EEPROM and write cycle limitations).

For entropy, we currently use a hash of the randomness in RAM at power-up. We tried measuring clock skew and ADC noise as entropy sources but found neither to be sufficiently random. Relying on RAM for entropy has issues too (e.g. it's hard to tell when a POR had power off long enough for the RAM state to change); hence the question. Again, it's an interesting idea; thank you!

P.S. If you know of a really compact CSPRNG, please share!

[Piranha]

Take the unique device ID and do a hash on it - that's your initial factory programmed seed. :)

[DAlbe.3]

Thank you for the suggestion @Piranha​. Unfortunately, having a unique seed doesn't really solve the entropy problem. My needs (and I apologize that I had not stated this clearly) are mainly security related. Consider three challenges:

1. An algorithmic hash of plaintext accessible to the attacker (like the UID) isn't going to yield much security. That's easy to solve: a truly random factory programmed seed can be easily supplied from many sources such as openssl. However, that just leads to a bigger problem:
2. Even with a truly random seed, most simple PRNGs (LFSR, GLFSR) are not cryptographically useful: their generated PN sequence is highly predictable. That could be solved with a cryptographically secure PRNG (CSPRNG) like ISAAC, but I'm also super-tight on code space. However, this too has significant vulnerabilities:
3. Even with a good factory seed and a CSPRNG, the seed for the next number must be updated and stored persistently after each number generated. The seed itself then becomes a vulnerability: if the seed is discovered, or fails to update (interrupted), or seed storage is manipulated, the CSPRNG output becomes predictable and security is lost.

Hence the interest in a good entropy source. What @Peter BENSCH​ said is true: a hardware TRNG is the right solution, but for hardware that lacks a TRNG, I'm interested in what people are using as the next-best thing. Clock skew, ADC noise, and RAM at power-up are all commonly discussed potential entropy sources. Some studies have shown that RAM entropy is quite good, but because RAM retention can be very long on low power uCs (STM32L/U), it's not clear how to tell when RAM is really at a random startup state. It's an interesting problem...thanks again!

[Danish1]

I seem to remember an interesting approach to generation of random numbers - I'm not sure if it was from Knuth or Numerical Recipes (my two go-to sources - it shows my age).

Anyway they had something like 3 pseudorandom-number generators, none of which was particularly strong. But then they used yet another pseudorandom sequence to choose which of those generators would be tapped for the next number.

Maybe you could use a weak entropy source, capable of producing only a couple of bits of randomness, to choose which pseudorandom sequence to next pluck from.

----

Another thought: MbedTLS has code that tries to combine multiple weak random sources. Have you checked what they do?