classify RNG "randomness" in code

[kaspar030]

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:

1. 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, ...).
2. per-node different sequence
   This would need seeding of PRNGs with something more or less unique per node. CPUID would mybe do. See sys/auto_init: cpuid as seed for random_init #5321.
   Solves the "random backoff" problem.
   Totally insufficient for any kind of cryptography.
3. 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.

1. 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.

1. 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.

1. high-quality HWRNG
   whatever that means.

[kaspar030]

IMHO we should make this classification available for code, so e.g., crypto code can at least spit out a warning when used with no or a bad random source.

[OlegHahm]

I just realized: it's probably not such a good sign, that we don't even have a label "security" in the issue tracker. ;)

[jia200x]

Some radio drivers (e.g at86rf2xx) provide a "true" RNG based on transceiver events. Should be fast enough for most applications :)