I believe that there is no such a thing as useful system without any viable source of entropy.
Any useful system has to communicate with something and has to have at least some vague idea of passing of time and thus you can hash timing and contents of outside communication into your preferably persistent entropy pool.
Ah, thank you. This is a good summary of another problem I had with the comment we're both replying to, that I had trouble voicing. The assumption that there is no entropy available almost directly contradicts the idea of using cryptographic random data for almost any purpose. I'm having trouble imagining a use case but I don't think it's entirely impossible one exists.
> The assumption that there is no entropy available almost directly contradicts the idea of using cryptographic random data for almost any purpose
Strictly speaking, that's correct. For practical purposes however, all you need is 256 bits of entropy. From there, you can generate an unbounded stream of independent random streams, which you can use for your crypto stuff. You don't need to re-seed. Ever. How do you think stream cipher work? You start from 256 random bits, and you generate a virtually unbounded random stream that encrypts your message.
The use case of this scheme is mainly reducing the attack surface. Not re-seeding prevents some attacks, detailed in the link I gave above.
> You need 256 bits of entropy and permanent, reliable power; or permanently writable and reliable media.
I did mention that already: https://news.ycombinator.com/item?id=18955720"If the device ever powers down, you will need 32 bytes worth of persistent storage, so you don't repeat the random stream every time you boot up."
> You haven't addressed the bit where you're presenting a solution in search of a problem.
Here's the problem: if the attacker controls one or several of the random sources, they may partially control the output of the RNG. In some cases, a simple bias can lead to catastrophic key recovery attacks (ECDSA comes to mind). In other cases, the attacker could simply use the RNG as a communication channel. It only takes 4 tries to control 2 bits of a hash. This is also described in the link you should really really follow.
> I'm quite familiar with random devices (i.e., Fortuna) and stream ciphers, thank you.
Good. Then you know that a stream cipher such as Chacha20 is a suitable high security RNG for long term keys (otherwise it wouldn't be suitable even as a stream cipher). The only problem is forward secrecy (the key used by the stream cipher is necessarily stored somewhere, and if it gets stolen, all past keys, including ephemerals!, are toast). That's what fast key erasure is for: have a 512 byte buffer or so, whose first 32 bytes are filled with your current seed. Stream 512 bytes from that seed and overwrite the entire buffer with it. The first 32 bytes will seed the next batch of random bytes. The rest can be distributed to the API user. (Also don't let users access the RNG state, they're obviously going to duplicate it.)
---
By the way, DJB points out that our go-to persistent storage, hard drives and SSD, aren't exactly easy to erase. Which is quite crucial for the forward secrecy fast key erasure achieves. My opinion is that every computer should come up with a dedicated persistent writeable (and over-writeable) memory. The tiniest chip should be able to afford 32 bytes of such memory.
Any useful system has to communicate with something and has to have at least some vague idea of passing of time and thus you can hash timing and contents of outside communication into your preferably persistent entropy pool.