alt Hacker NewsThis is why I use, in security critical contents of my software (where the numbers have to be computationally infeasible to produce), a type of random number generator called an XOF (extendable-output function).
It takes entropy from multiple different sources, makes it all input to the XOF, then the XOF uses cryptography to output a stream that has as much entropy as the combined entropy of all of its sources of randomness. So if an XOF, for example, takes 100 runs of rdrand16, along with the system time in microseconds and the number of milliseconds between receiving 100 packets over the network, the XOF will output a completely random stream without artifacts like never returning 0x0000, even if rdrand16 never outputs 0x0000.
Replies
Well that very similar to how the Linux kernel does it. The linux kernel does it a little differently in that it uses the chacha8 stream cipher instead of a XOF. The chacha8 stream key is frequently reseeded by hashing the entropy pool with blake2b over the collected randomness from all sources but a lot comes from the nanosecond timing of hardware interrupts. Depending on configuration the blocking rng does not return unless 256 bits of trusted randomness are mixed into the entropy pool.
If anyone is interested in this topic please just read the code[0]. It has a lot of interesting tricks that you would not have just rolling your own.
[0]https://github.com/torvalds/linux/blob/master/drivers/char/r...
If you're building a userland XOF RNG to extend the kernel's RNG (that has the same security properties) you are reducing security, not improving it. The kernel has advantages for managing and securing a secret "entropy" pool that you won't replicate in userland.
But if you're using a custom kernel that has a custom KRNG based on an XOF, sure, whatever, I guess.
Nifty! Out of curiosity, how much different is that from taking several partly-random streams and XORing them together? I always assumed what was going on was essentially a fancier version of that.
Oh, I guess you have to ensure the inputs aren’t correlated, or they’ll cancel out?
You can effectively achieve the same result with this simple operation:
hash = sha256(current_time());
for i := 0; i < n; i++ {
hash = sha256(hash.append(current_time()))
}
The reason I like doing it this way is that it happens entirely in userspace, it's genuinely a secure method of generating entropy, and it has no dependencies on potentially buggy firmware or microcode outside of the time() call, which is both fairly narrow, fairly heavily used (meaning a bug is likely to be discovered during testing, as the implementation is likely heavily scrutinized), and also fairly easy to test independently - just look at the number of nanoseconds that elapse at each consecutive call to sha256(current_time()) and verify that there's some statistical variance. The above suggestions are assuming about 2.5 bits of variance between calls, meaning there should be a range of at least 20 nanoseconds between your slowest and fastest hash call. This has been true on every CPU I've ever measured, including microcontrollers.
Isn’t this effectively what systems like /dev/(u)rand do? Pool multiple random sources together to hedge against these things?
I fail to see why one should either rely on a single random source nor roll their own.