In order to make discussion about RNG initialization etc. more effective, I've tried to classify the requirements to our random number generators for different applications:
- just spit out some numbers
Simple. Even rand() does that. It's always the same sequence, but ok for some applications. This is the current state of affairs.
Enough for (boring) Tetris.
Insufficient for networking (breaks random backoff, ...).
- per-node different sequence
This would need seeding of PRNGs with something more or less unique per node. CPUID would mybe do. See #5321.
Solves the "random backoff" problem.
Totally insufficient for any kind of cryptography.
- secret per-node different sequence
Depending on the seeding of a prng, this would make it possible to create initial secret crypto keys (I think.).
For this the CPUID needs to be sufficiently large, and the PRNG needs support for large seed values.
(An uint32_t seed value would only lead to 2**32 different seed values, making it unusable again)
CPUID may or may not be secret (e.g., only known to the person who flashed the node), as it might be derived from a serial number or MAC address.
So on the seeding, used PRNG and crypto algorithms, this might be a (suboptimal) baseline for cryptography.
Solves the "create initial crypto key" problem.
- properly seeded PRNG with injected entropy
Random events are used to somehow inject entropy into the PRNG output.
While there are many ways to implement this, if done well is probably as good as it gets without a HWRNG.
Solves the "barely enough for crypto" and "make tetris less boring" problems.
- HWRNG enhanced PRNG
HWRNG's promise "truly random numbers", but are often slow. So usually they're just used to improve randomness of PRNGs.
Solves the "hopefully good enough for crypto" problem.
- high-quality HWRNG
whatever that means.
Most helpful comment
I just realized: it's probably not such a good sign, that we don't even have a label "security" in the issue tracker. ;)