Under normal load, the generator reseeds every time it produces an output, so its output should be almost completely statistically random. Under very heavy load, it can generate multiple blocks of output between reseeds.
This is a very interesting point. The underlying algorithm AES-CTR has one potential pitfall that distinguishes it from true random: it never repeats. CTR mode works by encrypting a counter in ECB mode. ECB mode encryption must be reversible, or else you can’t decrypt, implying that two distinct inputs must result in two distinct outputs. Hence, two different counter values -> two different stream chunks.
This doesn’t help an attacker in any way I’m aware of, however. In order to reduce the set of “next possible outputs” to something feasible, they’d need to observe a mountain of previous outputs. If you rekey frequently though, that’s even better.
Hardware RNGs are an interesting conundrum… On the one hand, should a flaw be discovered down the line, there’s no way to patch the RNG. On the other hand, this means that there’s no way to tamper with the RNG which is sound and reassuring.
If you’re doing your HWRNGs the right way, that is piping them into a
proper PRNG (such as Yarrow or Fortuna), a flawed (or compromised) HWRNG
isn’t such a big deal (also provided that’s not your only source of
entropy into the PRNG).
This reads like an advertisement.